网络中断导致 Slave_IO_Running
为 No，先确认是不是真断了
网络中断是最常见的 IO 线程失败原因，但别急着重连——先排除误判。执行
SHOW SLAVE STATUS\G，如果
Slave_IO_Running: No且
Last_IO_Error类似
error connecting to master或
timeout，再往下查。 用
telnet 主库IP 3306或
nc -zv 主库IP 3306测试端口连通性（注意：MySQL 默认不监听公网，检查
bind_address和防火墙） 确认从库配置的复制账号在主库上真实存在，且授权包含
REPLICATION SLAVE权限（
SHOW GRANTS FOR 'repl'@'%';） 检查主库是否启用了
skip-networking，或
max_connections耗尽导致拒绝新连接 查看从库错误日志：
tail -n 50 /var/log/mysqld.log，留意是否有
authentication plugin不兼容（如 caching_sha2_password 在旧客户端不可用）
slave_net_timeout
和 master_retry_count
怎么调才不反复断
默认
slave_net_timeout=60，即 IO 线程空闲 60 秒就主动断开；若主库写入稀疏，又没心跳机制，就会“假中断”。这不是故障，是设计行为。 建议设为
slave_net_timeout = 30（更敏感）+
master_retry_count = 86400（1天内无限重试），避免短暂抖动触发中断 MySQL 5.7+ 支持
MASTER_HEARTBEAT_PERIOD（单位毫秒），例如
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 5000;，强制主库每 5 秒发心跳包，让 IO 线程始终保持活跃 注意：调整后必须
STOP SLAVE; START SLAVE;才生效，仅 reload 配置无效
重连后数据没丢，但 Seconds_Behind_Master
突然跳变很大
这不是同步失败，而是网络恢复后，从库批量拉取积压 binlog 导致的正常现象。关键看后续是否持续下降。
不要手动跳过事件（sql_slave_skip_counter），IO 中断不产生 SQL 执行错误，跳过会直接丢数据 若延迟长期卡住不动，检查从库磁盘 I/O（
iostat -x 1）、中继日志写满（
df -h /var/lib/mysql）、或是否被大事务阻塞（
SHOW PROCESSLIST查看
State为
Reading event from the relay log的线程是否卡住） 启用并行复制可加速追赶：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 4;（需主库也开启
binlog_transaction_dependency_tracking）
容错不能只靠“自动重连”，得有兜底动作
网络中断本身可自愈，但若中断期间主库发生 failover、binlog 被轮转清理、或从库意外重启丢失 relay log，单靠重连就失效了。
主库必须设置expire_logs_days = 7（至少保留一周 binlog），避免从库重连时所需日志已被删 从库开启
relay_log_recovery = ON（MySQL 5.6+），崩溃重启后自动重建 relay log，防止 relay log 损坏导致复制卡死 生产环境强烈建议启用 GTID：
gtid_mode = ON+
enforce_gtid_consistency = ON，这样网络中断恢复后无需人工计算 binlog 位置，
START SLAVE自动续传 监控项不能只盯
Slave_IO_Running，还要告警
Seconds_Behind_Master > 300且持续 2 分钟以上——延迟暴增往往是网络抖动+大事务叠加的信号
网络中断本身不可怕，可怕的是把它当成孤立事件处理。真正决定容错能力的，是 binlog 保留策略、GTID 是否启用、以及 relay log 是否能自我修复——这些配置一旦漏掉，下次中断可能就得重建从库。
