主库写了备库查不到？主从延迟四步定位法

发布时间：2026/7/30 20:50:10

十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

主从同步这个事，看起来简单。主库写、备库读，binlog 传过去、relay log 回放完，齐活。

但真出问题时能要人命。

上个月接到一个告警，业务方反馈"刚下的订单查不到"。排查下来是主从延迟 30 秒——用户刚在主库写完，备库还没同步到。30 秒在互联网业务里就是"数据丢了"。

干了这么多年 DBA，主从延迟是最容易被低估、也最容易背锅的问题。今天把排查方法论整理出来，从"发现延迟"到"定位根因"到"解决"，每一步都说清楚。

有好消息，也有踩坑的地方。各位耐心看完。

01 延迟从哪来？先搞清主从同步的完整链路

排查延迟之前，先搞清楚延迟可能出现在哪个环节。

主从同步不是"主库写完备库立刻就有"，它是一整条链路：

第一步：主库写 binlog。主库执行写操作后，把变更记录写入 binlog 文件。这一步通常很快，毫秒级。

第二步：binlog 传输到备库。备库的 I/O 线程连接主库，拉取 binlog，写入备库的 relay log。这一步的延迟取决于网络带宽和 binlog 产生速度。

第三步：备库回放 relay log。备库的 SQL 线程（或者多线程复制的工作线程）读取 relay log，把变更重放到备库数据上。这一步是延迟的重灾区。

第四步：备库数据可见。回放完成后，新数据才能在备库上被查询到。

关键认知：主从延迟不是"一个数字"，是整条链路累积的结果。排查时要逐段确认延迟出在哪个环节。

02 怎么发现延迟？别等业务方来报

主从延迟最可怕的不是"有延迟"，是"有延迟但没人知道"。

等业务方反馈"刚写的数据查不到"，问题已经发生很久了。DBA 应该在业务感知之前就发现并处理。

监控指标：看这三个数就够了

MySQL 8.0+：查询performance_schema.replication_connection_status和replication_applier_status，关注LAST_HEARTBEAT_TIMESTAMP（最后一次心跳时间）和SERVICE_STATE（复制状态）。

MySQL 5.7：执行SHOW SLAVE STATUS，关注Seconds_Behind_Master（延迟秒数）和Slave_IO_Running/Slave_SQL_Running（复制线程状态）。

PostgreSQL：查询pg_stat_replication，关注write_lag、flush_lag、replay_lag（分别对应写入、刷盘、回放延迟）。

三个阈值，分三级告警

延迟级别	阈值	响应动作
正常	< 1 秒	无需处理，常规监控
警告	1-10 秒	关注趋势，准备介入
危险	> 10 秒	立即排查，必要时切主

我的习惯：告警不要只设一个阈值。设三级，让团队知道"现在是什么状态"。只设一个"延迟 > 10 秒告警"，等告警响了再查，黄花菜都凉了。

03 排查流程——四步定位法

发现延迟后，按这个流程走，90% 的主从延迟都能定位到根因。

第一步：确认延迟在主库还是备库

怎么看？

在主库执行一个写入操作，记录时间戳。然后在备库查询这条数据，记录看到的时间戳。两者之差就是端到端延迟。

如果延迟很大，但主库的 binlog 写入很快（查 binlog 文件大小增长速度），说明问题不在主库，在传输或回放环节。

第二步：确认是传输慢还是回放慢

怎么看？

MySQL 执行SHOW SLAVE STATUS，对比两个值：

Read_Master_Log_Pos：I/O 线程读到的主库 binlog 位置
Exec_Master_Log_Pos：SQL 线程回放到的位置

如果Read_Master_Log_Pos落后Master_Log_Pos（主库当前位置）很多，说明传输慢——网络带宽不够或者主库 binlog 产生太快。

如果Read_Master_Log_Pos跟得上，但Exec_Master_Log_Pos落后很多，说明回放慢——备库 SQL 线程处理不过来。

