物理备份恢复后立刻报13117错误，是因为auto.cnf文件被原样复制，导致主从server_uuid重复；必须在启动mysql前删除该文件，并确保server-id唯一，且reset slave all不能替代删除auto.cnf操作。
物理备份恢复后为什么立刻报13117错误？
因为auto.cnf文件被原样复制过来了。MySQL在首次启动时生成server_uuid并写入/var/lib/mysql/auto.cnf，这个值不会随数据变更而更新——它只在第一次初始化时创建。用xtrabackup或mysqldump --all-databases恢复后，如果没手动清理或跳过该文件，从库就会和主库（或其它克隆实例）拥有完全相同的server_uuid，I/O线程一连接就触发Last_IO_Errno: 13117。
恢复前必须做的三件事
别等报错再补救。物理备份恢复流程里，这三步必须在systemctl start mysql之前完成：
- 确认目标目录下
/var/lib/mysql/auto.cnf已存在且内容与主库一致（可用cat /var/lib/mysql/auto.cnf快速比对） - 停止MySQL服务：
systemctl stop mysql（若已启动） - 删除或重命名该文件：
mv /var/lib/mysql/auto.cnf /var/lib/mysql/auto.cnf.bak
恢复后启动失败？检查server-id是否冲突
server_uuid不同了，但server-id仍可能重复——这是另一个常见连环坑。即使auto.cnf重建成功，若/etc/my.cnf中server-id没改，或者MySQL没加载该配置，SHOW VARIABLES LIKE 'server_id'仍可能返回和主库一样的值，导致Last_IO_Error提示equal MySQL server ids。
验证方式：
- 执行
mysql -e "SHOW VARIABLES LIKE 'server_id';"，确认输出值唯一 - 检查
my.cnf中server-id是否显式设置且不为1（主库常用值） - 运行
mysqld --verbose --help | grep "Default options"确认配置文件路径是否被正确读取
RESET SLAVE ALL不是万能的
有人以为执行RESET SLAVE ALL;就能抹掉UUID问题，其实不行。这个命令只清空复制元数据（如master.info、relay-log.info），但auto.cnf是实例级身份标识，不受其影响。更危险的是：如果先执行了RESET SLAVE ALL再删auto.cnf，重启后MySQL会生成新UUID，但gtid_purged可能残留旧主库的GTID集合，造成后续CHANGE MASTER TO时报GTID set mismatch。
正确顺序永远是：停服务 → 删auto.cnf → 启动 → STOP SLAVE → RESET SLAVE ALL → 重新CHANGE MASTER TO。
