必须修改从库auto.cnf中server-uuid值并重启服务，否则stop slave; reset slave all;无效；先通过show slave status\g确认last_io_errno为13117且错误含“equal mysql server uuids”，再比对主从show variables like 'server_uuid'是否一致。
必须修改从库的 auto.cnf 文件或让其重新生成，否则 STOP SLAVE; RESET SLAVE ALL; 无效，复制永远无法恢复。
确认是 UUID 冲突而非其他问题
先别急着改配置，直接查错误源头。在从库执行：
SHOW SLAVE STATUS\G
重点看这两项：
-
Last_IO_Errno: 13117（不是 2003、1045 或 1593） -
Last_IO_Error中包含"equal MySQL server UUIDs"字样
再对比主从的 UUID：
SHOW VARIABLES LIKE 'server_uuid';
如果输出完全一致，就是它了。注意：server_id 不同 ≠ server_uuid 不同——这是两个独立字段，别被绕进去。
修改从库 auto.cnf 的安全操作步骤
不能只改文件就重启，顺序错一步就会卡死。务必按以下顺序操作：
- 在从库执行
STOP SLAVE;（不加这句，后续可能报错“Cannot run this command on a running slave”） - 停止 MySQL 服务：
sudo systemctl stop mysql（Docker 环境用docker stop mysql-slave） - 备份原文件：
sudo cp /var/lib/mysql/auto.cnf /var/lib/mysql/auto.cnf.bak - 编辑
/var/lib/mysql/auto.cnf，仅修改server-uuid值（保留格式，换掉中间几位字符即可，例如把62570ab0-9260-11ed-a259-fa163efb5f25改成62570ab0-9260-11ed-a259-fa163efb5f26） - 启动服务：
sudo systemctl start mysql（Docker 用docker start mysql-slave）
重启后立刻验证：SHOW VARIABLES LIKE 'server_uuid'; —— 必须和主库不同，且不能和之前一样。
为什么不能删 auto.cnf 让 MySQL 自动重生成？
MySQL 8.0+ 在检测到 auto.cnf 缺失时，会尝试从 ibdata1 或 GTID 状态中提取旧 UUID 并写回，导致“删了又变回来”。这不是 bug，是设计行为：
- GTID 模式启用时，UUID 被绑定进事务日志元数据，删除文件不等于清除身份
- 某些云平台或容器镜像预置了 UUID 生成逻辑，跳过 auto.cnf 仍会复用缓存值
- 直接删文件还可能触发
mysqld启动失败（报错Failed to generate a new server UUID）
所以最稳的方式是：停服务 → 备份 → 手动改值 → 启动。别图省事。
修复后必须重配复制链路
UUID 改完只是解除了阻塞，但复制坐标已失效。接下来必须重做主从关系：
- 在从库执行
RESET SLAVE ALL;（注意是ALL，清空 relay log 和 master info repo） - 用主库当前的
SHOW MASTER STATUS;输出，重新执行CHANGE REPLICATION SOURCE TO ...（MySQL 8.0.23+ 语法，不是旧版CHANGE MASTER TO） - 再
START SLAVE;，然后SHOW SLAVE STATUS\G确认Slave_IO_Running: Yes且无Last_IO_Error
容易忽略的一点：RESET SLAVE ALL 会清空 source_host 等连接信息，所以必须重跑 CHANGE REPLICATION SOURCE TO，漏掉这步，IO 线程看似启动了，其实连的是空配置。
