MySQL自动故障转移不能只靠主从复制，因从库不会自动晋升且应用连接不自动切换，需Orchestrator等外部工具协调状态、触发切换、更新拓扑并通知客户端。
MySQL 自动故障转移为什么不能只靠主从复制
主从复制本身不提供自动故障转移能力。当主库宕机，从库不会自动晋升为主库，应用连接也不会自动切到新主——这需要外部工具协调状态、触发切换、更新拓扑、通知客户端或配置中心。
Orchestrator 就是为解决这个问题而生：它实时探测 MySQL 实例健康状态，支持基于 Raft 的高可用决策，能安全执行主从切换（failover），并提供 Web UI 和 API 管理集群视图。
常见错误现象：orchestrator 启动后无法发现实例、切换时卡在 Waiting for slaves to catch up、切换后应用连不上新主——多数源于权限不足、复制过滤规则冲突、或未关闭 read_only 自动同步机制。
Orchestrator 部署前必须配好的 MySQL 权限和参数
Orchestrator 需要读取复制状态、执行 STOP SLAVE/START SLAVE、修改 read_only、重置主库信息（CHANGE MASTER TO），所以账号权限不能只给 REPLICATION CLIENT。
- 必须授权：
SELECT, REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD（SUPER用于SET GLOBAL read_only=OFF） - 所有实例需启用
log_bin和log_slave_updates（否则级联复制中断，Orchestrator 无法构建完整拓扑） - 建议统一设置
relay_log_recovery=ON和skip_slave_start=ON，避免意外启动复制线程干扰切换逻辑 - 确保
server_id全局唯一，且不能为 0 或重复值（Orchestrator 依赖它识别实例）
Orchestrator 配置文件关键项说明（orchestrator.conf.json）
配置不是填完就能跑，几个字段直接影响 failover 是否触发、是否安全、是否可逆：
-
"MySQLOrchestratorHost"和"MySQLOrchestratorPort"：指向存放 Orchestrator 自身元数据的后端 MySQL（不是被管集群！），必须提前建库并授权 -
"DiscoveryIntervalSeconds": 5：探测间隔太长（如 30s）会导致故障发现延迟；太短（如 1s）会增加集群压力，5–10s 是较稳选择 -
"PromotionIgnoreHostnameFilters"：若某些从库（如备份专用机）不应参与主库选举，必须加进这个白名单，否则可能误切 -
"FailoverType": "elect"：推荐用elect（自动选最优从库），而非force（指定某台），后者绕过健康检查，风险高 -
"PostFailoverHooks"：务必配置，例如调用脚本更新 VIP、刷新 DNS、通知 Consul 或 Nacos，否则应用层不知道主变了
一次典型故障转移中 Orchestrator 做了什么
以单主多从集群中主库宕机为例，Orchestrator 不是简单找一个从库 STOP SLAVE; CHANGE MASTER TO master_host=''; START SLAVE 就完事——它会分步验证：
- 确认原主彻底失联（连续多次 ping +
SELECT 1超时） - 扫描所有从库的
Seconds_Behind_Master和Exec_Master_Log_Pos，选出最接近原主的候选者 - 对候选者执行
STOP SLAVE IO_THREAD等待追平，再STOP SLAVE锁定状态 - 将其他从库
CHANGE MASTER TO指向新主，并校验MASTER_AUTO_POSITION=1是否一致（GTID 模式下尤其关键） - 最后才把新主的
read_only=OFF，并调用PostFailoverHooks
容易被忽略的一点：如果集群混用 GTID 和非 GTID 实例，Orchestrator 默认拒绝切换——必须显式设 "DetectClusterAliasQuery" 并确保所有实例返回相同 alias，否则它会把它们当成不同集群处理。
