log_slave_updates 必须在双向同步双方都开启，否则循环复制断链；需配置文件固化、配合 GTID 或 server-id 过滤防循环；auto_increment 需错开 offset/increment；server-id、复制账号、初始位点对齐缺一不可。
log_slave_updates 参数到底要不要开
在 MySQL 双向同步（即 A↔B 互为主从）中，log_slave_updates 必须在**双方都开启**，否则必然断链。它控制的是：从库是否把接收到的 relay log 再写入自己的 binlog。不开，B 从 A 同步完数据后不会记录到自己的 binlog，A 就收不到 B 的回传变更，循环同步直接失效。
常见错误是只在一方开、另一方关，或者误以为“我是主库就不需要开”——双向场景下没有纯主库，只有角色切换的节点。
-
log_slave_updates=ON是双向同步的硬性前提，不能按“当前角色”动态开关 - 该参数需写入配置文件（
my.cnf或my.ini）并重启生效，运行时SET GLOBAL修改无效（MySQL 8.0.22+ 支持动态修改，但生产环境仍建议配置文件固化） - 开启后，所有从库行为变成“中继+转发”，binlog 体积和写入压力会上升，尤其在高更新频次下要注意磁盘 I/O 和
max_binlog_size设置
如何避免 INSERT/UPDATE 无限循环
即使 log_slave_updates 开了，双向同步仍大概率触发循环复制：A 更新某行 → B 同步并写 binlog → A 又读到 B 的 binlog 再执行一遍 → 永远打转。MySQL 原生不自动识别“这是我自己发出去又被对方回传的事件”，必须靠外部机制截断。
最可靠的做法是用 replicate_ignore_db 或 replicate_do_table 配合 server-id 过滤，但更推荐基于 GTID 的方案：
- 启用
gtid_mode=ON+enforce_gtid_consistency=ON，让每个事务带唯一 ID；MySQL 在 apply 时会自动跳过已执行过的 GTID（gtid_executed集合去重） - 若不用 GTID，必须手动设置
replicate_ignore_server_ids，例如 A 的server-id=1，B 的server-id=2，则在 A 上加replicate_ignore_server_ids=2（表示忽略来自 server-id=2 的事件），B 上对称配置 - 切勿依赖
replicate_ignore_db过滤系统库或临时库——跨库 UPDATE、USE 切换、存储过程内多库操作都会绕过它
为什么 auto-increment 冲突是高频死点
双向同步下，如果 A 和 B 都允许对同一张表执行 INSERT，且该表主键是 AUTO_INCREMENT，几乎必然主键冲突。MySQL 不会自动协调两边的自增步长，除非你提前干预。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
必须在两端分别配置错开的自增序列：
- A 设为：
auto_increment_offset=1，auto_increment_increment=2 - B 设为：
auto_increment_offset=2，auto_increment_increment=2 - 重启后，A 生成 1,3,5…，B 生成 2,4,6…，避免主键碰撞
- 注意：此配置仅对新插入生效；已有数据主键不调整，迁移前需人工校验主键范围
启动双向同步时最容易漏掉的三件事
很多人配完参数就 start slave，结果同步卡在 Seconds_Behind_Master: NULL 或报错 Could not execute Write_rows_v1 event on table。往往是因为以下三项没做全：
- 双方
server-id必须不同且非 0（如 A=1，B=2），且不能与任何历史节点重复（GTID 模式下重复会导致无法启动 IO 线程） - 建立复制账号时，必须授予
REPLICATION SLAVE权限，并显式指定REQUIRE SSL（如果启用了 SSL）或REQUIRE NONE，否则CHANGE MASTER TO会静默失败 - 首次启动前，务必用
mysqldump --single-transaction --master-data=2导出一致快照，并在对方导入后，用CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy精确对齐位点；仅靠MASTER_AUTO_POSITION=1在 GTID 切换初期容易错位
双向同步不是“配置完就能跑”的功能，它是把两个独立数据库强行耦合，任何一端的 DDL、权限变更、网络抖动都可能引发连锁异常。真正稳定运行的关键，是把每条 binlog 的流向、过滤逻辑、冲突边界都画清楚，而不是依赖某个参数自动兜底。
