删除auto.cnf可解决uuid冲突，因mysql重启时会自动生成新唯一uuid；克隆环境导致多实例共用同一uuid，删文件后需彻底停止服务再重启，确保新uuid生效。
MySQL主从复制中UUID重复会导致IO线程直接拒绝启动，报错明确指向server UUIDs must be different，必须手动干预，不能靠重启或重连自动修复。
为什么删auto.cnf就能解决
MySQL在首次初始化时生成一个全局唯一UUID，写入/var/lib/mysql/auto.cnf并永久绑定该实例。克隆虚拟机、复制数据目录等操作会把原文件一起带过去，导致多台机器共用同一个UUID。MySQL服务启动时读取该文件，发现与主库冲突，立刻中止IO线程。
删除auto.cnf后，mysqld重启时会自动生成新UUID，且只影响本机，不干扰主库或其他从库。
- 必须先停掉MySQL服务，否则文件可能被进程占用，删除无效或失败
- 不要仅清空文件内容，要彻底
rm -f auto.cnf；留空文件仍会被读取，可能触发未知行为 - 确认
datadir路径——不是所有部署都用默认/var/lib/mysql，可通过mysql -e "SELECT @@datadir;"验证
auto.cnf删了但重启后UUID没变
说明mysqld没真正重新生成，常见于以下情况：
- 服务未完全停止，残留
mysqld进程还在运行，删完文件又被旧进程“恢复”了 - 使用
systemctl restart mysql但配置了Restart=always，导致服务在删除前就自动拉起 - 容器环境里
auto.cnf被挂载为只读卷或ConfigMap，物理删除不生效
验证方式：重启后立即执行mysql -e "SELECT @@server_uuid;"，再对比cat /var/lib/mysql/auto.cnf里的server-uuid字段是否一致。不一致说明文件被覆盖或读取了缓存。
比删auto.cnf更稳妥的替代做法
直接编辑auto.cnf风险低、可控性强，适合生产环境：
- 停服务后，用
uuidgen生成新值：uuidgen | tr '[:lower:]' '[:upper:]' - 手动修改
auto.cnf中server-uuid行，替换为新UUID（格式必须是8-4-4-4-12小写十六进制+短横，如5A9F3C2E-1B4D-5F8A-9C7E-2D1F4A6B8C0E） - 确保文件权限仍是
mysql:mysql，否则启动时报错Can't read from file auto.cnf
注意：server_id和server-uuid是两回事——前者在my.cnf里配，后者只存在auto.cnf，改错地方毫无作用。
改完UUID后复制还是连不上
UUID只是第一关，常见连环问题：
-
Slave_IO_Running: Connecting持续存在 → 检查主库bind_address是否监听0.0.0.0或从库IP，而非仅127.0.0.1 -
Last_IO_Error提示Access denied for user→ 主库上CHANGE MASTER TO用的复制账号没开远程权限，或密码含特殊字符未转义 - 从库
show slave status\G里Master_Host显示为localhost→CHANGE MASTER TO语句写错了IP，不是UUID问题
UUID冲突的错误信息非常具体，只要看到equal MySQL server UUIDs就锁定auto.cnf；其他报错别盲目删文件，容易引发二次故障。
