Orchestrator 默认不自动故障转移，需同时启用 FailureDetectionEnable 和 AutomatedFailoverEnabled 并重载配置；切换失败常见于权限不足、super_read_only 锁定、binlog 未开启或应用未更新连接信息。
主库宕机后 Orchestrator 为什么没自动切？
Orchestrator 默认不自动执行故障转移，必须显式开启 FailureDetectionEnable 和 AutomatedFailoverEnabled，否则它只做检测、不行动。
-
FailureDetectionEnable控制是否监听主库心跳失败；设为false（默认值）时，连“宕机”都识别不到 -
AutomatedFailoverEnabled才决定是否发起切换；即使检测到故障，这个关着就只会发告警、不动 topology - 两者都需在配置文件中设为
true，且 Orchestrator 进程要 reload 或重启才生效 - 常见误操作：只改了 Web UI 的开关，但没写回配置文件或没触发 reload，导致重启后还原
切换后从库没升主？检查复制用户权限和 binlog 设置
Orchestrator 切换时会尝试在候选从库上执行 STOP SLAVE; RESET SLAVE ALL;，再把它设为可写。如果失败，切换就会卡住或回滚。
- 候选从库的
read_only=1必须能被 Orchestrator 动态关闭——确保它没被super_read_only=1锁死（MySQL 5.7+），否则SET GLOBAL read_only=0会报错 - 主库宕机前，所有从库必须已开启
log_bin且有binlog_format=ROW；否则新主无法继续提供 binlog 给下游，Orchestrator 会拒绝将其提升 - Orchestrator 连接各实例用的是同一套 MySQL 用户，该用户需具备
REPLICATION SLAVE ADMIN（8.0）或SUPER, REPLICATION CLIENT（5.7）权限，缺一不可
Orchestrator 检测延迟大？调低 heartbeat 和 detection 频率
默认每 10 秒查一次主库状态，故障发现平均延迟 5–15 秒；对 RPO 要求高的场景不够用。
- 缩短
DiscoveryIntervalSeconds（如设为3）可加快拓扑刷新，但会增加 Orchestrator 对各 MySQL 实例的查询压力 -
HealthPollSeconds控制心跳轮询间隔，建议与DiscoveryIntervalSeconds一致，避免健康状态滞后 - MySQL 端的
slave_net_timeout和master_heartbeat_period也要匹配，否则可能因网络抖动误判主库宕机 - 注意：太激进的探测频率在高延迟网络下反而引发频繁误切，测试环境先压测再上线
切换后应用连不上新主？Orchestrator 不管 DNS 或连接池
Orchestrator 只改 MySQL 实例角色和复制关系，不修改任何外部路由、VIP、DNS 或客户端配置。
- 应用直连 IP/Port 的话，必须自己更新配置并 reload —— Orchestrator 不提供回调钩子（
PostFailoverProcesses是可选配置，但得手动写脚本） - 若用 VIP，需配合
PreFailoverProcesses和PostFailoverProcesses脚本做地址漂移，且确保脚本幂等、超时可控 - 连接池（如 HikariCP）缓存的老连接不会自动断开，得靠
connection-test-query或validation-timeout配合 MySQL 的wait_timeout触发清理 - 最容易被忽略的一点：Orchestrator 切换后，原主库恢复时默认不会自动变成从库，得靠
RecoverMaster配置或人工介入，否则双主风险仍在
