怎么看 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: Yes
Slave_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，结合网络、系统、主库状态一起看。
