适用场景

主从延迟的直接后果是读库数据不一致，业务侧表现为「刚提交查不到」。排查要分清是主库写入太快、从库回放太慢，还是被大事务卡住。不同原因，治理手段完全不同。

配置步骤（定位方法与常用命令）

-- 1) 基础状态
SHOW SLAVE STATUS\G
-- 关注：Seconds_Behind_Master、Slave_SQL_Running_State、Relay_Log_Pos

-- 2) 并行复制配置
SHOW VARIABLES LIKE 'slave_parallel%';
SHOW VARIABLES LIKE 'slave_preserve_commit_order';

-- 3) 主库当前事务与写入量
SHOW ENGINE INNODB STATUS\G        -- 看 TRANSACTIONS 段
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 10;
SELECT sum(trx_rows_modified) FROM information_schema.innodb_trx;

-- 4) 从库回放瓶颈
SHOW PROCESSLIST;
-- 观察 SQL 线程是否在回放大事务（State: Waiting for ... commit）

关键参数与建议

  • 先看现象：Seconds_Behind_Master 是秒级波动还是持续上涨
  • 定位方向：大事务、DDL、批量导入、单线程回放、从库资源瓶颈
  • 并发回放：5.7+ 打开并行复制（slave_parallel_workers + logical clock）
  • 大事务拆分：批处理改小批，单事务控制在合理行数内
  • 读写分离：延迟敏感业务走主库或用延迟阈值剔除延迟从库
  • 资源保障：从库 IO 能力与主库匹配，别用低配机器当从库
  • 监控告警：延迟超过阈值告警，并记录发生时段的写入压力

容易踩的坑

  • 只看 Seconds_Behind_Master，不看到底卡在哪个事务
  • 用低配机器当从库，IO 能力不足回放慢
  • 大事务不拆分，一次插入几十万行
  • 备份与从库回放抢 IO，延迟被放大
  • 延迟上涨时先重启从库，掩盖了根因
  • 读写分离没有延迟剔除，读库读到旧数据

验证与巡检

# 延迟与回放状态
mysql -e 'SHOW SLAVE STATUS\G' | grep -E 'Seconds_Behind|Slave_SQL_Running_State|Retrieved_Gtid'

# 从库 IO 能力
sar -d 1 5
iostat -x 1 3 | head -20

# 主库写入压力
mysql -e 'SHOW GLOBAL STATUS LIKE "Com_insert";' ; sleep 60 ; mysql -e 'SHOW GLOBAL STATUS LIKE "Com_insert";'
  • 巡检：延迟 < 5 秒、并行复制已开启、无长期大事务、从库 IO 利用率 < 70%

小结

主从延迟治理验收：业务高峰下延迟稳定在秒级、有延迟剔除机制、大事务有拆分规范并纳入代码评审。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。