MySQL 8.0 不支持自动跳过相同 server_id 的双向同步，server_id 是强制唯一标识，冲突会导致复制启动失败；实现双向同步仅两种可行路径：双主+应用分片，或DTS类工具逻辑同步。
MySQL 8.0 不支持“自动跳过相同 server_id”的双向同步机制——这个特性根本不存在，强行依赖会导致复制中断或数据丢失。
MySQL 8.0 的 server_id 是强制唯一标识，不是可跳过的过滤条件
server_id 的作用是标记复制链路中每个节点的身份，MySQL 内部用它做事件来源判断、避免循环写入（比如 A→B→A）。如果两台服务器配置了相同 server_id，从库在启动 START SLAVE 时会直接报错：ERROR 1236 (HY000): The slave I/O thread stops because master and slave have equal MySQL server ids。这不是“可以跳过”的配置项，而是硬性校验。
- MySQL 启动时就校验
server_id是否为合法正整数且非 0 - 复制握手阶段，IO 线程会比对主库和自身
server_id，相等则拒绝连接 - 即使绕过启动检查（如临时改配置再 reload），后续 relay log 写入、GTID 生成、冲突检测都会出问题
真正能实现双向同步的两个可行路径
MySQL 原生不提供“自动双向同步”功能，必须靠组合配置 + 业务约束来模拟。主流做法只有两种：
-
双主（Active-Active）+ 应用层分片：两台都开
log-bin和log-slave-updates，server-id严格不同（如 1 和 2），auto_increment_increment=2+auto_increment_offset=1/2避免主键冲突；但要求应用写请求必须路由到固定主库，不能随机打 -
借助 DTS 类工具做逻辑双向同步：如阿里云 DTS、Debezium + Kafka + 自定义 sink，它们在应用层解析 binlog、过滤掉本端产生的变更、只同步远端变更，从而规避
server_id循环问题
注意：slave_skip_errors 或 replicate_same_server_id=ON（该变量在 MySQL 8.0 中已被移除）都不能替代上述设计。
容易被忽略的三个致命细节
很多人配完双主以为万事大吉，结果上线后出现数据覆盖、主键冲突、GTID 断点错乱。关键坑点如下：
-
log-slave-updates=ON必须在双方都启用，否则 A 同步过来的变更不会写入 B 的 binlog，B 就无法把变更再传回 A -
binlog_format=ROW是底线要求，STATEMENT 格式下自增字段、NOW()、USER() 等函数在两端执行结果不同，必然导致数据不一致 - 所有表必须有主键或唯一非空索引，否则
ROW格式下的 UPDATE/DELETE 无法准确定位行，从库重放时可能误改其他行
双向同步从来不是“配完就能跑”，它本质是用配置换掉一部分业务可控性。server_id 冲突不是 bug，而是 MySQL 在告诉你：这条路必须由你亲手画清边界。
