slave_net_timeout设定的是主从TCP连接空闲超时时间，非重连次数；超时后IO线程关闭连接并触发一次重连，之后需手动或脚本拉起。
slave_net_timeout 设定的是什么，不是重连次数
很多人以为 slave_net_timeout 是控制“重试几次”，其实它只是定义主从之间 TCP 连接空闲多久后断开——超时后 IO 线程会主动关闭连接，然后触发一次重连（仅一次），接着就停在那里等你手动 START SLAVE 或靠其他机制拉起。MySQL 本身不提供“自动重试 N 次”的内置参数。
常见错误现象：Seconds_Behind_Master 突然变成 NULL，SHOW SLAVE STATUS 里 Slave_IO_Running 变成 No，错误日志出现 error connecting to master 或 Lost connection to MySQL server during query。
-
slave_net_timeout默认是 3600 秒（1 小时），对生产环境太长，网络抖动后主从卡住很久才发现 - 设太小（比如 10 秒）会导致频繁断连重连，尤其在大事务复制或网络延迟略高时
- 这个值只影响 IO 线程，SQL 线程挂了它不管
真正能减少人工干预的配置组合
靠单个参数没法实现“自动重连多次”，得搭配 CHANGE MASTER TO ... MASTER_RETRY_COUNT 和外部保活逻辑。MySQL 5.7+ 支持 MASTER_RETRY_COUNT，但注意：它只在初次连接失败时生效，后续运行中掉线不触发重试。
- 设置
slave_net_timeout = 60（秒），让空闲连接更快释放，避免僵死 - 初始化从库时显式指定重试：
CHANGE MASTER TO MASTER_HOST='xxx', ..., MASTER_RETRY_COUNT=3; -
MASTER_RETRY_COUNT是整数，0 表示无限重试（慎用，可能掩盖真实故障） - 该参数只在
START SLAVE首次建立连接时起作用；运行中 IO 线程断开后，仍需依赖slave_net_timeout+ 重连逻辑
必须配合监控和自动恢复脚本
MySQL 不负责“掉线后反复拉起”，运维层面得补上这一环。典型做法是用定时任务检查 Slave_IO_Running 状态，发现异常就执行 START SLAVE。
- 检查命令示例：
mysql -Nse "SHOW SLAVE STATUS\G" | grep "Slave_IO_Running:" | awk '{print $2}' - 如果结果不是
Yes，可触发mysql -e "START SLAVE IO_THREAD;" - 注意避免重复执行：加锁、限频、记录上次操作时间
- 不要只看
Slave_IO_Running，也要查Seconds_Behind_Master是否持续增长（可能复制卡在 SQL 线程）
8.0.23+ 的新选项：SOURCE_CONNECTION_AUTO_FAILOVER
MySQL 8.0.23 引入了自动故障转移支持，但它是为多源复制 + 备选主库设计的，不是为单主从“重连”服务的。开启后需要提前配置备用源（ADD SOURCE），且要求主库地址可被解析、权限一致、GTID 开启。
- 启用前必须设
source_connection_auto_failover=ON（全局变量） - 单主从场景下强行配它，反而增加复杂度，还可能因 DNS 解析失败导致更难排查
- 真正稳定的需求，仍是降低
slave_net_timeout+ 外部健康检查 + 快速START SLAVE
最易被忽略的一点：修改 slave_net_timeout 后必须重启 IO 线程（STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;），动态改完不生效。
