MySQL 主主复制与主从复制在双活场景下的区别

MySQL 主从复制是单向同步，从库只读，主主复制是双向同步，两端均可写。主从适用于读多写少、强一致性场景，主主适用于跨机房、最终一致性场景，但存在循环复制和 ID 冲突风险。

先说结论：主从架构运维简单且数据一致性强，主主架构可实现双活写入但需自行解决冲突。

命令速用版

检查复制状态和自增配置，确认是否具备双活写入条件。

SHOW SLAVE STATUS\G
SHOW VARIABLES LIKE 'auto_increment_%';
SHOW VARIABLES LIKE 'log_slave_updates';

数据流向和写入权限决定了架构差异。主从复制是单向的，所有写操作必须发给唯一主库，从库设为只读，强行写会报错 ERROR 1290。双主复制是双向的，两台服务器互为对方的主和从，各自都能接受写请求，但这意味着必须自己兜底解决冲突。

主从复制天然存在同步延迟，从库可能落后几秒甚至几分钟。双主复制同样有延迟，但问题更隐蔽，如果两个节点几乎同时修改同一行，且没做应用层协调，就会出现后写覆盖前写或主键冲突报错，MySQL 自身不自动合并冲突。

若需搭建双主架构，必须按以下步骤配置以避免基础冲突。

1. 配置 server-id 全局唯一

确保每台服务器的 server-id 不同，否则一条语句可能在双主间无限循环复制。

[mysqld]
server-id=1
log-bin=mysql-bin

2. 配置自增 ID 避免冲突

双主必须配 auto_increment_increment 和 auto_increment_offset，否则自增 ID 必撞。例如 A 设 offset=1, increment=2 用奇数，B 设 offset=2, increment=2 用偶数。

# 节点 A
auto_increment_increment=2
auto_increment_offset=1
# 节点 B
auto_increment_increment=2
auto_increment_offset=2

3. 开启日志同步

双主都需开启 log_slave_updates=ON，否则无法接力同步。推荐使用 binlog_format=ROW，避免 STATEMENT 格式下函数在两端产生不同结果。

通过状态检查和写入测试确认复制链路正常且无冲突。

1. 检查复制线程

执行 SHOW SLAVE STATUS，看到 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 不代表数据已对齐，仅代表线程运行中。

2. 写入测试

在节点 A 插入数据，查询节点 B 是否可见；反之亦然。注意双主没有 Seconds_Behind_Master 指标，需业务层验证数据一致性。

3. 延迟观测

主从延迟可直接查 SHOW SLAVE STATUS，而双主更难观测，节点写完立刻返回成功，另一端可能还在重放中，此时若切流量过去，就可能读到旧值或空数据。

双主架构运维复杂度远高于主从，以下风险需提前规避。

1. 循环复制风险

若没关掉 log_slave_updates 或没设对 server-id，一条语句可能在双主间无限循环复制。必须确保 server-id 全局唯一。

2. 数据覆盖风险

假设 M1 和 M2 是双主，M1 执行 UPDATE 同步到 M2，M2 紧接着也执行 UPDATE 再同步回 M1，最终结果取决于谁后写、谁后同步，不是谁先提交谁生效。

3. 非确定性语句

禁止在双主上执行非确定性语句，如不带 WHERE 的 UPDATE、DELETE 或包含 NOW()、UUID() 的语句，否则极易导致数据不一致。

主从延迟是常态，双主伪实时但更难观测。主从延迟几秒到几分钟都常见，双主没有标准延迟指标，看到线程运行不代表数据已对齐。

适合跨机房部署、需就近写入、且能接受最终一致性的业务，如日志采集、用户行为埋点，不适合订单中心等强一致性场景。

必须配置 auto_increment_increment 和 auto_increment_offset，让不同节点生成不同步长的自增 ID，例如一个用奇数一个用偶数。