Orchestrator无法保证绝对秒级切换，但配置得当、网络稳定、从库无延迟时可压缩至3–8秒；关键需调优detect-slave-query-interval-seconds、audit-log-path、raft-enabled等5项配置。

Orchestrator 能否真正实现秒级主从切换？

不能直接保证“秒级”，但能将故障检测 + 切换流程压缩到 3–8 秒，前提是配置得当、网络稳定、从库 IO/SQL 线程无延迟。真实耗时取决于 Binlog GTID 同步状态、orchestrator 自身心跳间隔（默认 1 秒）、以及目标从库是否已启用 read_only=OFF 和具备写能力。若从库存在 Seconds_Behind_Master: 120，强行切换必然丢数据——Orchestrator 不会跳过这个检查，除非你关掉 prevent_cross_replication 或手动绕过验证。

关键配置项必须改哪几个？

不改这些，Orchestrator 默认会拒绝切换或切出不可用主库：

• detect-slave-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 在等候选从库的 Exec_Master_Log_Pos 追平原主库的 File/Position（或 GTID set）。常见原因：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 候选从库的 relay_log_recovery=OFF，导致重启后 relay log 不完整，SQL 线程卡住
• 原主库 binlog 写入太快，而候选从库磁盘 I/O 或网络带宽不足，Seconds_Behind_Master 持续增长
• Orchestrator 读取的是 SHOW SLAVE STATUS 的 Seconds_Behind_Master，但该值在并行复制下可能滞后于真实延迟（尤其 MySQL 5.7+ 使用 slave_parallel_workers > 0）
• 未启用 gtid_mode=ON + enforce_gtid_consistency=ON，Orchestrator 降级使用 file/pos 比对，精度低且易误判

切换后应用连不上新主库？检查这三点

Orchestrator 只管数据库拓扑变更，不改 DNS、VIP 或应用配置：

• 确认 orchestrator 的 post-failure-hook 脚本是否真实触发：比如调用 curl -X POST http://vip-manager/switch?new_master=10.0.1.22 更新 VIP，脚本权限、超时、返回码都要验
• 检查新主库的 max_connections 是否被突发连接打满（尤其应用未配置连接池复用），show status like 'Threads_connected' 看实时连接数
• 验证新主库的 read_only 状态：Orchestrator 默认会执行 set global read_only=off，但如果 SQL mode 包含 NO_AUTO_CREATE_USER 或账户无 SUPER 权限，该命令静默失败

最常被忽略的是：Orchestrator 的元数据表 database_instance 中 is_coordinator 字段不会自动更新，如果后续依赖它做路由判断，得自己加逻辑同步。