第三步：定位回放慢的具体原因

回放慢是最常见的延迟原因。具体又分几种情况：

情况 A：大事务回放。主库执行了一个大事务（比如批量更新了 100 万行），备库回放这个事务时，SQL 线程被占住，其他小事务都得排队等。

怎么看？查SHOW PROCESSLIST，看备库 SQL 线程正在执行什么 SQL。如果是一条执行了几十秒还没完的 UPDATE 或 DELETE，基本就是大事务了。

情况 B：锁冲突。备库回放时遇到锁冲突，SQL 线程被阻塞。

怎么看？查备库的information_schema.innodb_trx和data_lock_waits，看有没有锁等待。

情况 C：备库硬件跟不上。主库用 SSD，备库用的是机械盘。同样的写入量，备库回放速度天然就慢。

怎么看？对比主备两端的磁盘 I/O 指标（iostat 看 iowait 和吞吐量）。如果备库磁盘利用率持续 100%，就是硬件瓶颈。

第四步：验证根因

定位到可能的根因后，验证一下：

如果是大事务，在测试环境模拟同样规模的事务，看备库回放耗时。
如果是锁冲突，分析锁等待链，确认阻塞源。
如果是硬件瓶颈，做磁盘 I/O 压测，确认备库磁盘确实扛不住。

经验：不要猜根因，要验证。我见过太多 DBA 凭经验"觉得"是大事务导致的，结果查半天发现是备库磁盘满了。

04 解决思路——对症下药

定位到根因后，解决思路就清晰了。

方案 A：大事务 → 拆分事务 + 并行复制

大事务是主从延迟的头号杀手。一个事务更新了 100 万行，备库 SQL 线程要一条一条回放，可能花几十分钟。

治标：把大事务拆成小事务。原来一个 UPDATE 更新 100 万行，改成每次更新 1 万行，分 100 次执行。每次持锁时间短，备库回放也快。

治本：开启并行复制。MySQL 5.7+ 支持多线程复制（MTS），备库可以用多个线程并行回放不同库或不同事务的变更。

-- MySQL 开启并行复制（基于库的并行）SETGLOBALslave_parallel_workers=4;-- MySQL 5.7+ 基于逻辑时钟的并行复制（推荐）SETGLOBALslave_parallel_type='LOGICAL_CLOCK';SETGLOBALslave_parallel_workers=8;

注意：并行复制不是线程越多越好。线程数超过 CPU 核心数后，收益递减。一般设成 CPU 核心数的 1-2 倍。

方案 B：网络传输慢 → 压缩 + 带宽扩容

如果确认是 binlog 传输慢，两个方向解决：

开启 binlog 压缩：MySQL 5.7+ 支持 binlog 传输压缩，在网络带宽紧张时能显著降低传输量。

-- 主库开启 binlog 压缩SETGLOBALbinlog_transaction_dependency_tracking='WRITESET';

扩容网络带宽：如果主备跨机房部署，网络带宽是硬瓶颈。该升级就升级，别省这个钱。

方案 C：备库硬件瓶颈 → 升级存储 + 读写分离

如果备库硬件确实扛不住，两条路：

短期：把备库的读流量切一部分走主库，降低备库负载。

长期：升级备库存储。把机械盘换成 SSD，或者上 NVMe。硬件升级的钱，比延迟导致业务损失的钱少多了。

对比：三种复制方案的延迟表现

把上面的内容做个对比，方便选型：

方案	延迟范围	适用场景	局限性
单线程复制	秒级到分钟级	小数据量、低写入频率	大事务必延迟
基于库的并行复制	亚秒级到秒级	多库部署、写入分散	单库大事务仍然慢
基于逻辑时钟的并行复制	亚秒级	生产环境推荐	需要 MySQL 5.7+
半同步复制	毫秒级（但有写入延迟）	数据零丢失场景	主库写入变慢