--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），不能沿用测试环境数值
真正难的是把这三组值对齐到同一观察窗口下的主从负载曲线——多数故障都出在这里，而不是参数本身写错了。
