确认主从复制状态需执行show slave status\g，重点检查slave_io_running和slave_sql_running是否均为yes；任一为no即中断。启动用start slave（或指定线程），停止用stop slave（或指定线程），彻底清理用reset slave all。
如何确认主从复制当前状态
别急着启动或停止，先看它到底在不在跑。登录从库执行 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，影响其他从库或备份策略，从库上绝对不要执行。
