Slave_IO_Running 为 Connecting 的根本原因常是 slave_net_timeout 超时导致主动重连,而非网络或认证失败;需检查并调大该值(如设为7200),配合配置 MASTER_HEARTBEAT_PERIOD(如10.0),且必须执行 STOP SLAVE; START SLAVE; 才生效。

Slave_IO_Running 一直 Connecting,但网络和用户都正常
这种情况大概率不是连不上,而是连上后很快断开,然后重连——slave_net_timeout 在背后起作用。它控制从库 IO 线程在没收到主库任何数据时,等待多久就主动断开连接。默认值是 3600 秒(1 小时),但主库如果长时间没写入,IO 线程就会超时断开,日志里反复出现 Connecting 状态,Last_IO_Error 可能为空或只显示 “The slave I/O thread stops because a fatal error is encountered when it tries to get the binary log…”。
真正的问题在于:这个超时和主库心跳无关,它只看“有没有新 binlog 数据”,而不是“连接是否还活着”。所以即使主从 TCP 连接本身稳定,只要主库安静超过 slave_net_timeout,IO 线程就强制重连。
- 检查当前值:
SHOW VARIABLES LIKE 'slave_net_timeout'; - 临时调大(比如设为 7200):
SET GLOBAL slave_net_timeout = 7200; - 永久生效需写入从库
my.cnf的[mysqld]段:slave_net_timeout = 7200 - 改完必须重启复制:
STOP SLAVE; START SLAVE;,否则不生效
启用了 MASTER_HEARTBEAT_PERIOD,但 IO 线程还是断开
MySQL 5.7+ 支持主库主动发心跳包(MASTER_HEARTBEAT_PERIOD),但这个机制和 slave_net_timeout 是两套逻辑:心跳只防止主库单方面断连,而 slave_net_timeout 是从库单方面判断“我收不到东西了,先撤”。两者不互斥,必须同时配置才稳。
- 主库不需要额外配置,只要从库
CHANGE MASTER TO时指定了心跳周期即可 - 例如设置 10 秒心跳:
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10; - 注意单位是秒,且必须是浮点数(如
10.0),整数会报错 - 心跳值必须小于
slave_net_timeout,否则没意义;建议设为后者的 1/3~1/2
复制中断后 Last_IO_Error 显示 “error reconnecting to master” 却查不到网络问题
这种报错常被误判为防火墙或 DNS 问题,但实际可能是 slave_net_timeout 触发重连后,主库刚好在那一瞬间拒绝新连接(比如 max_connections 打满、复制用户密码过期、SELinux 拦截重连请求)。重连失败的错误会被记录为“reconnecting to master”,掩盖了真正的根因。
- 先确认重连是否真失败:在从库执行
mysql -h 主库IP -u 复制用户 -p -e "SELECT 1",模拟一次手动连接 - 查主库当前连接数:
SHOW STATUS LIKE 'Threads_connected';,对比max_connections - 检查主库错误日志中是否有 “Access denied for user” 或 “Too many connections”
- 不要只盯着
Last_IO_Error,配合SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Retrieved_Gtid_Set变化趋势一起看
为什么调小 slave_net_timeout 反而让复制更不稳定
设成 30 秒看似能更快发现故障,但实际会造成高频重连:主库轻微抖动、binlog 刷盘延迟、甚至网络瞬断都会触发 IO 线程断开再重建,每次重建都要握手、认证、定位位点,开销不小。尤其在 GTID 模式下,频繁重连还可能引发 Retrieved_Gtid_Set 不一致,导致后续同步跳变。
- 生产环境不建议低于 60 秒;高负载主库建议保持 1800~3600 秒区间
- 比调小 timeout 更有效的做法是:确保主库有稳定写入(哪怕定期
INSERT INTO heartbeat VALUES (NOW())),让 IO 线程始终有数据可收 - 监控重点应放在
Seconds_Behind_Master的持续增长,而非Slave_IO_Running的瞬时波动
真正容易被忽略的是:slave_net_timeout 修改后不会自动应用到已运行的 IO 线程,必须 STOP SLAVE; START SLAVE; 才 reload,这点和多数变量不同。很多运维改完变量就以为生效了,结果还在旧值下反复断连。


















