IO 线程断了怎么查
IO 线程断说明从库拿不到 binlog，原因集中在四类：网络不通、复制账号认证失败、主库 binlog 已被清理、主库位点或配置变更。定位入口是 SHOW REPLICA STATUS 里的 Last_IO_Errno 与 Last_IO_Error，错误码能直接指向类别。
基本信息
| 适用 | MySQL 5.7 / 8.0 异步复制 |
|---|---|
| 定位入口 | Last_IO_Errno、Last_IO_Error、Replica_IO_State |
| 前置检查 | 复制账号权限与来源主机、主库 log_bin 与 port 连通 |
| 恢复动作 | 修因后 STOP REPLICA IO_THREAD 再 START REPLICA IO_THREAD |
常见报错码读法
| 错误码 | 含义 | 处置方向 |
|---|---|---|
| 2003 | 连不上源端（Can't connect） | 网络、防火墙、端口与 bind-address |
| 1045 | 认证失败 | 账号密码、来源主机限制、密码策略变更 |
| 1236 | 源端 binlog 已被清理，位点丢失 | 从备份重建从库，或人工定位可用起点 |
| 2013 | 连接中断（Lost connection） | 网络抖动、超时参数、主库被重启 |
| 1593 / 1236 变体 | 位点或 GTID 与源端不一致 | 核对 GTID_PURGED 与 gtid_mode 设置 |
排查与重连
排查与重连
SHOW REPLICA STATUS\G # 先读 Last_IO_Errno / Last_IO_Error
-- 从库侧验证网络与端口
-- telnet 10.0.0.10 3306 或 nc -vz 10.0.0.10 3306
-- 主库侧确认账号与权限
-- SELECT user, host FROM mysql.user WHERE user='repl';
STOP REPLICA IO_THREAD; # 修因后单独重启 IO 线程
START REPLICA IO_THREAD;
SHOW REPLICA STATUS\G # 确认 Replica_IO_Running 变为 Yes典型使用场景
- 主库维护重启后从库未自动恢复，确认是网络抖动还是账号问题
- 主库手工 PURGE 后从库报 1236，评估重建还是改位点
- 账号密码轮换后复制中断，核对复制账号与来源主机
- 云上安全组调整导致端口不通，快速判定是网络层还是认证层
- GTID 环境下切换主库，确认 AUTO_POSITION 与 GTID 集合配置正确
1236 无法靠重启复制解决：binlog 已经被删掉，只能从备份重建从库或人工定位仍可用的起点，反复 START REPLICA 只会重复失败。
主库的 binlog 保留窗口要纳入维护检查清单：清理、迁移、升级等操作都可能触发 1236，事后追溯成本远高于事前确认。
断链处置顺序
- 先读 Last_IO_Errno 与 Last_IO_Error，不要第一反应就重启复制
- 网络类报错（2003/2013）从从库侧探端口，确认安全组、防火墙与端口放行情况
- 认证类报错（1045）核对复制账号密码、来源主机限制，以及主库近期的密码策略变更
- 位点类报错（1236）评估重建成本：数据量小直接重新导快照，数据量大从备份恢复更稳
- 恢复后把原因与处置写进变更记录，并检查其他从库是否存在同类风险