slave_io_running为connecting或no的真实原因多是slave_net_timeout超时导致主动断连,而非网络不通;需先查该变量值、主库binlog是否更新,并调大timeout(如7200)且配置master_heartbeat_period=10.0后执行stop slave; start slave;生效。

Slave_IO_Running 为 Connecting 或 No 的真实原因
这不是“连不上”,而是“连上了又断了”或“根本没发起到连接”。Slave_IO_Running 状态卡在 Connecting,多数情况不是网络不通,而是从库主动放弃连接——背后是 slave_net_timeout 在起作用。它默认 3600 秒(1 小时),只要主库在这段时间内没产生新 binlog,IO 线程就强制断开重连,日志里反复出现 Connecting,Last_IO_Error 却为空或只显示 “fatal error when trying to get the binary log”。
排查时别急着查防火墙或 ping 主库 IP,先执行:SHOW VARIABLES LIKE 'slave_net_timeout';
再看主库是否真有写入(SHOW MASTER STATUS\G 中 Position 是否变化)。
- 若主库安静,调大
slave_net_timeout(如设为7200),并配合CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10.0; - 改完必须执行
STOP SLAVE; START SLAVE;,否则不生效 - 心跳值(
MASTER_HEARTBEAT_PERIOD)必须是浮点数,且要小于slave_net_timeout,否则无效
认证失败导致的静默连接中断
MySQL 8.0+ 默认用 caching_sha2_password 插件,但很多旧客户端(比如 mysql-connector-java Unknown error 或 Slave_IO_Running: No,而 Last_IO_Error 可能只显示 “error reconnecting to master”。
确认方式:SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';
如果返回 caching_sha2_password,就得检查从库所用客户端是否兼容。
- 临时方案(仅限测试):连接串加
?allowPublicKeyRetrieval=true&useSSL=false - 长期方案:主库重建复制账号,改用
mysql_native_password:ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 别忽略驱动版本——哪怕 MySQL 版本一致,驱动不匹配照样连不上
容器或云环境下的 DNS 与网络解析陷阱
在 Docker 或 Kubernetes 中,CHANGE MASTER TO MASTER_HOST='mysql-master' 看似没问题,但实际可能解析失败。容器启动时 DNS 缓存未就绪、服务名未注册、或 /etc/hosts 被覆盖,都会让从库压根无法解析主机名,IO 线程卡在 Connecting,错误日志里却只有模糊的 “Can't connect to MySQL server”。
验证方法不是只看 docker exec -it slave ping mysql-master,而要在从库容器内直接模拟复制连接:mysql -h mysql-master -P 3306 -u repl_user -p'xxx' -e "SELECT 1"
- 失败时优先检查容器网络模式:确保主从在同一个自定义 bridge 网络,而非默认
bridge - K8s 环境下,确认 Service 名称、headless Service 配置、以及 Pod 启动顺序(从库不能早于主库就绪)
- 避免用 localhost 或 127.0.0.1 作为
MASTER_HOST——这会让从库连自己
被忽略的系统级资源限制
Unknown error 和 Connection refused 往往是表象,根源常在系统层:磁盘满、SELinux 拦截、max_connections 打满、或 socket 文件权限异常。这些不会直接写进 Last_IO_Error,但会让连接在 TCP 握手后立即断开。
关键动作:SHOW VARIABLES LIKE 'log_error'; → 找到错误日志路径 → tail -f /path/to/error.log 实时观察,同时在从库执行 START SLAVE;
- 重点盯三类日志行:“No space left on device”、“Plugin 'caching_sha2_password' is not loaded”、“Aborted connection”
- 检查主库
max_connections是否耗尽:SHOW STATUS LIKE 'Threads_connected'; - SELinux 启用时,
setsebool -P mysqld_connect_any on可放行跨容器连接
Last_IO_Error 是起点,但得顺着它往底层钻——日志时间戳、客户端驱动版本、容器 DNS 解析链,缺一不可。











