MySQL主从集群里，从节点断连后能自动重连吗？
不能自动重连，更不会自动“重加入”——MySQL原生复制没有内置的故障自愈逻辑。所谓“自动恢复后的节点重加入”，其实是靠外部机制补足的，比如 mysqlfailover（已弃用）、orchestrator、MHA，或者你自己写的监控脚本 + CHANGE REPLICATION SOURCE TO 命令。
常见错误现象：Slave_IO_Running: No 且 Seconds_Behind_Master: NULL，但没人去查、没人重置 IO 线程；或者主库 binlog 被清理，从库 relay_log 损坏后卡在 SQL_THREAD 报错，直接停摆。
- MySQL 8.0.22+ 支持
AUTO_POSITION = 1，能减少位点错配，但不解决连接中断问题 - 必须确保主库保留足够长的 binlog（
binlog_expire_logs_seconds设置要大于最大可能断连时长） - 从库
relay_log_recovery = ON是关键开关，它让 mysqld 重启后自动重建 relay log，避免手动RESET SLAVE
如何让从节点检测到主库恢复后立刻重试同步？
MySQL 自身不轮询、不重试、不报警。你需要在从库侧加一层轻量级探测和触发逻辑。
典型做法是写个 shell 脚本定期执行 mysql -e "SHOW REPLICA STATUS\G"，检查 Slave_IO_Running 和 Slave_SQL_Running 字段。一旦发现为 No，且网络可达（ping -c1 主库IP 成功），就执行修复动作。
- 先尝试
START REPLICA IO_THREAD（不是START REPLICA，避免误启 SQL 线程导致冲突） - 如果报错
Could not find first log file name in binary log index file，说明主库 binlog 缺失，需人工介入或切换备份恢复 - 若 IO 线程起来但 SQL 线程卡住，检查
Retrieved_Gtid_Set和Executed_Gtid_Set是否有 gap，必要时用SET GTID_NEXT+BEGIN; COMMIT;跳过空事务
用 orchestrator 实现自动重加入要注意什么？
orchestrator 是目前最接近“开箱即用”的 MySQL 高可用方案，但它默认不自动修复复制链路，得调对参数。
容易踩的坑：装完就跑，默认配置下它只做故障转移（failover），不处理“临时断连后恢复”的场景。你得打开 ApplyMySQLPromotionAfterMasterFailover 并设置 PreventCrossRegionFailover，更重要的是启用 RecoverDeadMaster 和 RecoverDeadReplicas。
-
RecoverDeadReplicas默认是 false，必须显式设为 true 才会主动探测并重启从库复制线程 - 它依赖
replication_credentials配置项，如果从库用的是mysql_native_password认证而 orchestrator 连接池用了 caching_sha2_password，会静默失败 - 它的“恢复”只是调
START REPLICA，不校验数据一致性，也不处理 GTID 不连续——这得靠你自己的校验流程兜底
为什么不要依赖 MySQL Group Replication 的 auto-rejoin？
Group Replication（MGR）确实有 group_replication_autorejoin_tries 参数，看起来像能自动重加入，但实际非常脆弱。
真实使用中，它只在节点因短暂网络抖动被踢出组（ERROR_STATE）时起作用；一旦发生磁盘满、OOM kill、mysqld crash 后未清理 group_replication_group_name，或者本地 relay_log 文件损坏，autorejoin 就彻底失效，状态卡在 RECOVERING 或直接 OFFLINE。
-
group_replication_autorejoin_tries最大值是 2048，但每次重试间隔固定 60 秒，意味着最长要等 34 小时才放弃 - 它不会主动拉取缺失的 binlog，也不会对比
view_id和group_replication_group_name是否匹配，容易加入错误的组 - 如果你用单主模式，还开了
enforce_gtid_consistency=ON，但某台从库手动执行过非 GTID 兼容语句（如CREATE TEMPORARY TABLE），autorejoin 后立即报错退出
真正可靠的重加入，永远建立在可验证的数据一致性、可控的 binlog 生命周期、以及明确知道“哪一步该谁来触发”的分工上。自动，只是把人肉操作封装成脚本或工具，而不是把判断权交给数据库自己。
