MySQL 数据库双向同步复制

最新推荐文章于 2025-10-19 22:08:33 发布

原创

最新推荐文章于 2025-10-19 22:08:33 发布 · 2.2w 阅读

13 ·

CC 4.0 BY-SA版权

本文探讨了MySQL数据库双主双向同步复制的挑战，包括数据一致性、主键冲突和循环同步问题。介绍了原生Dual Master方案及其不足，并提出自定义标记SQL方案以实现回环控制，避免循环复制。总结了设计要点，强调业务场景设计对规避数据冲突的重要性。

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

问题和制约

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

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

原生 Dual Master 方案

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

从 MySQL 自身的方案中可以找到切入点，就是如果能在 binlog 中打上标记，就有办法判断哪些 binlog 是复制产生的，并将其过滤。使用 MySQL 的方案则过于耦合 MySQL 的配置，在大规模部署的线上生产系统中容易因为 MySQL 配置错误导致问题。