Orchestrator 能实现自动主从切换，但需满足拓扑干净、MySQL 配置合规、网络权限无缺陷等前提；它依赖持续探测 SHOW SLAVE STATUS 和 @@read_only 判断状态，常见失败源于探测失真而非工具缺陷。
Orchestrator 能不能真做到自动主从切换？
能，但前提是拓扑干净、MySQL 实例配置合规、网络和权限没硬伤。Orchestrator 不是“装上就切”，它靠持续探测 SHOW SLAVE STATUS 和 SELECT @@read_only 做判断，一旦发现主库失联且从库无脑复制中断，才触发提升逻辑。常见失败不是工具不行，而是它探测不到真实状态——比如从库 Seconds_Behind_Master 一直为 0（实际已断连但 IO_THREAD 没报错），或主库 crash 后端口还占着（Orchestrator 认为它“活着”）。
实操建议：
- 所有 MySQL 实例必须开启
log_slave_updates，否则级联切换时中间节点无法继续做主 - 禁用
skip_name_resolve，Orchestrator 依赖 hostname 解析做实例识别，DNS 不稳等于拓扑不可信 - 每个实例的
server_id必须全局唯一，重复会导致 Orchestrator 把两个实例当成一个 - 部署前手动跑一次
orchestrator -c discover -i 'your-master-host:3306'，确认它能拉出完整复制链，而不是只看到孤点
切换失败最常见的三个配置坑
Orchestrator 切换失败，70% 出在权限、超时、或 MySQL 自身限制上，不是它代码有问题。
实操建议：
- Orchestrator 连接 MySQL 的账号必须有
SUPER、REPLICATION CLIENT、REPLICATION SLAVE权限，缺SUPER就没法执行STOP SLAVE和RESET SLAVE ALL -
raft_timeout_ms默认 5000，但在高延迟网络下，Orchestrator raft 成员间心跳超时会误判 leader 失效，建议设为10000并配raft_retry_timeout_ms=2000 - MySQL 8.0+ 默认开启
require_row_format，Orchestrator 的replica-binlog-convert功能不兼容，得关掉或降级到 5.7
如何让切换后应用不连错库？
Orchestrator 只管改复制关系，不管你的应用连哪个地址。它不提供 VIP 或 DNS 切换，也不改应用配置文件。想无缝，得自己搭一层路由。
实操建议：
- 别直接让应用连
mysql-master.example.com，而是连一个中间层，比如mysql-rw.example.com，背后用 LVS/HAProxy/ProxySQL 做后端健康检查 + 自动摘除 - Orchestrator 提供 HTTP 回调（
post_topology_recovery），可以在切换完成后 curl 一下你自己的脚本，触发 ProxySQL 的mysql_servers表更新 - 如果用 DNS，别用 TTL=300 那种“理论快速”，客户端缓存 DNS 更狠；建议 TTL ≤ 30，并配合应用层重试（如 MySQL 连接池的
autoReconnect=true&failOverReadOnly=false）
为什么测试环境切得利索，生产一挂就乱？
因为生产有延迟复制、多源复制、GTID 和非 GTID 混用、或者某些从库被 SET GLOBAL read_only=OFF 手动放开写入——Orchestrator 的默认策略（prefer-active-node）会把这种“假从库”当候选主库推上去。
实操建议：
- 上线前用
orchestrator -c audit扫一遍，重点看is_candidate_for_master字段是否全为true，手动关掉不该参选的节点：orchestrator -c set-replication-source -i 'bad-slave:3306' -d '' - GTID 环境下必须统一开启
enforce_gtid_consistency=ON和gtid_mode=ON，混用 binlog_pos 和 GTID 会让 Orchestrator 的find-gtid-basis算法失效 - 延迟复制从库（
CHANGE MASTER TO MASTER_DELAY = 3600）默认被 Orchestrator 排除在候选之外，但如果没显式配置avoid-binlog-dump，它可能在极端情况下仍参与选举
真正难的从来不是切，是切完谁来告诉下游“新主在这儿”，以及怎么确保旧主回来时不自作主张再抢回去。Orchestrator 本身不解决脑裂，得靠 raft + 正确的 promotion-rule + 外部仲裁（比如 etcd）兜底。
