SQL gh-ost 的 throttle 查询与动态限速机制生产实践

最可靠的方法是查看gh-ost每秒刷新的状态日志，重点关注throttlecontrolreplicas和throttleflagfile字段；也可curl http://localhost:6060/status查throttle字段，true表示已限速。

gh-ost 怎么查当前 throttle 状态

直接看 gh-ost 的状态输出最可靠，它每秒刷新一次的实时日志里就带 throttle 信息。重点盯两个字段：ThrottleControlReplicas（被控从库数）和 ThrottleFlagFile（是否命中文件限速）。生产中别依赖监控页面或外部指标——那些可能延迟几秒甚至丢点。

• 运行中执行 curl http://localhost:6060/status（默认端口），响应 json 里 throttle 字段为 true 表示已触发限速
• 用 ps aux | grep gh-ost 看命令行参数，确认是否带了 --throttle-control-replicas，没配这个的话，ThrottleControlReplicas 永远是 0
• 注意：throttle 为 true 不一定代表“慢”，可能是主动降速保主库稳定；反过来，false 也不绝对安全，得结合 lag 和 load 综合判断

动态修改 throttle 阈值为什么不起作用

gh-ost 启动后，大部分 throttle 参数（比如 --max-load、--critical-load）是只读的，改了配置文件或发信号也不会生效。真正能热更新的只有两类：文件型限速和 HTTP 接口控制。

• 通过创建/删除限速文件生效：touch /tmp/gh-ost.throttle 立即限速，rm /tmp/gh-ost.throttle 立即恢复（前提是启动时指定了 --throttle-flag-file=/tmp/gh-ost.throttle）
• 调用 HTTP 接口：curl -X POST http://localhost:6060/throttle（限速）或 curl -X POST http://localhost:6060/unthrottle（恢复），但必须启动时加了 --serve-http
• 常见坑：误以为 --max-load="Threads_running=30" 可以运行时改，其实不行；改了之后要重启迁移任务才生效，而重启会丢失进度、重走全量

Throttle 触发后 DML 还在写吗

会写，但节奏被拉长。throttle 不是暂停，而是让 gh-ost 主动 sleep 更久、减少每批次 chunk 大小、降低 binlog 解析并发度。主库 DML 完全不受影响，ghost 表的写入变慢，但不会中断。

• 典型表现：copy rows 阶段速度骤降，throttled 字段持续为 true，但 status 仍是 Copying，不是 Paused
• 如果看到 state: "Throttled" 且长时间卡住，大概率是 --throttle-control-replicas 指向的从库延迟过大，或者该从库本身负载高、心跳慢，导致 gh-ost 误判
• 注意：--throttle-control-replicas 列表里的从库必须开启 log_slave_updates，否则无法获取其复制延迟，gh-ost 会静默忽略该节点，造成限速失效

mysql 8.0 下 throttle 监控指标不准怎么办

MySQL 8.0 默认关闭 performance_schema 的部分 instruments（比如 events_statements_current），而 gh-ost 的 --max-load 依赖这些表查 Threads_running 或 Threads_connected。关了就查不到，阈值永远不触发。

• 检查是否启用：select * FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/%' AND ENABLED = 'NO';，如有结果，需在 my.cnf 加 performance-schema-instrument='statement/%=ON' 并重启
• 更轻量的替代方案：改用 --max-load="Threads_running=25" → --max-load="Threads_running=25" --critical-load="Threads_running=50"，但必须确保 performance_schema.threads 表可用（8.0 默认开）
• 另一个坑：某些云厂商 RDS 屏蔽了 performance_schema 的写权限，此时只能退回到基于 SHOW GLOBAL STATUS 的指标（如 Threads_running），但精度下降，且不能用复杂表达式

throttle 不是开关，是调节阀。真正难的是判断“该不该压”——主库 CPU 突增 30% 是该 throttle，还是该立刻停掉迁移？这取决于你对那台机器上其他业务的了解程度，而不是 gh-ost 日志里那一行 throttled: true。