SQL pt-online-schema-change 的 max-lag 与复制延迟保护设置

–max-lag 监控从库的 seconds_behind_master（或 mysql 8.0.22+ 的 replica_lag），默认仅检查第一个从库，需配合 –check-slave-lag 和 –recursion-method 才覆盖全部从库。

max-lag 参数到底监控谁的延迟

pt-online-schema-change 的 --max-lag 不是看主库写入延迟，而是持续轮询从库的 Seconds_Behind_Master（或 MySQL 8.0.22+ 的 replica_lag）。它默认只查第一个从库，哪怕你有多个从库，其他从库滞后再多也不会触发暂停。

• 必须配合 --check-slave-lag + --recursion-method 才能覆盖所有从库，否则容易误判
• 如果从库启用了 LOG_BIN=OFF 或复制被手动停过，Seconds_Behind_Master 可能长期为 NULL 或 0，这时 --max-lag 会失效
• MySQL 8.0.22 后推荐用 --max-replica-lag 替代 --max-lag，语义更准确，且兼容 replica 术语

延迟超限后工具实际怎么暂停和恢复

不是立刻 kill 迁移进程，而是进入“等待窗口”：每秒检查一次从库延迟，直到连续 --max-lag-count 次（默认 3 次）都低于阈值才继续。期间原表写入不受影响，但新表的同步 INSERT/UPDATE/delete 暂停，pt-osc 会在 _new 表上堆积变更事件。

• 堆积过多会导致 trigger 执行变慢，进而拖慢主表 DML——这是最隐蔽的性能雪球
• 如果等待超时（--max-wait，默认无限制），工具不会自动退出，得靠外部信号（如 kill -TERM）终止
• 恢复后，工具会重放积压的变更；若积压太久，可能触发 Lock wait timeout exceeded，需人工清理临时表再重试

为什么设了 –max-lag 还是导致从库雪崩

根本原因在于 pt-osc 自身写入也会加剧复制压力：它一边在原表做 chunk copy，一边通过 trigger 往 _new 表写数据，这两路写入都会生成 binlog，放大从库回放负载。

• 尤其当原表有大字段（TEXT/BLOB）或高并发更新时，--chunk-size 设太大（如默认 1000）会让单次 copy 时间变长，binlog 写入更集中
• --critical-load 和 --max-lag 是两套机制：前者防主库过载，后者防从库延迟，但两者不联动；光设 --max-lag 不控 --chunk-size 或 --sleep，照样压垮从库
• 建议搭配 --chunk-index 指定覆盖索引列，避免全表扫描加重主库 I/O，间接缓解复制延迟

生产环境必须校验的三个配置组合

单独调 --max-lag 没用，它必须和另外两个参数形成闭环，否则保护逻辑形同虚设。

• --max-lag 必须小于从库日常波动上限（比如平时延迟 100ms，就别设成 50ms，应设 200ms）
• --check-interval 要大于 --max-lag 对应的典型恢复时间（例如延迟通常 3 秒内回落，--check-interval 至少设 5s，避免高频轮询徒增主库压力）
• --max-load 和 --critical-load 必须基于当前主库真实指标设置（如 Threads_running=20），不能沿用测试环境数值

真正难的是把这三组值对齐到同一观察窗口下的主从负载曲线——多数故障都出在这里，而不是参数本身写错了。