MySQL 数据库双向同步复制

MySQL 复制问题的最后一篇，关于双向同步复制架构设计的一些设计要点与制约。

问题和制约

数据库的双主双写并双向同步场景，主要考虑数据完整性、一致性和避免冲突。对于同一个库，同一张表，同一个记录中的同一字段的两地变更，会引发数据一致性判断冲突，尽可能通过业务场景设计规避。双主双写并同步复制可能引发主键冲突，需避免使用数据库自增类主键方案。另外，双向同步潜在可能引发循环同步的问题，需要做回环控制。

如上图所示，复制程序写入时也会产生 binlog，如何识别由复制程序产生的 binlog 并将其过滤掉是避免循环复制的关键。

原生 Dual Master 方案

MySQL 自身支持双主配置，但并没有去解决潜在的主键和双写带来的数据一致性冲突。对于双向同步潜在的循环复制问题，MySQL 在 binlog 中记录了当前 MySQL 的 server-id。一旦有了 server-id 的值之后，MySQL 就很容易判断某个变更是从哪一个 Server 最初产生的，所以就很容易避免出现循环复制的情况。而且，还可以配置不打开记录 slave 的 binlog 选项（–log-slave-update），MySQL 就不会记录复制过程中的变更到 binlog 中，就更不用担心可能会出现循环复制的情形了。

从 MySQL 自身的方案中可以找到切入点，就是如果能在 binlog 中打上标记ÿ