确认是uuid冲突：执行show slave status\g，若last_io_errno为13117或1593且last_io_error含“equal mysql server uuids”，再查主从server_uuid相同即可确诊；需搜索并修改auto.cnf中的server-uuid，停服备份后用uuidgen生成新值覆盖写入，重启后执行reset slave all并重新配置复制。
确认确实是 UUID 冲突而非其他网络或权限问题
别急着改文件，先验证错误来源。从库执行 SHOW SLAVE STATUS\G，重点看这两项：Last_IO_Errno: 13117 或 Last_IO_Errno: 1593，且 Last_IO_Error 字段含 "equal MySQL server UUIDs"。再分别在主从库运行 SHOW VARIABLES LIKE 'server_uuid'; —— 如果返回值完全一样，就是它了。注意：server_id 不同不代表 server_uuid 就不同，两者无关。
找到并安全修改 auto.cnf 中的 server-uuid
auto.cnf 不一定在 /var/lib/mysql/auto.cnf，MySQL 启动时只读第一个找到的该文件。先全盘搜索：find / -name auto.cnf 2>/dev/null。常见位置还包括 /data/mysql/auto.cnf、/usr/local/mysql/data/auto.cnf。确认 datadir 路径更稳妥：mysql -e "SELECT @@datadir;"。操作前必须停服务：sudo systemctl stop mysql（Docker 环境用 docker stop mysql-slave）。备份原文件后，用 uuidgen 生成新值：echo "server-uuid=$(uuidgen)" > /var/lib/mysql/auto.cnf。切勿手动拼写 UUID，格式错会导致 mysqld 启动失败；也别只清空文件内容，要覆盖写入或彻底删除。
重置复制状态，否则旧元数据仍指向旧 UUID
改完 auto.cnf 只是第一步，复制线程内部缓存和 relay log 信息还绑定着旧标识。启动 MySQL 后，必须登录执行：STOP SLAVE; → RESET SLAVE ALL;（注意是 ALL，不是 RESET SLAVE）→ CHANGE MASTER TO ...（确保 MASTER_AUTO_POSITION=1 或对应 binlog 位点正确）→ START SLAVE;。执行完立刻查 SHOW SLAVE STATUS\G，Slave_IO_Running 和 Slave_SQL_Running 都为 Yes 才算真正恢复。
Docker 环境下 auto.cnf 持久化导致修改失效
容器里删了或改了 auto.cnf 却发现重启后 UUID 没变？大概率是 auto.cnf 被挂载为只读卷、ConfigMap 或初始化镜像自带该文件。验证方式：重启后立即对比 mysql -e "SELECT @@server_uuid;" 和 cat /var/lib/mysql/auto.cnf 是否一致。不一致说明文件被覆盖或读取了缓存。解决办法：要么在启动容器前用 docker cp 替换宿主机映射目录里的 auto.cnf，要么改用初始化脚本，在容器首次启动时生成新 UUID 并写入——不能依赖镜像内置的固定文件。
UUID 冲突本质是实例身份标识冲突，不是配置疏漏而是克隆/镜像复用的必然结果。最易被忽略的是 RESET SLAVE ALL 这一步，漏掉它，哪怕 UUID 已更新，复制线程仍会拒绝连接。
