MySQL 配置参数 -- logs-slave-updates

0

logs-slave-updates 参数主要在多主多从的集群架构中开启,否则会导致各从实例无法完整同步集群的全量数据的问题。

多主多从

集群架构:

masterA → slaveA
↑ ↓
masterB → slaveB

logs-slave-updatesNormally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log.

即,正常情况下,一个slave节点是不会将其从master节点同步的数据更新操作记录至自己的二进制日志bin-log中的。

在多主的场景下,各master节点其实又相互作为另一方的slave节点进行着数据的一致性同步操作。例如 masterA 会以slave的角色同步 masterB 上的数据,masterB 也会以slave的角色同步 masterA 上的数据,如果没有开启 logs-slave-updates参数配置,则masterA \ masterB 虽然也能保证数据的一致性和完整性,但二者的 bin-log 中都只记录了作用在自身实例上的数据更新操作。

例如:

masterA insert row1 bin-logA add row1
masterB insert row2 bin-logB add row2
masterA replicate row2 from masterB But bin-logA will not log this update
masterB replicate row1 from masterA But bin-logB will not log this update
slaveA replicate row1 form bin-logA
slaveB replicate row2 form bin-logB

因为主从复制是使用 bin-log 完成的,masterA masterB 互补同步数据时并没有从对方同步的数据写入自己的bin-log,则会导致自己的从实例只能同步到集群的部分数据。

多从一从

在多主一从模式下,logs-slave-updates就没那么必须了,各主实例只需维护好自身的 bin-log,从实例则分别读取各主实例的bin-log汇总集群的全量数据,还可以一定层度上提高集群性能。

但为了保证容灾恢复,还是要尽可能的保证logs-slave-updates的开启,否则每台主实例都只有自身数据更新的bin-log,都只能恢复集群数据的一部分,虽然也可以只恢复各自的bin-log再全量同步其他主实例的数据,但相对麻烦些。

你可能感兴趣的

载入中...