mysql从库重启后复制线程默认不启动，属正常设计行为；因start slave不持久化，服务重启后slave_io_running和slave_sql_running均为no，需手动检查错误并执行start slave。
MySQL从库重启后复制线程默认不启动
MySQL 服务重启后，Slave_IO_Running 和 Slave_SQL_Running 都是 No，这是正常行为，不是故障。MySQL 设计上就禁止自动启动复制线程，防止网络未就绪、主库不可达、或配置残留导致数据错乱。
关键点在于：START SLAVE 操作不会被持久化到磁盘，只存在于内存中；服务一重启，状态就清空。你之前执行过 START SLAVE，不代表下次重启还能继续跑。
为什么有些从库“看起来”一启动就复制了？
这通常不是 MySQL 默认行为，而是人为干预的结果：
-
skip-slave-start没配（即配置文件里没写），且上次START SLAVE成功后 MySQL 实例未异常终止——部分旧版本（如 5.6）可能从master.info恢复状态，但不可靠、不推荐依赖 -
my.cnf里漏写了skip-slave-start = ON，而运维脚本或 systemd service 文件在ExecStartPost里加了mysql -e "START SLAVE;" - 用了 MHA、Orchestrator 等高可用工具，它们监听到实例上线后主动调用
START SLAVE（例如 Orchestrator 的PostStartSlaveStart: true）
如何确认并强制禁用自动启动？
别猜，直接查：
- 运行
SELECT @@skip_slave_start;—— 返回ON表示已禁用自动启动；返回OFF就得改配置 - 检查配置文件：
grep skip-slave-start /etc/my.cnf，若无输出，说明没显式控制，行为不确定 - 正确做法：在
[mysqld]段加上skip-slave-start = ON，然后systemctl restart mysqld（SET GLOBAL不持久）
重启后必须手动 START SLAVE 吗？
是的，但要带条件：
- 先执行
SHOW SLAVE STATUS\G，重点看Last_IO_Error和Last_SQL_Error—— 如果有错误，START SLAVE会立刻失败甚至掩盖根因 - 常见前置问题：主库连不上（
Last_IO_Error含Connection lost或认证失败）、server-uuid冲突（克隆机未改/var/lib/mysql/auto.cnf）、master.info损坏（需STOP SLAVE后删掉再重配） - 只有
Slave_IO_Running: No且Last_IO_Error为空时，才安全执行START SLAVE
真正容易被忽略的是：断电或强制 kill 后，auto.cnf 和 master.info 这两个文件最容易损坏或重复，比参数配错更隐蔽、更常导致“明明配置对却连不上”。
