根本原因是主从server_uuid相同，而非server_id重复；server_uuid是mysql启动时写入auto.cnf的硬编码唯一标识，io线程握手时强制校验，相同则直接拒绝连接，必须停服删除auto.cnf后重启自动生成新uuid。
MySQL 5.7主从复制失败，报错 The slave I/O thread stops because master and slave have equal MySQL server UUIDs，根本原因不是server_id重复，而是两台实例的server_uuid完全一样——这在克隆虚拟机、物理拷贝数据目录、RDS导出再导入等场景中极为常见。
为什么server_uuid必须唯一，而server_id不够用？
server_id是逻辑标识，可动态修改（SET GLOBAL server_id = ...），仅用于复制链路中的位置标记；而server_uuid是MySQL实例启动时自动生成的硬编码身份凭证，写死在auto.cnf里，主从握手阶段由IO线程校验——一旦发现UUID相同，直接拒绝连接，连server_id是否冲突都不会再检查。
常见误操作包括：
- 用
scp或rsync整库拷贝从库到新机器，没删auto.cnf - VMware/CentOS克隆后未重置MySQL实例身份
- RDS备份恢复到自建ECS时，未手动覆盖
auto.cnf
如何安全修改server_uuid？
不能用SQL动态改，必须停服+手改文件。步骤如下：
- 执行
sudo systemctl stop mysql（或对应服务名，如mysqld） - 定位数据目录：
mysql -e "SELECT @@datadir;"，通常为/var/lib/mysql或/home/mysql/data3059 - 进入该目录，确认存在
auto.cnf文件；备份它：cp auto.cnf auto.cnf.bak - 删除原文件：
rm auto.cnf（注意：不是清空内容，是彻底删掉） - 重启MySQL：
sudo systemctl start mysql
重启后，MySQL会自动生成新的server_uuid（格式如 5c2e2849-5309-11ee-96a2-005056861cd4），可通过 SELECT @@server_uuid; 验证。
为什么只改server_id不解决问题？
因为错误发生在IO线程建立TCP连接后的身份认证阶段，早于复制参数解析。即使你用 SET GLOBAL server_id = 4310 改了ID，只要server_uuid还和另一台从库一致，master一收到第二个同UUID的连接请求，就会立即中断前一个（或拒绝新连接），导致“刚修好A，B就断了”的循环现象。
典型表现：
-
SHOW SLAVE STATUS\G中Last_IO_Error明确提示UUID冲突 -
SHOW SLAVE HOSTS;查不到某台从库（被master主动踢出） - 错误日志里反复出现
A slave with the same server_uuid as this slave has connected to the master
额外注意：RDS与自建混搭时的陷阱
阿里云RDS等托管服务的server_uuid不可见、不可改，但它的auto.cnf不会暴露给你；当你把RDS备份恢复到ECS时，ECS上的auto.cnf仍保留原克隆来源的UUID——这就和RDS本身形成隐性冲突。此时必须删掉ECS上的auto.cnf并重启，否则即使server_id设得再不同，复制也起不来。
真正要动的永远只有从库端的auto.cnf，主库UUID绝不能碰；多从库环境下，每台都必须有独立auto.cnf，哪怕它们的数据完全一样。
