orchestrator能实现mysql主从自动故障转移，但需满足log_slave_updates=on、server_id全局唯一非0、skip_name_resolve=off三大硬性条件，并配置failovertype="elect"及postfailoverhooks脚本以同步proxysql/dns/vip。
Orchestrator 能实现 MySQL 主从自动故障转移，但不是“装上就切”——它只在探测到主库真实不可用、且有合格从库可提主时才动作。绝大多数失败案例，根源不在 Orchestrator 本身，而在于 MySQL 实例状态不可信或配置未对齐。
MySQL 实例必须满足的三个硬性条件
Orchestrator 不修配置，只按规则执行。以下三点不满足，failover 大概率卡住或降级为人工干预：
• log_slave_updates = ON：否则级联从库无法继续做主，会被识别为“死端”，直接排除在候选名单外
• 每个实例的 server_id 全局唯一且非 0：重复值会让 Orchestrator 把两台机器当成一个节点，拓扑发现彻底错乱
• skip_name_resolve = OFF：它靠 report_host + DNS 解析结果标识实例，DNS 失败 → 实例“消失” → 拓扑断裂
FailoverType 和 PostFailoverHooks 必须显式配对
FailoverType 决定“选谁”，PostFailoverHooks 决定“怎么让应用连上”。二者缺一不可：
• FailoverType 必须设为 "elect"：跳过延迟检查和 binlog 位置比对的 "force" 模式极易选到落后数小时的从库，等于丢数据
• PostFailoverHooks 必须配置 shell 脚本路径（如 "/usr/local/orch/hooks/failover.sh"）：这个脚本负责调用 ProxySQL API 更新 mysql_replication_hostgroups，或触发 DNS 解析更新、VIP 漂移；漏掉就等于“切成功了，但应用全连错”
• 注意：该脚本需有执行权限，且能访问下游服务（如 ProxySQL 的 admin 端口、DNS API 密钥等）
探测失效的典型现象与排查点
Orchestrator 只信两个 SQL 的返回值：SHOW SLAVE STATUS 和 SELECT @@read_only。一旦它们失真，切换逻辑就失效：
• 从库 Seconds_Behind_Master = 0 但实际已断连（IO 线程假死）→ Orchestrator 认为它健康，可能误选
• 主库 crash 后端口仍被占用（如被其他进程监听）→ SELECT 1 成功，但 @@read_only 查不到 → Orchestrator 无法确认其只读状态，拒绝触发 failover
• DiscoveryIntervalSeconds 设为 30 秒 → 故障最长要等半分钟才被发现；设为 5 是合理下限，但别压到 1，小规格 MySQL 扛不住高频探测
老主库恢复后不会自动“夺权”，但会自动归队
故障老主库重启后，Orchestrator 不会把它当“原主”特殊对待，而是当作一个新上线的实例，走标准流程：
• 它被 InstancePollSeconds 周期探测到，read_only=ON、GTID 集合落后于当前主库 → 自动识别为“旧主”
• 接着执行 STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1;，将其作为从库重新接入新拓扑
• 这个过程依赖 GTID；若你禁用 GTID（如用 binlog file + position），则必须确保 RecoverMasterBinlogFileLocation: true 且所有节点启用 Pseudo-GTID，否则归队失败
