上周三下午，业务同事发消息说报表数据对不上。同一张订单表，主库查是4.8万条，从库查只有4.6万条。登上从库一看，`Seconds_Behind_Master` 显示1786，快30分钟了。

当时心里一沉。30分钟的延迟，从库上的读请求拿到的全是半小时前的数据。读写分离嘛，从库读到的全是脏数据。

干了15年数据库，主从延迟少说也碰过百来次。Oracle的Data Guard、MySQL的复制机制，原理不同，但排查思路相通。这次事故的排查过程完整讲一遍，各位看完，至少延迟告警来了不慌。

## 先搞清楚：主从延迟是怎么产生的

说白了，主从复制就是三步走：

1. **主库**把变更写到binlog

2. **从库的IO线程**拉取binlog，写到本地的relay log

3. **从库的SQL线程**读relay log，回放SQL

延迟可能出现在第2步，也可能出现在第3步。实际碰到的情况，十有八九卡在第3步，SQL线程回放跟不上。

IO线程通常不是瓶颈，除非网络带宽不够。SQL线程就不一样了，老版本是单线程回放，主库上10个并发线程同时写入，到从库变成1个线程慢慢回放，不延迟才怪。

这跟Oracle Data Guard的思路不一样。Oracle的Redo Apply是物理级别的块变更应用，天然可以多进程并行。MySQL是逻辑回放，SQL线程得把一条条SQL重跑一遍，本质上就慢。

## 第一步：看延迟状态，判断严重程度

上来别急着调参数。先看清楚延迟到底有多大，是个别从库的问题还是所有从库都有问题。

在从库上执行：

```
SHOW SLAVE STATUS\G
```
重点关注这几个字段：

```
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 1786
Relay_Log_Space: 2048576384
```
Seconds_Behind_Master 就是延迟秒数。但有个坑：这个值是SQL线程当前回放的事务时间戳和主库当前时间的差值。SQL线程卡在大事务上时，这个数字会一直不动，然后突然跳一大截。

再看 Relay_Log_Space。relay log堆积到几个G甚至十几个G，说明SQL线程确实严重跟不上了。

这次事故里，1786秒的延迟加上2G的relay log堆积，显然是SQL线程回放出了问题。

## 第二步：看SQL线程卡在哪

接下来要搞清楚SQL线程到底在干什么。MySQL 5.7以上可以用 `performance_schema` 查看：

```
SELECT * FROM performance_schema.threads
WHERE NAME = 'thread/sql/replica_sql';
```
或者直接看当前正在回放的事务：

```
SHOW PROCESSLIST;
```
找到 `system user` 身份、状态为 `Reading event from the relay log` 或者 `Applying batch of row changes` 的线程，那就是SQL线程。

我这次看到SQL线程在回放一条 `UPDATE`，对着一张3000万行的订单明细表。拿这条SQL在主库上跑了下 `EXPLAIN`，没走索引，全表扫描。

主库上一条烂SQL可能影响不大，有缓存、有并发。但到从库单线程回放，杀伤力翻好几倍。

## 第三步：查有没有大事务

大事务是主从延迟最大的坑。怎么查？

在主库上，查当前和最近的长事务：

```
SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS running_seconds,
       trx_rows_modified
FROM information_schema.innodb_trx
ORDER BY trx_rows_modified DESC;
```
如果你看到 `trx_rows_modified` 达到了几十万甚至上百万，那就是大事务没跑了。

我这次排查时，发现有个定时任务在主库上一次性 `UPDATE` 了40万行。这个操作在主库跑了3秒（并发高、buffer命中率好），但到了从库，单线程回放这40万行变更，花了将近20分钟。

跟Oracle比一下。Oracle的Data Guard是物理复制，40万行变更被拆成一堆Redo块，可以并行应用。MySQL呢？逻辑复制，这40万行变更就是一条条 `UPDATE` 或行镜像，得一个个回放。

大事务拆小，分批提交。别在主库上一次 `UPDATE` 几十万行。业务允许的话，拆成每次5000行。

## 第四步：检查从库资源瓶颈

如果SQL线程回放的都是正常大小的事务，但还是慢，那就要看从库自身有没有资源瓶颈。

先看CPU和IO。从库回放是IO密集型操作。看 `iostat`，`%util` 长期超过80%就说明磁盘IO是瓶颈。特别是机械硬盘，随机写性能差，回放天然就慢。

```
iostat -x 1 10
```
再看锁等待。从库上如果有长查询，可能和SQL线程回放产生锁冲突：

