IO线程是否运行需查SHOW SLAVE STATUS\G中Slave_IO_Running值，仅Yes/No两种状态；为No表示彻底失败，常见原因包括网络不通、配置错误、权限不足、log_bin未开启、server_id重复或防火墙拦截。
怎么看 IO 线程是否在运行
直接查 SHOW SLAVE STATUS\G，重点看 Slave_IO_Running 字段。它只有两个合法值：Yes 或 No，没有中间状态。如果显示 No，说明 IO 线程根本没起来，不是卡住、不是延迟，是彻底失败。
常见原因包括：
- 主库网络不通（从库连不上主库的
3306端口） -
CHANGE REPLICATION SOURCE TO里配错了SOURCE_HOST或SOURCE_USER权限不足（该用户必须有REPLICATION SLAVE权限） - 主库没开
log_bin，或从库的server_id和主库重复 - 主库防火墙拦截了 binlog dump 请求，或者云厂商安全组没放行
IO 线程报错时怎么定位具体问题
SHOW SLAVE STATUS 里 Slave_IO_State 是空字符串或停留在 Connecting to master，基本就是连接层失败；如果出现类似 error connecting to master 'repl@10.0.1.100:3306' - retry-time: 60 retries: 1 的提示，就去检查 Last_IO_Error 字段。
典型错误和应对方式：
-
Access denied for user 'repl'@'x.x.x.x' (using password: YES)→ 主库上执行SHOW GRANTS FOR 'repl'@'%';，确认权限和 host 匹配 -
Could not find first log file name in binary log index file→ 从库配置的SOURCE_LOG_FILE在主库上已不存在，需重新CHANGE REPLICATION SOURCE TO指向当前有效的 binlog 文件 -
Got fatal error 1236 from master when reading data from binary log→ 多半是主库 binlog 被清理过，从库要重做同步
只靠 Seconds_Behind_Master 判断同步是否健康？不行
这个值为 0 只代表 SQL 线程追上了 IO 线程读到的位置，并不保证 IO 线程还在工作。比如 IO 线程崩溃后停止拉日志，SQL 线程把已缓存的 relay log 全执行完，Seconds_Behind_Master 就会变成 0，但实际早已不同步。
真正可靠的组合判断是：
Slave_IO_Running: YesSlave_SQL_Running: Yes-
Seconds_Behind_Master数值稳定（不是忽高忽低） -
Retrieved_Gtid_Set和Executed_Gtid_Set相等（GTID 模式下）
建议写个简单脚本定期查这三个字段，而不是只盯一个 Seconds_Behind_Master。
监控 IO 线程不能只看 MySQL 内部状态
MySQL 层面一切正常，不代表网络链路真的可靠。IO 线程可能处于“假活”状态：TCP 连接未断，但主库 binlog dump 线程已卡死或被 kill，从库收不到新事件。
更稳妥的做法是交叉验证：
- 在主库执行
SHOW PROCESSLIST，找状态为Binlog Dump GTID或Binlog Dump的线程，确认它存在且Time值持续增长 - 用
tcpdump抓从库到主库3306端口的包，看是否有持续的 binlog 数据流（注意别在生产高峰跑） - 对比主从的
SHOW MASTER STATUS和SHOW SLAVE STATUS中的 binlog 文件名和位置偏移，手动算差值
IO 线程的“活着”只是最低门槛，真正难的是确认它是否在**有效工作**——这需要跳出 MySQL，结合网络、系统、主库状态一起看。
