网络中断导致Slave_IO_Running为No时，需先验证真实断连：检查SHOW SLAVE STATUS、telnet端口、复制账号权限、主库skip-networking/max_connections、错误日志及认证插件兼容性；调整slave_net_timeout=30与master_retry_count=86400，并启用MASTER_HEARTBEAT_PERIOD=5000；重连后Seconds_Behind_Master跳变属正常积压追赶，勿跳过事件；长期延迟需查I/O、中继日志空间及大事务阻塞；启用并行复制、expire_logs_days≥7、relay_log_recovery=ON及GTID模式提升容错能力。
网络中断导致 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 是否能自我修复——这些配置一旦漏掉，下次中断可能就得重建从库。
