Orchestrator 能否真正实现秒级主从切换？
直接打包票说“秒级切换”，那肯定不现实。不过，在配置得当、网络稳定、且从库没有复制延迟的理想情况下，把整个故障检测到切换完成的流程压缩到3到8秒，是完全有可能的。这里的实际耗时，很大程度上取决于几个关键因素：主从之间的Binlog GTID同步状态、Orchestrator自身的心跳探测间隔（默认是1秒）、以及目标从库是否已经准备好接管——比如read_only参数是否已关闭，具备了写入能力。
这里有个必须警惕的误区：如果候选从库的Seconds_Behind_Master显示有120秒的延迟，这时强行切换必然会导致数据丢失。Orchestrator默认不会跳过这个检查，除非你手动关闭了prevent_cross_replication这类安全验证，或者用其他方式绕过去——但这无异于埋雷。
关键配置项必须改哪几个？
下面这几个配置项，可以说是Orchestrator高效工作的“命门”。如果保持默认不动，它很可能会拒绝执行切换，或者切出一个根本不可用的主库。
detect-sla ve-query-interval-seconds：建议设为1。这个值决定了探测从库延迟的频率，调低它能更快地感知状态变化。audit-log-path：务必配置一个可写的路径。否则切换日志无处落盘，出了问题连排查的依据都找不到。raft-enabled：必须设为true。尤其是在多节点高可用部署下，它能有效避免脑裂问题。即便是单机部署，也强烈建议开启。skip-replica-start-on-failover：设为false。这能确保新的主库在切换后自动启动复制通道，避免后续的其他从库无法追上数据。failure-detection-period-blocks：建议设为3。这意味着需要连续3次心跳失败，才会判定主库宕机，可以有效避免因网络瞬断导致的误判切换。
执行 failover 时为什么卡在 “waiting for replicas to catch up”？
遇到这个提示，说明Orchestrator正在等待候选从库的复制位置追平原主库。这时候别慌，通常可以从以下几个方面排查：
- 从库配置问题：检查候选从库的
relay_log_recovery参数是否为OFF。如果为OFF，从库重启后可能因relay log不完整而导致SQL线程卡住。 - 性能瓶颈：原主库的binlog写入速度过快，而候选从库的磁盘I/O或网络带宽跟不上，就会导致
Seconds_Behind_Master这个值只增不减。 - 并行复制的“错觉”：Orchestrator依赖
SHOW SLA VE STATUS中的Seconds_Behind_Master来判断延迟。但在MySQL 5.7及以上版本启用了并行复制（sla ve_parallel_workers > 0）后，这个值的更新可能会有滞后，不能完全反映真实的同步进度。 - GTID未启用：如果没有启用
gtid_mode=ON和enforce_gtid_consistency=ON，Orchestrator就会降级使用传统的file/position方式进行位置比对。这种方式精度较低，也更容易出现误判。
切换后应用连不上新主库？检查这三点
首先要明确一点：Orchestrator只负责数据库拓扑结构的变更，它不会自动去更新你的DNS、VIP或者应用配置文件。连接不上，问题往往出在“最后一公里”。
- 钩子脚本是否生效：确认
post-failure-hook脚本是否被正确触发并执行。比如，这个脚本是否真的调用了更新VIP的接口（例如curl -X POST https://vip-manager/switch?new_master=10.0.1.22）？脚本的执行权限、超时设置以及返回码都需要仔细验证。 - 新主库连接数是否打满：切换瞬间，所有应用连接可能同时涌向新主库。如果新主库的
max_connections设置过低，或者应用没有使用连接池，很容易导致连接数被瞬间打满。可以通过show status like 'Threads_connected'命令实时观察。 - 新主库的只读状态：虽然Orchestrator默认会执行
set global read_only=off来解除新主库的只读状态，但如果数据库的SQL mode包含NO_AUTO_CREATE_USER，或者执行该命令的账户没有SUPER权限，这个操作可能会静默失败，导致主库实际上仍处于只读模式。
最后，还有一个容易被忽略的细节：Orchestrator自身的元数据表database_instance中，is_coordinator这个字段在切换后并不会自动更新。如果你的后续路由或判断逻辑依赖这个字段，就需要自己额外编写逻辑来同步这个状态。
