mysql 8.0无“重试n次”内置开关，slave_net_timeout仅控制空闲断连阈值（推荐10～30秒），source_retry_count仅影响首次连接重试，运行中掉线需外部脚本监控并手动重启io线程。
MySQL 8.0 本身不提供“重试 N 次”的内置开关，所谓“自动重连次数”是误读；真正起作用的是 slave_net_timeout 触发断连 + SOURCE_RETRY_COUNT 控制首次连接失败时的重试行为，运行中掉线后仍需外部干预。
slave_net_timeout 不是重试次数，而是空闲断连阈值
它只决定 IO 线程多久没收到主库数据就主动关闭当前 TCP 连接——之后触发一次重连（仅一次），然后停在 Slave_IO_Running: No。默认 3600 秒太长，网络抖动后可能卡住一小时才反应；设太小（如 5 秒）又容易误判，尤其主库写入空闲期稍长时。
- 推荐值：10～30 秒，取网络 P99 延迟的 3–4 倍（例如监控显示延迟峰值 800ms，则设
slave_net_timeout = 3） - 必须配合
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;才生效，SET GLOBAL单独执行无效 - 它只影响 IO 线程，SQL 线程卡住（比如主键冲突）时完全不触发
MySQL 8.0+ 的 SOURCE_RETRY_COUNT 只在首次连接生效
这是新版 CHANGE REPLICATION SOURCE TO 语句里的参数，替代了旧版 MASTER_RETRY_COUNT。但它只管“START SLAVE 第一次连不上时 retry 多少次”，不是运行中掉线后的持续重试机制。
- 设为
SOURCE_RETRY_COUNT = 3表示首次连接失败后最多再试 2 次（共 3 次尝试） - 设为 0 表示无限重试，但可能掩盖真实故障（如主库宕机、权限错误）
- 必须搭配
SOURCE_CONNECTION_AUTO_RETRY = 1才启用该逻辑，漏掉任一参数都不生效 - 执行后需重启 IO 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
运行中掉线后，MySQL 不会自动反复拉起 IO 线程
这是最容易被忽略的现实：哪怕你把 slave_net_timeout 设成 10 秒、SOURCE_RETRY_COUNT 设成 100，只要 IO 线程已启动过，后续掉线就只重连一次，然后静默等待人工 START SLAVE。
- 典型症状：
SHOW REPLICA STATUS\G显示Slave_IO_Running: No，但Last_IO_Error是error connecting to master或Lost connection - 必须靠外部脚本定期检查状态，例如用
mysql -Nse "SHOW REPLICA STATUS\G" | grep "Slave_IO_Running:" | awk '{print $2}' - 脚本要加锁或限频，避免并发执行
START SLAVE IO_THREAD导致冲突 - 别只盯
Slave_IO_Running，还要看Seconds_Behind_Master是否持续增长——那可能是 SQL 线程卡住，重连解决不了
MySQL 8.0.23+ 的 SOURCE_CONNECTION_AUTO_FAILOVER 不适用于单主从重连
这个新特性是为多源复制（Multi-source Replication）设计的，需要提前配置多个备用源（ADD SOURCE）、开启 GTID、主备权限一致且地址可解析。对普通单主从场景，它不接管日常网络抖动导致的重连。
- 启用后仍需手动维护备用源列表，且故障转移逻辑复杂，运维成本高
- 如果只是想应对偶发网络中断，不如专注调好
slave_net_timeout+ 监控脚本 - 不要因为看到“auto”字样就默认它能替代人工保活逻辑
真正可靠的自动恢复，从来不是靠某个参数设大一点，而是把 slave_net_timeout 调到合理灵敏度、确认 SOURCE_CONNECTION_AUTO_RETRY = 1 和 SOURCE_RETRY_COUNT 已生效、再配上带状态去重和错误过滤的监控脚本——三者缺一不可。漏掉任意一环，都会在凌晨三点收到告警却只能手动登录修复。
