答案是报错“equal MySQL server UUIDs”实为server-id重复所致，需执行SELECT @@server_id确认主从ID是否相同；若相同，须修改my.cnf中[mysqld]段的server-id为唯一非零值、重启MySQL，并依次执行STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO MASTER_SERVER_ID=主库ID; START SLAVE。
报错“equal MySQL server UUIDs”或IO线程卡在Connecting、Slave_IO_Running: No，十有八九不是UUID真重复，而是server_id撞车了——主从用了相同非零整数，比如都是1。
为什么server_id重复会导致复制失败
MySQL在复制握手阶段就校验server_id：从库连主库时，主库一看对方ID和自己一样，直接拒绝连接，根本不会交换UUID。所以SHOW SLAVE STATUS\G里Master_UUID为空、Last_IO_Error写“equal UUIDs”，其实是障眼法。
- SQL线程会静默跳过所有事件，
Seconds_Behind_Master不动，日志里却没报错 - 多个从库共用一个
server_id时，主库binlog只记录第一个连上来的那个ID，其余同ID从库收不到对应事件 -
server_id = 0会导致MySQL启动失败，错误日志明确提示server_id cannot be 0
怎么快速确认是不是server_id冲突
别只翻配置文件，运行时值才作数：
- 在主库和所有从库上分别执行：
SELECT @@server_id;—— 如果返回相同非零整数（如都是1），就是它 - 如果返回
0，说明配置没生效或压根没设，MySQL当未设置处理 - 检查
my.cnf里server-id是否写在[mysqld]段下；写在[client]或[mysqld_safe]里，MySQL完全不读 - Docker场景下，查启动命令是否带
--server-id=参数，镜像里硬编码的server-id = 1最常踩坑
改完server_id为什么还是连不上
改配置、重启MySQL只是第一步，旧的复制上下文还缓存着老ID的元信息，START SLAVE仍会带着旧ID重试：
- 必须先执行：
STOP SLAVE; - 再清空全部复制状态：
RESET SLAVE ALL;（注意是ALL，RESET SLAVE不删master.info） - 重新配置时，
CHANGE MASTER TO语句里的MASTER_SERVER_ID要填主库当前的@@server_id，不是本机新ID - 最后
START SLAVE;，再看SHOW SLAVE STATUS\G里Slave_IO_Running和Seconds_Behind_Master是否正常变化
怎么生成安全不重复的server_id
手填1、2、101这类小整数，扩缩容或克隆环境时极易撞车：
- 物理机推荐用IP段拼接，比如
192.168.0.101→1921680101 - 云环境优先取实例ID数字部分（如AWS
i-0abc123def456789a→ 取后8位456789a转十进制） - Docker/K8s用
hostname+pod UID哈希，避免同名Pod复用ID - 绝对避开
0和1：前者启动失败，后者是Docker镜像、一键脚本默认值，撞车率最高
真正麻烦的不是改ID，而是改完忘了RESET SLAVE ALL和重配MASTER_SERVER_ID——这两步漏掉，重启一百次也没用。
