server_id必须唯一，否则双主复制会因日志来源识别失效而静默丢弃事件、陷入循环复制；MySQL通过server_id过滤同源binlog事件，I/O线程在写入relay log前比对并跳过与本机相同的server_id，该逻辑不可绕过且不依赖GTID。
server_id 不唯一，双主复制必然陷入循环复制，且静默丢事件——这不是配置错误，而是 MySQL 复制协议的底层行为。
为什么 server_id 重复会导致循环复制
在非 GTID 模式下（MySQL 5.6 之前或显式关闭 GTID），MySQL 依赖 server_id 做日志来源识别：每个 binlog event 都携带生成它的源节点的 server_id；当从库重放 relay log 时，若开启 log_slave_updates（双主必需），它会把重放的事务原样记入自己的 binlog，但 server_id 不会改写——仍保留原始 server_id。
如果 A 和 B 的 server_id 都是 1：
- A 写入事务 → binlog 记录
server_id=1→ 发给 B - B 重放 → 生成新 binlog，仍带
server_id=1→ 发回 A - A 收到
server_id=1的日志，误判为“自己刚发出去的”，直接丢弃（不报错、不告警） - 同理，B 也会丢弃从 A 回传的日志 → 双方 SQL 线程看似运行，实则事务反复丢失
server_id 如何实际参与过滤逻辑
MySQL 在 I/O Thread 接收 binlog 后、写入 relay log 前，会检查 event 中的 server_id：
- 如果等于本机的
server_id，跳过该 event（SQL_Thread不会看到它） - 如果不同，才写入 relay log，后续交由 SQL Thread 执行
- 这个判断发生在网络层解析阶段，不依赖 GTID、不依赖 position、不可绕过
所以双主中 A→B→A 的闭环能被切断，**前提是 A 和 B 的 server_id 必须不同**。例如 A 设为 1，B 设为 2，则：
- A 发出的 event 带
server_id=1→ B 接收并执行（因 1 ≠ 2） - B 重放后生成新 event，仍带
server_id=1→ A 收到后发现 1 == 1，丢弃
常见配置错误与验证方式
最容易被忽略的是：修改 my.cnf 后未重启 mysqld，或使用 SET GLOBAL server_id = N 临时设置——该值在重启后丢失，且无法用于复制过滤（I/O Thread 只读取配置文件中的值）。
- 确认生效：连接 MySQL 后执行
SELECT @@server_id;，必须与my.cnf中的server-id值一致 - 检查冲突：所有参与复制的节点（包括潜在的新从库）执行
SELECT @@server_id;，结果不能有重复 - 避免用 0 或 1 作为默认值：某些自动化部署脚本硬编码
server-id=1，一主多从时极易撞车 - 云环境特别注意：克隆实例常继承原
server_id，上线前必须手动修改
GTID 模式下 server_id 还重要吗
重要，但角色变了。GTID 模式下，循环复制主要靠 gtid_executed 集合去重，server_id 不再承担过滤职责。但它仍是节点身份标识，影响以下场景：
- 启动复制时，
CHANGE MASTER TO仍需指定MASTER_HOST等参数，而这些参数在 SHOW SLAVE STATUS 中的显示依赖server_id区分来源 - 部分监控工具（如 Percona Toolkit）通过
server_id关联拓扑，重复会导致识别混乱 - 降级到非 GTID 模式时，历史
server_id配置若未清理，可能引发意外丢事件
所以即使启用 GTID，server_id 仍需全局唯一——这不是冗余，而是兼容性与可观测性的底线。
