postpone-launch 是手动控制 cut-over 时机的机制，非时间延迟；它在数据同步完成、校验通过后暂停于“就绪未上线”状态，需人工触发 –execute-postponed 或 http api 才执行 rename。
gh-ost 的 postpone-launch 并不是“延迟启动”，而是一种手动控制 cut-over 时机的机制，用于在数据迁移完成、校验通过后，暂不自动切换主从流量，等待人工确认再执行最终切换。它本身不提供时间维度上的“延时”，而是暂停在“就绪但未上线”状态。
postpone-launch 的真实作用
启用该参数后，gh-ost 会在以下阶段停止并等待人工干预：
- 完成所有增量同步（binlog 拉取与应用）
- 完成表结构变更和数据拷贝
- 通过一致性校验（如 –test-on-replica 或 checksum 对比）
- 此时 ghost 表已就绪，原表与 ghost 表数据一致，但 尚未执行 rename 操作
此时需手动运行 gh-ost --execute-postponed 或调用其 HTTP API 触发 cut-over，否则迁移长期挂起，不影响线上服务。
如何配合实现真正的“延迟启动”
若需在满足条件后 过一段时间 再上线（例如避开业务高峰、等待监控观察窗口），需外部编排，常见做法有：
- 定时任务调度：用 crontab / systemd timer / Airflow 等，在预定时间触发
gh-ost --execute-postponed - HTTP API + 脚本守候：启动 gh-ost 时开启
--serve-http，写一个轻量脚本定期检查健康/校验状态，满足条件后再 sleep N 分钟，最后调用POST /continue - 人工灰度流程嵌入：将
postpone-launch作为发布流程卡点，例如“变更单审批通过后，dba 手动执行上线命令”，把延迟逻辑放在流程管控层而非工具层
替代方案：用 cut-over-lock-timeout 控制风险窗口
如果目标是“避免长锁影响业务”，可结合：
-
--cut-over-lock-timeout-seconds=3：限制 rename 阶段最大持锁时间，超时则中止，保障可用性 -
--max-load="Threads_running=25"：在高负载时自动暂停写入，避免雪崩 -
--allow-on-master+--concurrent-rowcount：控制迁移节奏，降低对主库压力
这些参数让 gh-ost 更“温和”，但不改变 cut-over 的即时性 —— 它们是安全护栏，不是延迟开关。
注意事项与典型误用
使用 postpone-launch 时需注意：
- 挂起期间 ghost 表持续接收 binlog 增量，若长时间不 cut-over，可能因磁盘或 relay log 清理导致同步中断
- 不能与其他自动化 cut-over 工具（如某些运维平台内置的“一键上线”）混用，易引发冲突
- 务必提前验证
--execute-postponed命令权限与网络可达性（尤其跨集群场景） - 日志中出现
Postponing launch. Waiting for manual trigger.即表示已就绪待命
不复杂但容易忽略。