mysql主从复制和双主复制有什么区别_mysql架构对比-mysql教程-PHP中文网

主从复制仅主库可写，双主复制两端均可写但需自行处理冲突；主从适用于读多写少、强一致性场景，双主适用于跨机房、最终一致性场景，但存在循环复制、id冲突、延迟不可见等风险，运维复杂度远高于主从。

mysql主从复制和双主复制有什么区别_mysql架构对比

主从复制只能写主库，双主复制两边都能写

这是最根本的差异：主从架构下，INSERT/UPDATE/DELETE 必须发给唯一 master，从库（slave）设为只读（read_only=ON），强行写会报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。而双主是两个节点互为 master 和 slave，应用可向任意一端发起写请求——但这也意味着你必须自己兜底解决冲突。

主从适合读多写少、强一致性要求高的场景（如订单中心），写路由集中，运维简单
双主适合跨机房部署、需就近写入、且能接受最终一致性的业务（如日志采集、用户行为埋点）
双主必须配 auto_increment_increment 和 auto_increment_offset，否则自增 ID 必撞（比如 A 设 offset=1, increment=2 → 用奇数；B 设 offset=2, increment=2 → 用偶数）

双主复制天然存在循环写入和数据覆盖风险

假设 M1 和 M2 是双主，M1 执行 UPDATE t SET balance = 150 WHERE id = 1，binlog 同步到 M2 并执行；M2 紧接着也执行了 UPDATE t SET balance = 130 WHERE id = 1，再同步回 M1 —— 最终结果取决于谁后写、谁后同步，不是“谁先提交谁生效”。更危险的是，若没关掉 log_slave_updates 或没设对 server-id，一条语句可能在双主间无限循环复制（M1→M2→M1→M2…）。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

必须确保 server-id 全局唯一，且双主都开启 log_slave_updates=ON（否则无法接力同步）
推荐使用 binlog_format=ROW，避免 STATEMENT 格式下函数（如 NOW()、UUID()）在两端产生不同结果
禁止在双主上执行非确定性语句（如不带 WHERE 的 UPDATE、DELETE），否则极易导致数据不一致

主从延迟是常态，双主“伪实时”但更难观测

主从延迟（Seconds_Behind_Master）可直接查 SHOW SLAVE STATUS，几秒到几分钟都常见；而双主没有这个指标——你看到 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes，不代表数据已对齐。因为 M1 写完立刻返回成功，M2 可能还在重放中，此时若切流量过去，就可能读到旧值或空数据。

主从可用 pt-heartbeat 或写入时间戳表来监控真实延迟
双主建议加应用层校验：关键写操作后，主动查另一端确认（例如插入后立即按主键查一次对方库）
不要依赖 SELECT ... FOR UPDATE 跨双主加锁，它只锁本机，另一端完全不受影响

双主不是高可用银弹，故障切换反而更复杂

很多人以为“双主=自动 failover”，其实恰恰相反：当 M1 宕机，所有写自动切到 M2，看似无缝；但 M1 恢复后，若未及时修复复制链路，M2 新增的数据不会反向同步回 M1，M1 成为脏数据源。更糟的是，如果应用在 M1 宕机期间仍往它发请求（比如 DNS 缓存未刷新），会产生写失败或连接超时，而这些失败请求若没做幂等重试，就会丢数据。