双主复制循环写入的根本原因是log_slave_updates开启后，从库执行的relay日志会写入本机binlog，被对方重复拉取。解决方案：MySQL 8.0.23+用SOURCE_REPLICATE_IGNORE_SERVER_IDS精准过滤；旧版本可用replicate_rewrite_db按库隔离；严禁关闭log_slave_updates。
为什么双主复制会循环写入
根本原因是：每台 MySQL 在作为从库应用对方 binlog 时，log_slave_updates 开启后，这些被 relay 并执行的语句又会写入本机 binlog；而另一台机器同样在监听这个 binlog，于是把“刚收到的、自己转发过去的”事务又拉一遍——形成无限套娃。
典型现象是：SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 持续跳变、Exec_Master_Log_Pos 反复回退，或者 gtid_executed 里反复出现同一段 GTID（含对方 server_uuid）。
用 replicate_ignore_server_ids 精准过滤（MySQL 8.0.23+）
这是最干净的解法：让每个节点明确忽略“自己发出去又被对方转回来”的事务。
- 先查清双方
server_uuid：SELECT @@server_uuid; - 在 NodeA 上执行：
CHANGE REPLICATION SOURCE TO SOURCE_REPLICATE_IGNORE_SERVER_IDS = (UUID_OF_NODE_A); - 在 NodeB 上执行：
CHANGE REPLICATION SOURCE TO SOURCE_REPLICATE_IGNORE_SERVER_IDS = (UUID_OF_NODE_B); - 重启复制：
START REPLICA;（注意 MySQL 8.0.23+ 已弃用SLAVE术语）
该参数只接受 UUID 列表，不能填数字或通配符；且必须在 START REPLICA 前设置，运行中修改不生效。
用 replicate_rewrite_db 做逻辑隔离（兼容老版本）
当 MySQL 版本低于 8.0.23，或无法获取稳定 UUID 时，可用库名重写绕过循环。
- 约定：NodeA 写
db_a，NodeB 写db_b，业务层严格分流 - 在 NodeA 上配置：
CHANGE REPLICATION SOURCE TO SOURCE_REPLICATE_REWRITE_DB = (('db_b', 'db_b_local')); - 在 NodeB 上配置：
CHANGE REPLICATION SOURCE TO SOURCE_REPLICATE_REWRITE_DB = (('db_a', 'db_a_local')); - 这样对方写入的
db_b会被重写成db_b_local，本机规则不匹配，自然跳过
缺点是要求业务能按库切分写入，且重写后的库需提前建好、权限配齐；replicate_do_table 也可类似用，但表级粒度更难维护。
千万别关 log_slave_updates
有人为防循环直接在从角色上关掉 log_slave_updates，这是高可用架构的致命错误。
- 旧主切回从角色后，binlog 断层 → 其他从库无法接续同步
- VIP 切换后，新主无法被下游感知，整个复制链断裂
-
GTID模式下，gtid_executed集不完整，RESET REPLICA后可能丢事务
真正要控制的是“谁的事务该被重放”，不是“要不要记日志”。循环的本质是逻辑判断缺失，不是日志本身有问题。
实际部署中最容易被忽略的点是：SOURCE_REPLICATE_IGNORE_SERVER_IDS 必须在 START REPLICA 之前设置，且不能靠重启 mysqld 生效——它属于复制通道配置，改完得 STOP REPLICA; CHANGE REPLICATION SOURCE TO ...; START REPLICA; 才行。
