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）。常见原因：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 候选从库的
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 字段不会自动更新，如果后续依赖它做路由判断，得自己加逻辑同步。
