双主复制需严格配置auto_increment_offset与increment错开、server-id唯一、log_slave_updates开启、binlog_format设为ROW、GTID全集群启用，且应用层必须实现写入路由控制。
双主复制能实现写节点冗余，但auto_increment冲突是上线即爆的高频故障点——必须在配置阶段就堵死，不能靠后期补救。
必须错开auto_increment_offset和auto_increment_increment
这是防主键冲突的硬性前提，不是可选项。两台机器的auto_increment_increment必须相同（通常为2），而auto_increment_offset必须不同且互斥。
- 节点A设为
auto_increment_increment=2、auto_increment_offset=1→ 生成ID：1, 3, 5, 7… - 节点B设为
auto_increment_increment=2、auto_increment_offset=2→ 生成ID：2, 4, 6, 8… - 如果集群扩展到3节点，
increment要改为3，offset分别设为1、2、3 -
server-id也必须全局唯一，否则复制通道会静默失败
log_slave_updates必须开启，否则复制链断裂
双主本质是“互相当从库”，每台机器既要写自己的binlog，也要把从对方同步来的变更再写进自己的binlog，否则另一端无法继续接力同步。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 若漏配
log_slave_updates=ON，会出现Slave_IO_Running: Yes但Slave_SQL_Running: No，且Seconds_Behind_Master持续增长 - 该参数只对启用了
log_bin的实例生效，纯从库无需开启 - 开启后磁盘IO压力略增，但不可妥协
优先用ROW格式，别信MIXED或STATEMENT
STATEMENT日志在UPDATE含函数（如NOW()、UUID()）或非确定性SQL时，会导致主从值不一致；MIXED切换逻辑黑盒，线上难以预测。双主场景下，一致性比日志体积重要得多。
- 确认已设
binlog_format=ROW，可通过SELECT @@binlog_format;验证 -
ROW模式下，UPDATE语句即使并发执行，只要行锁机制正常，就不会因执行顺序不同导致最终状态差异 - 注意：
ROW日志体积更大，需确保max_binlog_size和磁盘空间足够
GTID模式能简化运维，但要求全集群统一启用
传统基于File/Position的复制，在主库切换或日志清理后容易断点错位；GTID用事务ID定位，自动跳过已执行事务，大幅降低人工干预频率。
- 必须同时开启：
gtid_mode=ON+enforce_gtid_consistency=ON - 所有节点（包括未来可能加入的从库）都要启用，混合模式会导致
CHANGE MASTER TO失败 - 启用GTID后，
START SLAVE不再需要指定MASTER_LOG_FILE和MASTER_LOG_POS，改用MASTER_AUTO_POSITION=1 - 首次启用GTID需重启MySQL，且不能有未提交的匿名事务
真正麻烦的从来不是配置步骤，而是应用层没做写入路由控制——哪怕参数全对，如果业务代码随机往两个节点发INSERT，UPDATE语句仍可能因执行顺序不同产生逻辑冲突。双主不是免运维银弹，它只是把“单点故障”换成了“冲突治理”。
