server-id重复会导致主库在握手阶段拒绝从库连接，io线程直接退出；因主库校验从库server-id时发现与自身或其他从库相同，即终止复制连接，错误日志提示“equal mysql server uuids”实为server-id冲突所致。
必须停掉冲突实例、改配置、重启MySQL，再重置复制上下文——只改server-id不重启，或者只重启不执行RESET SLAVE ALL，同步仍会失败。
为什么server-id重复会导致IO线程直接退出
MySQL在建立复制连接时，主库会校验从库发来的server-id。如果发现和自己相同，或和已注册的其他从库重复，主库会在握手阶段拒绝该连接，并在从库错误日志里写入：Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs（注意：这里报的是UUID，但根源常是server-id撞车，尤其克隆虚拟机/Docker镜像未清理）。
常见诱因包括：
- 用
cp /etc/my.cnf直接复制配置，没改server-id - Docker容器反复启停，复用默认
server-id = 1 - 自动化部署脚本硬编码
server-id = 1，未做去重逻辑
检查与确认是否真冲突
别只看配置文件——得确认运行中的值。在每台MySQL上执行：
SELECT @@server_id;
如果返回相同数字（比如都是1），就是冲突；如果返回0，说明配置未生效或根本没设（MySQL会把0当未设置处理）。
顺带验证是否真在跑：
ps aux | grep mysqld
避免残留进程干扰判断。
修改后必须重启+重置复制链路
改完/etc/my.cnf里的server-id，光systemctl restart mysqld不够。旧的复制连接还带着老ID的元信息，必须手动刷新上下文：
STOP SLAVE;-
RESET SLAVE ALL;（注意不是RESET SLAVE，后者不删master.info） -
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_SERVER_ID=123;（这里的MASTER_SERVER_ID填主库的@@server_id，不是本机的新ID） START SLAVE;
最后用SHOW SLAVE STATUS\G确认：Slave_IO_Running和Slave_SQL_Running都为Yes，且Seconds_Behind_Master开始下降——才真正恢复。
容易被忽略的细节
很多人修完以为完事了，结果过几小时又断。问题常出在：
- 没清空
datadir下的旧relay-log文件（如localhost-relay-bin.*），这些文件头里还存着旧server-id，重连后继续读就会错乱 - 误以为
SET GLOBAL server_id = N能热生效——不行，这个变量不可动态修改，必须重启 - 用IP末段生成
server-id（如192.168.0.9 → 9），网络重构或扩容时极易重复，应改用MAC哈希或云平台instance-id数字部分
真正安全的做法：改ID、删relay log、重启、重置复制——四步缺一不可。
