答案是报错“equal MySQL server UUIDs”常实为server-id重复所致，需先查SELECT @@server_id确认主从是否相同；若相同，必须修改my.cnf中[mysqld]段的server-id为唯一非零值，重启MySQL，并执行STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO ...（MASTER_SERVER_ID填主库server_id）; START SLAVE。
报错“equal MySQL server UUIDs”其实是server-id撞车
看到这个错误别急着删auto.cnf——先查@@server_id。很多情况下日志写的是UUID冲突，但真正拦住IO线程的是server_id重复。主库在握手阶段就拒绝连接，根本没机会交换UUID，所以SHOW SLAVE STATUS\G里Master_UUID为空是正常的，不能据此判断UUID真重复。
执行：SELECT @@server_id;
主从都跑一遍。如果返回相同非零整数（比如都是1），就是它了；如果返回0，说明配置没生效或压根没设，MySQL会把它当未设置处理。
常见诱因：
-
my.cnf里server-id = 1写在[client]段下，mysqld根本不读 - Docker容器反复启停，镜像里固化了
server-id = 1 - 自动化部署脚本硬编码，没做去重逻辑
- 克隆虚拟机后只改了IP，忘了改
my.cnf里的server-id
改完server-id不重启，复制照样连不上
SET GLOBAL server_id = N在MySQL 5.7里是无效操作，变量只读，改了也白改。必须改/etc/my.cnf（或对应配置路径）里的[mysqld]段，然后systemctl restart mysqld。
但光重启还不够——旧的复制上下文还缓存着老ID的元信息。从库重启后，START SLAVE仍会带着旧ID尝试连接，主库照拒。
必须补这三步：
STOP SLAVE;-
RESET SLAVE ALL;（注意是ALL，不是RESET SLAVE，后者不删master.info） -
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_SERVER_ID=123;（这里的MASTER_SERVER_ID填主库的@@server_id，不是本机新ID）
server-id设成0或1，等于埋雷
server-id = 0会导致MySQL启动失败，错误日志明确报server_id cannot be 0；server-id = 1虽能启动，但极易撞车——它是传统master默认值，也是Docker镜像、一键脚本最爱填的数字。
安全生成方式：
- 物理机：用MAC哈希，比如
printf '%s' 'eth0' | md5sum | cut -c1-8 | xargs printf '%d\n' 0x - 云环境：取instance-id数字部分（如
i-0abc123def456789a→456789a转十进制） - 别用IP末段（如
192.168.0.9→9），网络重构时极易重复
验证是否生效：SELECT @@server_id;和SHOW VARIABLES LIKE 'server_id';必须返回相同非零整数。
删auto.cnf前，先确认真是UUID冲突
如果SELECT @@server_id已不同，但依然报equal MySQL server UUIDs，再查@@server_uuid：
SELECT @@server_uuid;
主从都跑。如果返回完全一致（比如都是5a1b2c3d-开头），才是UUID真撞了。
这时才删auto.cnf（路径以datadir为准，通常是/var/lib/mysql/auto.cnf），然后systemctl stop mysqld → rm -f /var/lib/mysql/auto.cnf → systemctl start mysqld。重启后MySQL会自动生成新UUID。
容易漏掉的细节：
- 没清
relay-log文件（如localhost-relay-bin.*），这些文件头里存着旧server-id，重连后继续读就会错乱 - 误以为改
my.cnf+ 重启就够了，跳过RESET SLAVE ALL和重新CHANGE MASTER TO - 在
CHANGE MASTER TO里把MASTER_SERVER_ID填成本机新ID，而不是主库的@@server_id
