MySQL 双主同步如何防止数据循环写入

核心是让节点准确识别“数据是否自己发出又被回传”，必须开启log_slave_updates且server-id全局唯一；GTID模式通过gtid_executed集合自动去重，比server-id过滤更可靠，可避免静默丢事件或无限循环。

MySQL 双主同步防止数据循环写入，核心不是“堵住某条路”，而是让每个节点能准确识别“这条数据是不是我自己发出去又被对方打回来的”。只要识别机制失效，循环就必然发生——而且是静默丢事件或无限重放，不报错、难排查。

必须开启 log_slave_updates 且双方固化

这是双向同步的物理前提。A 同步完 B 的变更后，必须把这次变更再记进自己的 binlog，B 才能回传；否则链路直接断开，根本构不成“循环”，只是单向失效。

• 参数必须写在 my.cnf（或 my.ini）中，设为 log_slave_updates = ON，然后重启 MySQL；运行时 SET GLOBAL 在多数生产版本中无效
• 不能只在 A 开、B 关，也不能认为“B 是从库才需要开，A 是主库不用开”——双主下没有纯主库，只有互为从库的节点
• 开启后 binlog 写入量翻倍，需检查 max_binlog_size、sync_binlog 和磁盘 I/O 承载能力

server_id 全局唯一且严格验证

这是防循环最底层、不可绕过的过滤开关。I/O 线程在写 relay log 前，会比对 event 携带的 server_id 和本机 @@server_id：相同就直接丢弃，不进 relay log，SQL 线程根本看不到它。

• A 设 server-id = 101，B 设 server-id = 102（避免用 0 或 1，防自动化脚本冲突）
• 修改配置后必须重启，并执行 SELECT @@server_id; 确认值与配置文件一致
• 检查所有参与复制的节点（包括未来可能加的从库），确保无重复；重复即等同于主动打开循环大门

优先启用 GTID 实现自动去重

GTID 比 server_id 过滤更鲁棒。每个事务自带唯一 ID（source_id:transaction_id），节点执行前查 gtid_executed 集合，已存在就跳过——不依赖位置、不惧跨库、无需人工维护规则。

• 两端都配：gtid_mode = ON + enforce_gtid_consistency = ON
• 初始化时用 CHANGE MASTER TO ... AUTO_POSITION = 1，位点由 GTID 自动对齐
• 禁用 replicate-ignore-db 等库级过滤，GTID 下它们既不可靠又不必要

auto_increment 必须错开避免主键冲突

循环写入常以主键冲突（ERROR 1062）暴露，根源是两边 INSERT 都生成相同 ID。这不是复制问题，但会中断 SQL 线程，放大循环风险。

• A 配：auto_increment_offset = 1，auto_increment_increment = 2 → 生成 1,3,5…
• B 配：auto_increment_offset = 2，auto_increment_increment = 2 → 生成 2,4,6…
• 两个参数都要写进配置文件并重启；increment 建议固定为 2，避免 offset 超出范围导致重叠