MySQL主从复制配置参数 -- logs-slave-updates
logs-slave-updates 参数主要在 多主多从 的集群架构中 开启 ，否则会导致各 从实例 无法完整同步集群的全量数据的问题。
多主多从
集群架构：
masterA → slaveA ↑ ↓ masterB → slaveB
logs-slave-updates ： Normally, 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 再全量同步其他主实例的数据，但相对麻烦些。
