slave_net_timeout 应设为网络P99延迟的3–4倍（如800ms则设3或4秒），并配合SOURCE_CONNECTION_AUTO_RETRY=1和SOURCE_RETRY_COUNT=N，且relay_log_recovery=ON才真正有效。
slave_net_timeout 设为多少才真正有效
这个参数不是设得越小，主从就恢复得越快。它只控制「从库多久没收到主库心跳就判定连接断开」，不负责重连逻辑本身。MySQL 5.6+ 默认是 60 秒，但如果你的网络偶尔抖动 2–3 秒，设成 5 秒反而会引发频繁断连重试，加重 IO 和 binlog 位置错乱风险。
实操建议：
-
slave_net_timeout建议设为网络 P99 延迟的 3–4 倍（比如监控显示最大延迟 800ms，那就设3或4） - 必须配合
master_connect_retry（MySQL 8.0.22+ 已弃用，改用CHANGE REPLICATION SOURCE TO ... SOURCE_CONNECTION_AUTO_RETRY=1）才能触发自动重连 - 修改后需执行
STOP SLAVE; START SLAVE;才生效，仅SET GLOBAL不够
为什么改了 slave_net_timeout 还是不自动重连
最常见原因是复制线程根本没挂——只是 SQL 线程卡在某个事务里，IO 线程还在收日志，此时 slave_net_timeout 完全不触发。你看到的“中断”，其实是 Seconds_Behind_Master 持续增长，而非 Slave_IO_Running: No。
排查要点：
- 先查
SHOW REPLICA STATUS\G（或SHOW SLAVE STATUS\G），重点看Slave_IO_Running和Slave_SQL_Running是否都为Yes - 如果 IO 是 Yes、SQL 是 No，说明是回放失败（比如主键冲突、DDL 不兼容），
slave_net_timeout压根不参与 - 检查错误日志里有没有
Got timeout reading communication packets或The slave I/O thread stops because a fatal error is encountered when it tries to get the binary log from master
MySQL 8.0.22+ 自动重连必须打开的两个开关
旧版本靠 master_retry_count + master_connect_retry 组合实现，新版本统一收口到复制源配置里，漏掉任意一个都会让自动重连失效。
关键操作：
- 执行
CHANGE REPLICATION SOURCE TO SOURCE_CONNECTION_AUTO_RETRY=1—— 这是开启自动重连的总开关 - 同时必须设置
SOURCE_RETRY_COUNT = N（比如10），否则默认为 0，等于没开 - 这两个值必须在
START REPLICA前配置，运行中修改需先STOP REPLICA - 注意：不是所有错误都重试，比如认证失败、SSL 握手失败这类明确拒绝型错误，重试机制直接跳过
超时后重连，binlog 位置会不会丢
不会丢，但可能重复或跳过一小段——取决于 relay_log_recovery 是否开启和 relay log 的刷盘策略。
真实影响链：
- IO 线程断开重连时，会从本地
master_log_file和master_log_pos（即上次成功写入 relay log 的位置）继续拉取，只要 relay log 没被清理，位置就准确 - 如果
relay_log_recovery=OFF（默认），重启后可能读到损坏或不完整的 relay log，导致 SQL 线程报错停住 - 强烈建议设为
ON：每次START REPLICA时自动丢弃未应用完的 relay log，从主库重新拉取，牺牲一点性能换一致性 - 别忘了配
relay_log_purge=ON，否则磁盘爆满也会间接导致 IO 线程异常退出
自动重连不是设个超时就万事大吉，它依赖 IO 线程真实断开、重试开关打开、relay log 可恢复这三个条件同时满足。最容易被忽略的是 relay_log_recovery 关闭状态下，看起来重连成功了，其实 SQL 线程卡在坏日志里不动。
