如何确认主从复制当前状态
别急着启动或停止，先看它到底在不在跑。登录从库执行
SHOW SLAVE STATUS\G，重点盯住两行：
Slave_IO_Running：是否正在拉取主库 binlog（应为
Yes）
Slave_SQL_Running：是否正在回放中继日志（也应为
Yes）
只要任一为
No，说明复制已中断——此时“启动”实际是“恢复”，而“停止”可能根本没必要操作。
启动复制：从 STOP 到 START 的关键路径
复制不是靠重启 MySQL 服务来启停的，而是靠 SQL 命令控制两个独立线程。从库上执行：
START SLAVE;—— 最常用，同时启动 IO 和 SQL 线程
START SLAVE IO_THREAD;—— 只拉日志，不执行（适合补日志但暂不应用）
START SLAVE SQL_THREAD;—— 只执行 relay log，不拉新日志（适合追平积压）
执行后务必再查一次
SHOW SLAVE STATUS\G，确认两个
Running字段都变成
Yes，且
Seconds_Behind_Master开始下降才表示真正动起来了。
停止复制：STOP SLAVE 的三种用法和陷阱
STOP SLAVE;看似简单，但不同场景要选对子命令： 临时维护（比如升级从库）→ 用
STOP SLAVE;，完整暂停，安全 只暂停写入、保留中继日志供后续分析 → 用
STOP SLAVE SQL_THREAD;主库网络抖动，想缓存日志但不执行 → 用
STOP SLAVE IO_THREAD;
⚠️ 容易踩的坑：
STOP SLAVE;后如果直接改配置或删 relay log 文件，再
START SLAVE可能报错
Could not find first log file name in binary log index file——因为
master.info还记着旧位置，但文件已被清空。
彻底断开复制关系：RESET SLAVE ALL 是终极清理
如果明确不再恢复复制（比如拆集群、测试环境回收），不能只停线程，必须清元数据：
RESET SLAVE ALL;（MySQL 5.7+ 推荐）→ 彻底删除
master.info、
relay-log.info、所有 relay log 文件，
SHOW SLAVE STATUS返回空结果
RESET SLAVE;（旧版本兼容）→ 仅清空内存状态，保留 relay log 文件和 info 文件，重启 MySQL 后可能自动重连主库
注意：
RESET MASTER是主库命令，会清空所有 binlog，影响其他从库或备份策略，从库上绝对不要执行。
