MySQL双主复制不自动解决冲突，需通过写入分离、错开自增ID、禁用双向UPDATE/DELETE、强化监控等手段规避；它非高可用银弹，运维复杂且风险高，建议优先选MHA、Group Replication等方案。
MySQL双主复制（Master-Master）本身不自动解决冲突，必须通过架构设计和规则约束来规避，而不是依赖复制层“修复”。核心思路是：让同一时刻只有一台主库写入特定数据，或确保写入内容天然不冲突。
写入分离：按业务/数据分片路由
最稳妥的方式是人为控制写入流向，避免两端同时修改同一行。例如：
- 用户表按ID奇偶拆分：主库A处理ID为奇数的写入，主库B处理偶数；
- 按业务模块划分：订单服务只写主库A，用户服务只写主库B；
- 使用中间件（如ShardingSphere、Maxwell+自定义路由）在应用层做写入判断，禁止跨库并发更新同主键记录。
主键与自增策略强制错开
防止INSERT主键冲突的关键是让两台主库生成的自增ID永不重叠：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 设置auto_increment_offset和auto_increment_increment；
- 主库A：offset=1，increment=2 → 生成1,3,5…；
- 主库B：offset=2，increment=2 → 生成2,4,6…；
- 务必同时配置innodb_autoinc_lock_mode=0（传统锁模式），避免批量插入时错乱。
禁止双向UPDATE/DELETE，只允许单向变更
UPDATE和DELETE极易引发不一致，尤其当WHERE条件匹配多行或依赖当前值时：
- 禁用应用对双主环境执行UPDATE语句，改用“逻辑删除字段+定时同步”；
- 所有更新走幂等接口：先SELECT再判断是否需要UPDATE，并加应用层分布式锁；
- DELETE操作统一转为UPDATE状态字段（如is_deleted=1），由下游任务异步归档清理。
监控与快速发现比自动修复更重要
双主下一旦出现冲突，往往已造成数据偏差。应聚焦于早发现、快止损：
- 定期比对SHOW SLAVE STATUS\G中的Seconds_Behind_Master、SQL线程错误；
- 用pt-table-checksum校验主从/主主间数据一致性，配合pt-table-sync修复（仅限低峰期且确认无写入时）；
- 在业务关键表添加last_modified_time字段，结合binlog解析识别异常时间戳跳跃。
双主不是高可用银弹，它增加了运维复杂度和风险面。若非强需求（如机房级容灾+读写分离），建议优先考虑MHA、Orchestrator等主从自动切换方案，或直接采用MySQL Group Replication、TiDB等原生支持多写一致性的系统。
