orchestrator能实现自动主从切换，但需满足三个硬性前提：log_slave_updates=on、skip_name_resolve=off、server_id全局唯一；还需super权限及完整探测能力，否则因状态失真导致切换失败。
Orchestrator 能实现自动主从切换，但**不是装上就能切**——它依赖真实、及时的底层状态反馈。多数“切换失败”问题，根源不在工具本身，而在 MySQL 实例配置失真或网络探测失准。
MySQL 实例必须满足的三个硬性前提
Orchestrator 通过持续执行 SHOW SLAVE STATUS 和 SELECT @@read_only 判断节点状态，以下配置缺一不可：
-
log_slave_updates=ON：否则级联从库无法在晋升后继续作为主库提供复制服务 -
skip_name_resolve=OFF：Orchestrator 用 hostname 做实例唯一标识，DNS 解析失败会导致拓扑识别错乱 -
server_id全局唯一：重复值会让 Orchestrator 把两个实例当成一个，拓扑图直接崩坏
部署前务必手动运行：orchestrator -c discover -i 'your-master-host:3306'，确认返回的是完整链路（而非孤点），否则后续所有自动逻辑都建立在错误拓扑上。
Orchestrator 连接账号权限不能只给“够用”的最小集
它需要在故障时执行 STOP SLAVE、RESET SLAVE ALL、CHANGE MASTER TO 等操作，仅靠 REPLICATION SLAVE 和 REPLICATION CLIENT 不够：
- 必须包含
SUPER权限（MySQL 5.7+）或SYSTEM_VARIABLES_ADMIN+CONNECTION_ADMIN（MySQL 8.0.21+） - 还需
SELECT权限访问mysql.slave_master_info表（用于读取复制源信息） - 如果启用
raft模式，Orchestrator 自身也需要一个后端 MySQL 存储元数据，该库账号需有ALL权限
切换后应用连不上新主库？Orchestrator 不管路由层
它只改复制关系，不碰 VIP、DNS 或应用配置。常见踩坑点：
- 直接让应用连
mysql-master.example.com→ DNS 缓存导致长期连旧主（即使 TTL 设为 30，客户端 SDK 仍可能缓存数分钟） - 没配健康检查中间件 → 新主提升后，旧连接还在往已下线节点发请求
- 没利用
post_topology_recovery回调 → 无法触发 ProxySQL / HAProxy 的mysql_servers表更新
推荐做法：应用统一连 mysql-rw.example.com，背后由 ProxySQL 或 HAProxy 做后端探活与自动摘除，再通过 Orchestrator 的 HTTP 回调实时同步主库变更。
MySQL 8.0+ 的 binlog_format 兼容陷阱
MySQL 8.0 默认开启 require_row_format=ON，而 Orchestrator 的 replica-binlog-convert 功能（用于 position 模式兼容）会因此报错退出：
- 要么关闭该参数：
SET GLOBAL require_row_format = OFF（需重启生效） - 要么降级到 MySQL 5.7（若业务允许）
- 要么彻底弃用
replica-binlog-convert，全程使用 GTID 复制（推荐）
GTID 模式下，MASTER_AUTO_POSITION=1 必须在所有从库 CHANGE MASTER TO 时启用，否则 Orchestrator 无法安全计算切换路径。
Seconds_Behind_Master 显示 0，但 IO thread 已静默断连；或者主库 crash 后 mysqld 进程未彻底退出，端口仍被占用，Orchestrator 就会误判为“存活”。这些细节，才是高可用落地真正的分水岭。
