log_slave_updates必须双方开启，否则双主复制闭环中断；server-id须全局唯一且写入配置重启生效；auto_increment_offset与increment需成对错开防主键冲突；GTID不能替代server-id的事件过滤作用。
log_slave_updates 必须双方都开，否则复制链直接断掉
双主不是“一主一从+反向再配一次”，MySQL 在双向同步中没有纯主库角色，A 和 B 互为对方的从库。log_slave_updates=ON 是让从库把重放的事务写进自己 binlog 的开关——不开，B 执行完 A 的变更后不记 binlog，A 就收不到回传，整个闭环根本走不通。
常见错误包括：
• 只在一方开启，另一方关着
• 误以为“我是主库不用开”
• 运行时执行 SET GLOBAL log_slave_updates = ON，但没写入 my.cnf，MySQL 8.0.22 之前该设置重启即失效
开启后会带来额外压力：
• max_binlog_size 是否合理？过小会导致频繁 rotate
• 磁盘 I/O 能否扛住双倍写入（原生写 + relay 后再生）
• sync_binlog 设为 1 时可能引发性能抖动，尤其高并发写场景
server-id 必须全局唯一，且必须写进配置文件并重启生效
server-id 不是标识“谁是主”，而是用于 I/O 线程过滤同源事件：每个 binlog event 都携带源节点的 server-id，接收方在写入 relay log 前硬性比对——若等于本机 @@server_id，直接丢弃，不报错、不记录、不告警。
如果 A 和 B 的 server-id 都是 1：
• A 发的 event 带 server-id=1 → B 收到后因 1 ≠ 1？不对，B 的 @@server_id 也是 1 → B 静默丢弃
• 实际结果是：双方互相跳过对方日志，SQL 线程看似运行，数据却反复丢失
验证是否真正生效，必须三步并行：
• 修改 my.cnf 后重启 mysqld
• 连接后执行 SELECT @@server_id;，结果必须与配置值一致
• 所有节点（含未来可能加入的从库）执行该语句，确保无重复
• 避免用 0 或 1；云环境克隆实例极易继承原值，上线前必改
防循环机制不能只靠 GTID，server-id 冲突仍会导致 I/O 层丢事件
启用 gtid_mode=ON + enforce_gtid_consistency=ON 后，MySQL 用 gtid_executed 集合去重，能自动跳过已执行事务——这是目前最可靠的防乒乓方案。但它不替代 server-id 的作用。
实测表明，在 MySQL 5.7 中：
• 即使 GTID 开启，若 A 和 B 的 server-id 相同，I/O 线程仍会在接收阶段静默丢弃事件
• gtid_executed 根本没机会看到这条 event，去重逻辑压根不触发
• 结果仍是数据丢失，而非死循环，但危害一样严重
所以正确顺序是：
• 先确保所有节点 server-id 唯一且持久化
• 再开启 GTID 并校验 SELECT @@gtid_mode; 返回 ON
• 最后检查 SHOW SLAVE STATUS\G 中 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否持续增长且无停滞
auto_increment_offset 和 increment 必须成对错开，且不能只设一个
双主下两边同时 INSERT，AUTO_INCREMENT 主键冲突是最常见的卡点。MySQL 不协调自增值，必须人工错开。
典型配对：
• A： auto_increment_offset=1，auto_increment_increment=2 → 生成 1,3,5…
• B： auto_increment_offset=2，auto_increment_increment=2 → 生成 2,4,6…
关键细节：
• 两个参数都必须写进 my.cnf，缺一不可
• increment 建议固定为 2（或更大偶数），避免因 offset 错位导致重叠
• offset 必须严格小于 increment，否则仍可能撞（例如 offset=3, increment=2 → 3,5,7… 和 offset=1, increment=2 → 1,3,5… 重叠）
• 修改后需重启，SET GLOBAL 不生效
最容易被忽略的是：循环复制问题往往在压测或切流后才暴露。低流量下丢几个 event 不易察觉，而它不报错、不中断线程、不写错误日志，只悄悄丢数据。
