Orchestrator 并非开箱即用的自动切主黑盒，其正常工作依赖 MySQL 实例状态准确、权限完整、拓扑可识别；需确保 server_id 全局唯一非零、log_bin 与 log_slave_updates 均开启、Orchestrator 账号具备 SELECT/REPLICATION SLAVE/SUPER/PROCESS/RELOAD 权限。
Orchestrator 不是“开了就能自动切主”的黑盒，它依赖 MySQL 实例状态准确、权限完整、拓扑可识别。没有前置复制稳定性保障和最小必要权限配置，部署后大概率卡在探测失败或切换中止。
Orchestrator 启动后找不到 MySQL 实例？检查这三处硬性条件
常见错误现象：orchestrator 日志反复报 Failed to discover instance 或 Web UI 显示空拓扑，本质是它连不上、读不了、认不出你的 MySQL 节点。
-
server_id必须全局唯一且非 0 —— 重复或为 0 会导致实例被忽略，show variables like 'server_id';每台都得查 -
log_bin和log_slave_updates必须同时开启 —— 否则级联从库无法被纳入拓扑，show variables like 'log_%';确认两者均为ON - Orchestrator 连接账号缺关键权限 —— 仅
REPLICATION CLIENT不够，必须显式授予：SELECT,REPLICATION SLAVE,SUPER,PROCESS,RELOAD
切换时卡在 “Waiting for slaves to catch up” 怎么办？
这不是网络问题，而是 Orchestrator 在等所有候选从库的 Seconds_Behind_Master = 0。但生产环境极少真正为 0，尤其半同步复制下可能有毫秒级延迟。
- 检查
"WaitForSemiSyncTimeoutSeconds"配置项（默认 30）是否过短 —— 建议设为 60～120，避免因瞬时延迟误判 - 确认从库未启用
relay_log_purge = ON（默认值），否则中继日志被清空后 Orchestrator 无法比对 Binlog 位置 - 若使用
binlog-format = ROW，确保主库sync_binlog = 1，否则崩溃后 Binlog 可能丢失最后几条，导致从库永远追不上
切换后应用连不上新主？别只盯数据库
Orchestrator 完成 STOP SLAVE、RESET SLAVE ALL、CHANGE MASTER TO 后，新主已就位，但应用层仍连旧 IP —— 这是最常被忽略的环节。
-
"PostFailoverHooks"必须配置：例如调用keepalived切换 VIP，或更新 Consul 服务注册，或触发 Nacos 配置推送 - 连接池需支持健康检查：HikariCP 的
connection-test-query+validation-timeout，Druid 的testOnBorrow，否则旧连接会缓存数分钟 - 避免直接用 IP 连接：应用应通过域名（如
mysql-primary.service.local）访问，DNS TTL 设为 5s，并配合脚本在切换后nsupdate修改 A 记录
为什么 elect 模式比 force 更安全？
"FailoverType": "force" 会跳过所有健康检查，强行把指定实例提为新主 —— 适合灾备演练，但线上绝对禁用。
-
"elect"模式按顺序评估：Seconds_Behind_Master→Binlog position→read_only=OFF状态 → 是否在线，选最优而非“指定” - 若某从库
read_only=ON但super_read_only=ON，elect会跳过它；而force会直接执行SET GLOBAL super_read_only = OFF，可能引发写冲突 - 选举前 Orchestrator 会自动
STOP SLAVE所有从库，防止切换中继续拉日志干扰位置判断 —— 这步force不做
真实故障转移不是“一键切换”，而是复制状态可信、权限无缺口、网络路径通、应用感知快的链路闭环。最容易被跳过的其实是 log_slave_updates 开关和 PostFailoverHooks 脚本 —— 它们不报错，但会让整个流程在最后一步静默失效。
