断电重启后slave_io_running为no，应先查last_io_error：若为空或“connection lost”，需检查auto.cnf中server-uuid是否重复；若报server-id冲突，需修正my.cnf；若skip-slave-start=on，则须在my.cnf中显式设为off并重启；master.info损坏则需stop slave后删除并重启再重新配置。
先看 Last_IO_Error，别急着 START SLAVE
断电重启后 Slave_IO_Running: No，本质是 I/O 线程无法重建与主库的连接，不是“丢了”而是主动停了。关键线索全在 Last_IO_Error 字段里——执行 SHOW SLAVE STATUS\G 后直接定位它，跳过其他字段。
常见报错及对应动作：
-
Last_IO_Error: error connecting to master 'repl@10.0.1.5:3306'→ 网络或认证失败，不是配置写错了，是根本连不上 -
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids→server-id冲突，检查主从双方my.cnf的[mysqld]段 -
Last_IO_Error为空或只显示Connection lost→ 很可能是auto.cnf中server-uuid重复（克隆/快照后未修改）
检查 auto.cnf 是否被克隆导致 server-uuid 冲突
硬件断电后若从库是通过 VM 克隆、Docker 镜像复用或直接拷贝数据目录恢复的，/var/lib/mysql/auto.cnf 极大概率和主库一模一样。MySQL 启动时读取该文件生成唯一标识，重复则主库静默拒绝连接，I/O 线程卡在 Connecting 或直接变 No。
操作步骤：
- 在从库执行
find / -iname "auto.cnf" 2>/dev/null找到文件路径（通常为/var/lib/mysql/auto.cnf） - 备份原文件：
cp /var/lib/mysql/auto.cnf /tmp/auto.cnf.bak - 编辑该文件，修改
server-uuid值为合法 UUID（如a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8），确保与主库及其他从库不重复 - 重启 MySQL：
systemctl restart mysqld（仅STOP SLAVE; START SLAVE;不生效）
确认 skip-slave-start 是否被意外启用
MySQL 5.7+ 默认 skip-slave-start = OFF，但运维误加 skip-slave-start = ON 到 my.cnf 是常见原因。断电重启后 MySQL 实例起来，但复制线程压根不初始化。
验证和修复：
- 查当前值：
SELECT @@skip_slave_start;，返回ON就必须改配置 - 编辑
my.cnf，在[mysqld]段确保有skip-slave-start = OFF（显式写出，别依赖默认） - 改完必须重启 MySQL 生效，
SET GLOBAL skip_slave_start = OFF不持久 - 重启后执行
START SLAVE;，再查状态
master.info 损坏或残留旧参数需清理
断电可能让 master.info 文件写入中断，内容错乱；或之前多次失败配置残留错误参数（如已失效的 Master_Log_File），导致新连接仍沿用旧值。
安全清理方式：
- 先执行
STOP SLAVE; - 确认 MySQL 已停止写入该文件（无活跃复制），再删：
rm -f /var/lib/mysql/master.info - 注意：删完必须重启 MySQL 服务，否则下次启动会按旧缓存重建该文件
- 重启后重新执行
CHANGE MASTER TO ...（确保参数准确），再START SLAVE;
真正容易被忽略的是：server-uuid 冲突不会报明确错误，Last_IO_Error 可能为空；而 master.info 损坏后即使网络通、权限对，I/O 线程也起不来——这两点必须手动验证，不能只靠 START SLAVE 碰运气。
