延迟的处置顺序
从库延迟要先判断瓶颈在哪一段：IO 线程跟不上主库写入、SQL 线程重放慢、还是从库自身被大查询占满资源。处置遵循先止血后治本：先让从库追上来（提高并行度、暂停从库上的重查询、必要时限流主库写入），再回到根因层面治结构问题，例如补主键、拆大事务、调整索引。
基本信息
| 适用平台 | MySQL 5.7 / 8.0、MariaDB |
|---|---|
| 观察命令 | SHOW REPLICA STATUS\G 的 Seconds_Behind_Source |
| 并行参数 | replica_parallel_workers、replica_parallel_type |
| 顺序保证 | replica_preserve_commit_order=ON |
| 区分线程 | Replica_IO_Running 与 Replica_SQL_Running |
典型使用场景
- 批量导入或大事务后从库落后数分钟，需要快速追赶
- 延迟持续增长而非一次性抖动，怀疑结构或硬件瓶颈
- 读流量路由到从库前先判断延迟是否在可接受范围
- 切换演练前确认延迟已归零，避免切到落后数据
- 新增从库后首次追赶阶段观察复制吞吐是否正常
定位与处置命令
定位与处置命令
-- 先看延迟数值与两个线程状态
SHOW REPLICA STATUS\G
-- 关注：Seconds_Behind_Source、Replica_IO_Running、Replica_SQL_Running
-- 查看并行相关参数
SHOW VARIABLES LIKE 'replica_parallel%';
SHOW VARIABLES LIKE 'replica_preserve_commit_order';
-- 需要暂停重放（例如先让读流量降下来）
STOP REPLICA SQL_THREAD;
START REPLICA SQL_THREAD;
-- 从库上正在跑的重查询
SELECT id, user, time, state, info FROM information_schema.processlist
WHERE command <> 'Sleep' ORDER BY time DESC LIMIT 10;延迟成因与处置
| 现象 | 原因 | 处置 |
|---|---|---|
| IO 线程落后 | 主库写入量大、网络带宽不足 | 提升链路带宽，检查是否频繁重连 |
| SQL 线程慢 | 并行度低、大事务串行重放 | 提高并行度并启用 WRITESET 依赖跟踪 |
| 从库被查询压满 | 报表或备份任务占用 IO/CPU | 错峰执行，重查询走专用副本 |
| 结构缺主键 | 按行重放退化为全表扫描 | 补主键，避免无主键表的大批量更新 |
| 单次延迟不再下降 | 大事务或长回滚在执行 | 等待回滚结束，必要时评估重建副本 |
replica_preserve_commit_order=ON 保证并行重放时提交顺序与源端一致，这是并行复制下能够安全切换的前提，改参数时不要为了吞吐随意关掉。
不要用清空 relay log 或跳过事务的方式「重置延迟」：跳过事务会让从库与主库数据永久不一致，之后的所有读数都不可信。