orchestrator能实现自动主从切换，但前提是mysql实例状态可被真实探测——它依赖show slave status和select @@read_only返回值，若io线程假死或主库端口假活则会误判；必须开启log_slave_updates、server_id全局唯一非0、禁用skip_name_resolve；discoveryintervalseconds建议设为5，failovertype应选"elect"而非"force"，postfailoverhooks必须配置以同步vip/dns/proxysql。
Orchestrator 能实现自动故障切换，但前提是 MySQL 实例状态可被真实探测到——它不猜，只信 SHOW SLAVE STATUS 和 SELECT @@read_only 的返回值。一旦这两个查询失真（比如从库 IO 线程假死、主库端口被占但进程已崩），切换就会卡住或误判。
MySQL 实例必须满足的三个硬性条件
Orchestrator 不会帮你修配置，它只按规则做事。以下三点不满足，failover 90% 会失败或降级为手动干预：
-
log_slave_updates必须开启：否则级联从库无法继续做主，Orchestrator 在拓扑中会把它识别为“死端”，拒绝选举 -
server_id全局唯一且非 0：重复值会让 Orchestrator 把两台机器当同一个实例，拓扑发现直接错乱 -
skip_name_resolve = OFF：Orchestrator 用 hostname 做实例身份标识，DNS 解析失败 → 实例“消失” → 拓扑断裂
Orchestrator 配置里最容易被忽略的三个字段
不是填完就能跑，这几个键值决定 failover 是“秒切”还是“卡死”：
-
"DiscoveryIntervalSeconds": 5：设成 30 就意味着故障最长要等半分钟才被发现；设成 1 则可能压垮小规格 MySQL 实例 -
"FailoverType": "elect"：别用"force"，后者跳过延迟检查和 binlog 位置比对，选到一个落后 2 小时的从库就等于丢数据 -
"PostFailoverHooks"必须配：Orchestrator 切完主库后，不会改 DNS、不漂 VIP、不通知 ProxySQL —— 这些全靠你写的脚本补上，漏掉就等于“切了但应用连不上”
为什么切换后应用连不上新主？
Orchestrator 只改复制关系，不碰客户端连接层。常见断连不是因为切换失败，而是没配好下游协同：
- 没在
PostFailoverHooks里调用 VIP 漂移脚本，应用还在往旧 IP 发请求 - ProxySQL 没接 Orchestrator API：它的
mysql_replication_hostgroups表没更新，读写路由仍指向旧主 - 应用直连 MySQL，且连接串里写死 host:port —— 这种架构下 Orchestrator 再强也救不了，必须加一层中间件或 DNS
真正难的从来不是“怎么切”，而是“怎么让上下游都认出新主”。Orchestrator 把最复杂的拓扑判断和原子操作封装好了，但路由、连接、权限这些边界动作，得你自己钉死。
