启用 --allow-on-master 参数意味着跳过安全检查直接在主库执行ddl，导致cpu与i/o压力叠加、rename瞬间mdl阻塞、无降级路径及binlog位点漂移等高风险；仅当无从库或从库不可用且表体积小等全部条件满足时方可谨慎评估。
启用 gh-ost 的 --allow-on-master 参数，意味着跳过默认的安全检查，直接在主库（Primary/Leader）上执行 DDL 变更。这不是“不能用”，而是把原本由从库灰度验证、流量观察、失败回滚等缓冲机制全部绕开，风险陡增。
主库直接变更的核心风险点
不同于在从库上预演再切流的常规流程，--allow-on-master 让 gh-ost 在主库上一边同步数据、一边写入新表，同时还要接管原表的 DML 流量 —— 这三个动作全部压在主库单点上：
- 主库 CPU 与 I/O 压力叠加：原表读取 + 新表写入 + binlog 生成 + 行复制事件处理，极易触发高负载、响应延迟甚至连接堆积
-
DDL 阻塞不可控：虽然 gh-ost 是无锁设计，但
RENAME TABLE切换瞬间仍需获取元数据锁（MDL），若此时有长事务或慢查询持有 MDL，切换将卡住，阻塞所有后续 DML - 无降级路径：一旦出错（如触发器异常、磁盘满、OOM），无法像从库方案那样“暂停切流、回退从库、排查修复”，只能在主库上硬中断，可能遗留不一致状态或半截 ghost 表
- binlog 位点漂移风险：主库直连模式下，gh-ost 自身的读取位置与 MySQL 复制位点无强绑定，若中间发生主从切换或 binlog 清理，可能导致数据追平失败或漏数据
什么场景下可谨慎考虑 allow-on-master
仅当满足以下全部条件时，才建议评估启用该参数：
- 集群无从库，或从库严重滞后/不可用，且业务无法接受停更窗口
- 表体积小（
- 已通过
--test-on-replica或影子表方式完整验证过迁移逻辑与性能影响 - 运维具备实时监控主库 load、threads_running、binlog_delay、MDL 等关键指标的能力，并配置了自动熔断（如配合
--max-load和--critical-load）
必须配套的防护措施
若决定使用 --allow-on-master，以下参数不是可选，而是底线要求：
-
强制限流：
--max-load="Threads_running=25" --critical-load="Threads_running=50"，防止主库雪崩 -
超时控制：
--timeout-seconds=3600避免无限 hang 住；--panic-flag-file配合外部巡检主动中止 -
原子切换保护：
--cut-over-lock-timeout-seconds=3缩短 rename 阻塞窗口；--default-retries=2避免重试放大风险 -
可观测性拉满：开启
--debug+--verbose并接入日志系统；实时跟踪_gho和_ghc表状态、chunk 进度、lag 秒数
更推荐的替代路径
绝大多数生产环境应优先规避 --allow-on-master：
- 利用
--test-on-replica+--migrate-on-replica在从库完成全量迁移和校验，再通过gh-ost自带的--switch-to-master安全升主（需提前停写） - 对超大表，采用分批迁移（按时间/ID 范围）+ 应用双写 + 校验比对，完全绕过在线 DDL 工具
- 升级 MySQL 8.0+ 后，评估原生
ALGORITHM=INSTANT或ALGORITHM=INPLACE是否满足需求，减少工具依赖
不复杂但容易忽略：allow-on-master 不是功能开关，而是风险移交开关——它把数据库的稳定性责任，从工具逻辑转移到了你的监控粒度、响应速度和兜底能力上。
