适用场景

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

配置步骤（治理手段与业务配合）

-- 1) 并行复制（需要重启或动态设置）
SET GLOBAL slave_parallel_workers = 8;
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_preserve_commit_order = ON;

-- 2) 大事务拆分（应用侧）
-- 原来：一次 INSERT 20 万行
-- 改为：每批 1000 行，批间 sleep 20ms

-- 3) DDL 与批量任务错峰
-- 大表变更放到低峰，批量导入与备份错开
# 业务侧约定
1) 延迟敏感接口（支付结果、订单状态）读主库
2) 列表与统计读从库，允许秒级延迟
3) 从库延迟超阈值自动从读库池摘除
4) 批量导入走专用通道，避开业务高峰

关键参数与建议

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

容易踩的坑

  • 并行复制开了但没开 commit order，从库数据出现短暂不一致
  • 大事务只让应用「注意」，没有代码评审约束
  • 全部业务读从库，延迟一涨全站异常
  • 从库摘除机制没有恢复逻辑，节点长期不回流
  • 备份与批量导入同窗口，延迟反复
  • 没有延迟历史数据，无法判断是否在恶化

验证与巡检

# 治理效果
mysql -e 'SHOW SLAVE STATUS\G' | grep Seconds_Behind
# 记录一周：延迟最大值、超阈值次数、摘除次数

# 大事务审计：慢日志中事务行数分布
  • 巡检：周报含延迟峰值、摘除/回流记录、大事务拆分效果

小结

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

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