MySQL从库重启后复制不自动启动是默认行为，因skip-slave-start默认为ON（5.7+）或slave-start未启用（5.6及以前），需手动执行START SLAVE并确认Slave_IO_Running和Slave_SQL_Running均为Yes。
MySQL从库重启后SHOW SLAVE STATUS显示Slave_IO_Running: No
MySQL从库重启后复制没自动恢复，这是默认行为——slave_start（5.6及以前）或skip-slave-start（5.7+）默认为ON，即不自动启动复制线程。
实操上必须显式开启：
- 执行
START SLAVE;（不是START SLAVE IO_THREAD;单启，除非你明确只拉日志不执行） - 检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否开始下降，Slave_SQL_Running和Slave_IO_Running都为Yes才算真正跑起来 - 若
START SLAVE报错（如Could not initialize master info structure），说明master.info文件损坏或权限异常，需停库后手动清理再重启
如何让MySQL从库开机/重启后自动启动复制
靠配置项skip-slave-start反向控制：它实际是“跳过启动”，设为OFF才允许自动启。但注意版本差异：
- MySQL 5.6 及更早：在
my.cnf的[mysqld]段加slave-start = 1（已废弃，但部分旧环境仍认） - MySQL 5.7+：必须设
skip-slave-start = OFF（默认就是OFF，但很多运维会误加ON到配置里） - 配置改完必须重启MySQL生效，仅
SET GLOBAL不持久
验证方式：SELECT @@skip_slave_start;返回OFF才算对。
START SLAVE执行后立刻Seconds_Behind_Master还是NULL
这通常不是配置问题，而是SQL线程卡在某个事务上，常见于主库有大事务、从库有锁冲突、或GTID模式下gtid_executed与gtid_purged不一致。
- 先看
Slave_SQL_Running_State字段：如果是Waiting for dependent transaction to commit，说明被上游事务依赖阻塞 - 查
Last_SQL_Errno和Last_SQL_Error，常见如1032（行不存在）、1062（唯一键冲突），这类错误不会自动跳过，必须人工干预 - GTID环境下，若
Retrieved_Gtid_Set不为空但Executed_Gtid_Set为空，大概率是gtid_purged被清空或重置过，需用RESET MASTER+SET GTID_PURGED修复（慎用）
为什么systemd重启MySQL后复制仍不启动
因为systemd服务脚本本身不感知MySQL复制状态，它只管进程启停。即使skip-slave-start = OFF，也只影响MySQL实例初始化阶段，不保证复制线程一定跑起来。
- 最稳妥的做法是在
my.cnf中配skip-slave-start = OFF，并确保MySQL启动后能成功读取master.info（路径由relay_log_info_file和master_info_repository共同决定） - 如果用的是
master_info_repository = TABLE（推荐），数据存在mysql.slave_master_info表中，该表必须可写，且不能被FLUSH PRIVILEGES等操作意外清空 - 某些云厂商RDS或封装镜像会覆盖默认行为，需确认其启动脚本是否强制执行
STOP SLAVE
自动化的边界就在这里：MySQL只负责“按配置决定是否尝试启动复制”，不负责“启动失败后重试”或“错误后自愈”。一旦出错，得靠监控告警+人工介入，或者自己套一层crontab定期检查Slave_IO_Running状态并补START SLAVE——但这只是权宜之计，掩盖了根本问题。
