MySQL官方不原生支持双主架构，需手动配置互为主从并严格规避冲突；必须设置auto_increment_increment/offset、禁用非安全语句、统一ROW格式、确保事务顺序；因脑裂与数据不一致风险高，生产环境多弃用而选用MHA或Group Replication等方案。
MySQL 双主架构是否原生支持
MySQL 官方不提供原生的双主（Active-Active）复制支持。所谓“双主”，本质是两个 MySQL 实例互相配置为对方的从库，即 master1 → slave2，同时 master2 → slave1。这种拓扑能实现写入分流，但必须手动规避冲突，MySQL 本身不会自动合并、重排或拒绝重复写入。
配置双主前必须解决的核心问题
双主最致命的风险是主键冲突、自增 ID 冲突、DDL 不同步、以及事务执行顺序不一致导致的数据不一致。以下措施不可跳过：
-
auto_increment_increment和auto_increment_offset必须配对设置：例如两台机器分别设为increment=2, offset=1和increment=2, offset=2，否则 INSERT 会撞 ID - 所有表必须有显式主键，禁止使用
REPLACE INTO或无条件INSERT IGNORE，它们在双主下行为不可预测 - 禁止在双主间混用
STATEMENT和ROW复制格式；推荐统一用binlog_format=ROW - 关闭
slave_parallel_workers或谨慎启用（5.7+），并确认slave_preserve_commit_order=ON，否则事务回放顺序错乱
常见错误现象与对应检查点
一旦出现复制中断，大概率不是网络或权限问题，而是逻辑冲突：
- 错误信息
Could not execute Write_rows_v1 event on table xxx; Duplicate entry '1001' for key 'PRIMARY'→ 检查auto_increment配置和写入是否绕过应用层路由直接打到两台 - 从库 SQL 线程报
Slave_SQL_Running: No且Seconds_Behind_Master持续为 NULL → 执行SHOW SLAVE STATUS\G查Last_SQL_Error，90% 是主键/唯一键冲突或缺失表结构 - 部分表数据一致，部分不一致 → 检查是否用了
CREATE TABLE ... SELECT或临时表操作，这类语句在STATEMENT模式下无法正确复制
为什么多数生产环境弃用双主
双主不是“高可用升级版”，而是把故障面扩大了一倍。一个节点异常可能触发脑裂、写入丢失、甚至需要人工比对 binlog 手动修复。真正稳定的方案是：MHA + 单主 + 多从，或 MySQL Group Replication（8.0+）、Percona XtraDB Cluster 这类内置冲突检测与仲裁机制的集群方案。如果业务真需要双写，更推荐应用层分片 + 单主，而非依赖 MySQL 自身做双主同步。
最容易被忽略的一点：即使配置完全正确，只要应用没做写请求路由隔离（比如用户 A 固定写 A 主、用户 B 固定写 B 主），双主就随时可能因并发更新同一行而产生不可逆不一致。
