MySQL秒级切换实际需3–8秒，依赖主从同步、Orchestrator配置及网络稳定；Orchestrator等待从库真实追平GTID而非Seconds_Behind_Master；必须启用GTID并用WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()验证；切换后连不上主因应用层未更新连接、hook失败、max_connections不足或read_only未解除；延迟备库仅提供人工干预窗口，非回滚机制；切换快慢取决于GTID对齐、Orchestrator高可用配置及应用侧DNS/连接池设置。
MySQL数据库迁移无法真正实现“秒级切换”，所谓秒级，实际是3–8秒的故障检测+拓扑变更耗时，前提是主从已同步、Orchestrator配置正确、网络无抖动——否则切完就是丢数据或连不上。
Orchestrator failover 为什么卡在 waiting for replicas to catch up
这不是卡住，是 Orchestrator 在等候选从库真实追平主库的 GTID 或 binlog 位置。Seconds_Behind_Master 显示为 0 不代表真的追上了，尤其开启并行复制（slave_parallel_workers > 0）后，该值可能滞后于实际延迟。
- 必须启用
gtid_mode = ON和enforce_gtid_consistency = ON，否则 Orchestrator 退化为 file/pos 比对，精度差、易误判 - 检查
SHOW REPLICA STATUS\G中的Executed_Gtid_Set是否包含主库最新 GTID；若缺失，说明 SQL 线程没执行完 -
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()是唯一可靠验证方式，超时未返回 0 就不该发起切换
切换后应用连不上新主库的三个硬伤
Orchestrator 只改数据库角色，不碰应用层连接——所有“切完连不上”问题都出在这里。
-
post-failure-hook脚本没触发或失败：比如 VIP 切换命令ip addr add ...权限不足、curl 超时、返回非 2xx 状态码，日志得查audit-log-path配置路径 - 新主库
max_connections被打满：切流瞬间连接暴增，show status like 'Threads_connected'若接近上限，需提前扩容 -
read_only = OFF执行失败却静默：Orchestrator 默认发这条命令，但若账户缺SUPER权限，或 SQL mode 含NO_AUTO_CREATE_USER，命令无效，新主仍只读
延迟备库不能当“回滚”用，但能抢出60秒窗口
延迟备库（SOURCE_DELAY = 60）不是回滚机制，而是给你人工干预的时间缓冲。它不记录事务 undo log，只让 SQL 线程故意慢 60 秒。
- 最小建议设 60 秒：人工发现误操作 + 登录 + 查位点 + 跳过事件平均耗时 25–40 秒，再留余量
-
SQL_Remaining_Delay为NULL表示延迟失效（relay log 已追完或 IO 线程异常），此时Seconds_Behind_Master不可信 - 跳过误操作必须用
SET GTID_NEXT（GTID 模式）或SET GLOBAL sql_slave_skip_counter = 1（file/pos 模式），不能靠 mysqldump 导出再导入——那会破坏主从一致性
真正决定切换快慢的，从来不是工具命令执行时间，而是你有没有在切换前确认 Executed_Gtid_Set 对齐、有没有给 Orchestrator 配好 raft-enabled 和 failure-detection-period-blocks、以及是否忘了更新应用侧的 DNS 缓存或连接池存活检测间隔。
