MySQL双主复制（Master-Master）本身不自动解决冲突，必须通过架构设计和规则约束来规避，而不是依赖复制层“修复”。核心思路是：让同一时刻只有一台主库写入特定数据，或确保写入内容天然不冲突。
写入分离：按业务/数据分片路由
最稳妥的方式是人为控制写入流向，避免两端同时修改同一行。例如：
用户表按ID奇偶拆分：主库A处理ID为奇数的写入，主库B处理偶数； 按业务模块划分：订单服务只写主库A，用户服务只写主库B； 使用中间件（如ShardingSphere、Maxwell+自定义路由）在应用层做写入判断，禁止跨库并发更新同主键记录。主键与自增策略强制错开
防止INSERT主键冲突的关键是让两台主库生成的自增ID永不重叠：
设置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等原生支持多写一致性的系统。
