确认IO线程真停需看Slave_IO_Running为No且不自动恢复，Seconds_Behind_Master变为NULL，Relay_Log_Space停止增长；若需永久停止，应执行RESET SLAVE ALL并配置skip-slave-start=1。
STOP SLAVE 后怎么确认 IO 线程真停了
执行 STOP SLAVE 或 STOP SLAVE IO_THREAD 后，不能只信命令没报错——得看状态是否真实反映为“已停止”。关键就是 Slave_IO_Running 字段必须是 No，且不再恢复为 Yes。
-
SHOW SLAVE STATUS\G中Slave_IO_Running: No是硬性指标；若仍是Yes，说明命令未生效（常见于权限不足、SQL 线程卡死拖住 IO 线程） - 检查
Seconds_Behind_Master是否变为NULL：IO 线程停后，从库无法再拉取新 binlog，这个值会立刻变NULL（不是缓慢增长或维持不变） - 观察
Master_Host和Master_Port是否仍存在：如果RESET SLAVE ALL之前就停了 IO，这些连接信息还在；但若已执行RESET SLAVE ALL，字段会清空，此时Slave_IO_Running也必然为No，不过这是“配置级停止”，不是“运行级暂停” - 别依赖
ps aux | grep mysql查进程：MySQL 5.7+ 的 IO 线程不对应独立系统进程，ps看不到它是否在跑
为什么 Slave_IO_Running = No 还可能“假停”
现象是 SHOW SLAVE STATUS\G 显示 Slave_IO_Running: No，但过几秒自动变回 Yes——这不是你操作失误，而是 MySQL 自动重连机制在起作用。这通常发生在启用了 master_retry_count（默认 86400 次）和 master_connect_retry（默认 60 秒）的场景下。
- 主库临时不可达（如网络抖动、防火墙拦截），IO 线程断开后进入重试队列，状态短暂为
No，随后自动重连成功 → 又变Yes - 从库配置了
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1（GTID 模式），但主库 binlog 被 purge，IO 线程无法定位起始位置，反复失败重试，状态在No/Yes间跳变 -
Last_IO_Error字段有内容但被忽略：比如报错error connecting to master 'repl@10.0.1.100:3306' - retry-time: 60 retries: 1，说明它正在重试，No是瞬态，不是终态
真正安全停止 IO 线程的实操步骤
要确保 IO 线程不再尝试重连、不残留连接、不继续写 relay log，光靠 STOP SLAVE 不够，得配合清理动作。
- 先执行
STOP SLAVE IO_THREAD;，再立刻查SHOW SLAVE STATUS\G确认Slave_IO_Running为No - 检查
Relay_Log_Space是否停止增长：持续上涨说明 relay log 还在写入（可能是 SQL 线程仍在消费旧日志，但 IO 已停）；若它稳定不变，才说明 IO 停得干净 - 若后续不打算再同步，直接执行
RESET SLAVE ALL;—— 它会清空master.info文件、删除所有 relay log 文件，并重置Slave_IO_Running和Slave_SQL_Running为No - 验证：执行完
RESET SLAVE ALL后，SHOW SLAVE STATUS\G中Master_Host、Master_Port、Master_User全为空，Relay_Master_Log_File为空字符串，Slave_IO_Running和Slave_SQL_Running都是No
容易被忽略的两个细节
很多运维在确认 Slave_IO_Running: No 后就以为万事大吉，结果发现从库还在悄悄拉日志，或者重启后自动恢复同步——问题往往出在这两个地方。
-
my.cnf里写了skip-slave-start = 0（或压根没配）：MySQL 重启时默认会自动启动复制线程。要永久禁用，必须显式设为skip-slave-start = 1，否则STOP SLAVE只是临时操作 - 从库开启了
log_slave_updates = ON：即使 IO 线程停了，如果该从库本身又是其他节点的主库（级联复制），它的 binlog 还在写，容易误判为“还在同步”