```
SELECT * FROM information_schema.innodb_lock_waits;
```
或者用 `SHOW ENGINE INNODB STATUS` 看LATEST DETECTED DEADLOCK部分。

之前碰到过一回：从库上有个报表查询，跑了2分钟。这查询持着某个范围的共享锁，SQL线程回放时要拿同一范围的排他锁，被阻塞了。主库的变更一个接一个进来，从库卡在那里动不了，延迟越来越大。

## 第五步：并行复制，该开就开

前面排查完了，该调的参数调起来。MySQL 5.7引入了基于组提交（Group Commit）的并行复制，SQL线程回放速度能上去不少。

检查当前是否开启：

```
SHOW VARIABLES LIKE 'slave_parallel%';
```
参数就三个：

```
# 开启并行复制，建议设置为逻辑CPU数的一半
slave_parallel_workers = 8

# 基于组提交的并行模式（MySQL 5.7+）
slave_parallel_type = LOGICAL_CLOCK

# 并行回放时保持事务顺序（保证主从一致性）
slave_preserve_commit_order = ON
```
开启后，SQL线程变成1个协调线程加8个worker线程，回放速度直接翻几倍。

不过并行复制也有局限。事务之间有数据依赖（操作同一行），worker还是得串行。真正能并行的，是操作不同行、不同表的事务。

调完参数重启复制，延迟从30分钟开始快速追赶。10分钟左右追平，`Seconds_Behind_Master` 回到0。

## 这次事故的完整复盘

|时间|动作|耗时|
|:-:|:-:|:-:|
|14:20|业务反馈数据不一致|-|
|14:22|登从库查 `SHOW SLAVE STATUS`，确认延迟1786秒|2分钟|
|14:25|查PROCESSLIST，定位到大事务|3分钟|
|14:30|在主库查 `innodb_trx`，确认40万行大事务|5分钟|
|14:35|检查从库IO和锁等待，排除资源瓶颈|5分钟|
|14:40|调整并行复制参数，重启复制|5分钟|
|14:50|延迟追平，确认数据一致|10分钟|

总共30分钟定位并解决。事后推动开发同事把那个定时任务改成分批提交，每批5000行，问题没再复发。

## 日常巡检建议

这些年我管主从复制，养成了一套习惯：

1. Seconds_Behind_Master 超过60秒就告警，别等到30分钟才发现。配连续告警，别只告一次就完了

2. MySQL 5.7以上的环境，并行复制默认就该开。`slave_parallel_workers` 设CPU核数的一半，别太激进

3. 超过1万行的批量DML必须分批提交，没有例外。这事儿我踩过坑，真没商量余地

4. 报表查询走专门的报表从库，别和实时同步从库混在一起。锁冲突是延迟里最隐蔽的推手

5. `Relay_Log_Space` 超过1G就要关注，超过5G基本就是事故预兆

6. 业务对数据一致性要求高的核心库，考虑开半同步（`rpl_semi_sync`）。主库等至少一个从库确认收到binlog后才返回commit成功，代价是少量性能损耗

最后一句。主从延迟就是个症状，盯数字没意义，得去查背后的根因。是大事务？烂SQL？资源瓶颈？还是复制参数没配对？找到根因，延迟自然就消了。

各位在生产中遇到过什么离谱的主从延迟案例？评论区聊聊，互相避坑。

上周三下午，业务同事发消息说报表数据对不上。同一张订单表，主库查是4.8万条，从库查只有4.6万条。登上从库一看，Seconds_Behind_Master 显示1786，快30分钟了。

MySQL主从延迟30分钟？DBA手把手排查全流程，5步定位根因

从真实生产事故出发，详解MySQL主从延迟的排查思路和5个关键步骤，覆盖并行复制优化、大事务拆分、从库资源瓶颈等常见场景。

数据库

运维

后端

MySQL主从延迟排查实战：30分钟数据不一致事故复盘。从库1786秒延迟、2G relaylog堆积，定位大事务导致SQL线程回放阻塞。详解5步排查法：检查延迟状态、分析SQL线程、识别大事务、排除资源瓶颈、开启并行复制。分享批量DML分批提交、并行复制参数调优等实战经验，助你快速解决主从同步问题。

腾讯云数据库特惠，新用户首单0.5折起


腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL主从延迟30分钟？DBA手把手排查全流程，5步定位根因-腾讯云开发者社区-腾讯云

MySQL主从延迟30分钟？DBA手把手排查全流程，5步定位根因

MySQL主从延迟30分钟？DBA手把手排查全流程，5步定位根因

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