slave_io_running 为 connecting 或 no 通常因 slave_net_timeout 超时断连而非网络不通，需调大该值并配合 master_heartbeat_period、master_connect_retry 等参数优化重连机制，同时排查中间设备 tcp 连接中断问题。
Slave_IO_Running 一直 Connecting 或 No，但 telnet 通、账号权限正常
这大概率不是连不上，而是连上后被 slave_net_timeout 主动断开再重试。它只看“有没有新 binlog 数据”，不看 TCP 连接是否还活着。主库写入空闲期稍长（比如夜间），IO 线程就会超时断开，日志里反复出现 Connecting 状态，Last_IO_Error 可能为空或只提示 “The slave I/O thread stops because a fatal error is encountered…”。
检查当前值：SHOW VARIABLES LIKE 'slave_net_timeout';
临时调大（例如设为 7200）：SET GLOBAL slave_net_timeout = 7200;
永久生效需写入从库 my.cnf 的 [mysqld] 段：slave_net_timeout = 7200
改完必须执行：STOP SLAVE; START SLAVE;，否则不生效
GTID 模式下 IO 线程失败后根本不重试
MySQL 默认行为就是“连一次，失败就停”。Slave_IO_Running: No 且 Last_IO_Error 是 “error connecting to master”，说明压根没触发重连逻辑——根本没启用自动重连机制。
确认是否启用了 GTID：SELECT @@gtid_mode; 必须是 ON
检查 CHANGE MASTER TO 是否明确包含 AUTO_POSITION = 1（不是 0，也不能省略）
执行 SHOW SLAVE STATUS\G，看 Auto_Position 字段是否为 1；若为 0，调再小的 slave_net_timeout 也白搭
slave_net_timeout 不是重连间隔，只是“读超时阈值”：它决定 IO 线程等多久没收到数据就断开连接，之后才可能触发重连——但重连是否发生、隔多久重、重几次，由 MASTER_CONNECT_RETRY、MASTER_RETRY_COUNT 和 MASTER_HEARTBEAT_PERIOD 共同控制
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
网络抖动后重连延迟高、恢复慢
默认 slave_net_timeout 在 5.7.7+ 是 60 秒，老版本是 3600 秒。设太大（如 3600）会让抖动后延迟数分钟才感知断连；设太小（如 5 或 10）又会导致公网偶发丢包就频繁断连。
跨机房或云上 VPC 建议设为 30，局域网可设 60
必须配合 MASTER_HEARTBEAT_PERIOD（建议设为 slave_net_timeout / 2），否则心跳发得太晚，超时仍会触发断连
MASTER_CONNECT_RETRY 控制每次重试前等待秒数，默认 60；可通过 CHANGE MASTER TO MASTER_CONNECT_RETRY = 10 缩短
MASTER_RETRY_COUNT 控制总重试次数，默认 86400（即 60 天），设为 0 表示无限重试
所有参数修改后都需执行：STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; 才生效，SET GLOBAL 不会重建连接
中间设备（防火墙/NAT/SLB）悄悄掐断连接
MySQL 自身不控制底层 TCP keepalive 行为。当中间有防火墙、NAT 设备或云厂商负载均衡时，它们常默认 300 秒无流量就清空连接表项——此时即使 MySQL 的 slave_net_timeout 设得再大也没用，连接早被中间设备掐断了。
不要只盯着 MySQL 参数，得查系统级 tcp_keepalive 设置（/proc/sys/net/ipv4/tcp_keepalive_time 等）
生产环境建议在从库侧用 tcpdump 抓包，过滤 tcp.analysis.lost_segment 或观察 TCP Retransmission 次数突增段；云环境务必在数据库服务器侧抓，避免中间跳数隐藏真实丢包点
真正麻烦的是：这些断连往往不报错，Seconds_Behind_Master 看似正常，但 Retrieved_Gtid_Set 和 Executed_Gtid_Set 差值在缓慢扩大——你得主动盯这个差值，而不是只看线程状态
