MySQL主从复制延迟常见原因及解决方法有哪些？

承蒙大家的支持，刚上市的《MySQL实战》已经跃居京东自营数据库图书热卖榜第 1 名，收到的反馈也普遍不错。对该书感兴趣的童鞋可通过右边的链接购买。目前，京东自营有活动，只需 5 折。 主从延迟作为 MySQL 的痛点已经存在很多年了，以至于大家都有一种错觉：有 MySQL 复制的地方就有主从延迟。 对于主从延迟的原因，很多人将之归结为从库的单线程重放。 但实际上，这个说法比较片面，因为很多场景，并行复制方案也解决不了，譬如从库 SQL 线程被阻塞了，从库磁盘 IO 存在瓶颈等。 很多童鞋在分析此类问题时缺乏一个系统的方法论，以致无法准确地定位出主从延迟的根本原因。 下面就如何分析主从延迟做一个系统、全面的总结。 本文主要包括以下两方面的内容。 如何分析主从延迟。 主从延迟的常见原因及解决方法。 下一篇文章会介绍如何监控主从延迟，包括如何解读 Seconds_Behind_Master、Seconds_Behind_Master 的局限性、pt-heartbeat 及 MySQL 8.0 原生的解决方案，敬请留意。 如何分析主从延迟 分析主从延迟一般会采集以下三类信息。 从库服务器的负载情况 为什么要首先查看服务器的负载情况呢？因为软件层面的所有操作都需要系统资源来支撑。 常见的系统资源有四类：CPU、内存、IO、网络。对于主从延迟，一般会重点关注 CPU 和 IO 。 分析 CPU 是否达到瓶颈，常用的命令是 top，通过 top 我们可以直观地看到主机的 CPU 使用情况。以下是 top 中 CPU 相关的输出。 Cpu(s):0.2%us,0.2%sy,0.0%ni,99.5%id,0.0%wa,0.0%hi,0.2%si,0.0%st 下面我们看看各个指标的具体含义。 us：处理用户态（ user ）任务的 CPU 时间占比。 sy：处理内核态（ system ）任务的 CPU 时间占比。 ni：处理低优先级进程用户态任务的 CPU 时间占比。 进程的优先级由 nice 值决定，nine 的范围是 -20 ～ 19 ，值越大，优先级越低。其中，1 ～ 19 称之为低优先级。 id：处于空闲状态（ idle ）的 CPU 时间占比。 wa：等待 IO 的 CPU 时间占比。 hi：处理硬中断（ irq ）的 CPU 时间占比。 si：处理软中断（ softirq ）的 CPU 使用率。 st：当系统运行在虚拟机中的时候，被其它虚拟机占用（ steal ）的 CPU 时间占比。 一般来说，当 CPU 使用率 （ 1 - 处于空闲状态的 CPU 时间占比 ）超过 90% 时，需引起足够关注。毕竟，对于数据库应用来说，CPU 很少是瓶颈，除非有大量的慢 SQL 。 接下来看看 IO。 查看磁盘 IO 负载情况，常用的命令是 iostat 。 #iostat-xm1 avg-cpu:%user%nice%system%iowait%steal%idle 4.210.001.770.350.0093.67 Device:rrqm/swrqm/sr/sw/srMB/swMB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%util sda0.000.000.000.000.000.000.000.000.000.000.000.000.00 sdb0.000.00841.003234.0013.1438.9626.190.600.150.300.110.0832.60 命令中指定了 3 个选项，其中， -x：打印扩展信息。 -m：指定吞吐量的单位是 MB/s ，默认是 KB/s 。 1：每隔 1s 打印一次。 下面看看输出中各指标的具体含义。 rrqm/s：每秒被合并的读请求的数量。 wrqm/s：每秒被合并的写请求的数量。 r/s：每秒发送给磁盘的读请求的数量。 w/s：每秒写入磁盘的写请求的数量。注意，这里的请求是合并后的请求。r/s + w/s 等于 IOPS 。 rMB/s：每秒从磁盘读取的数据量。 wMB/s：每秒写入磁盘的数据量。rMB/s + wMB/s 等于吞吐量。 avgrq-sz：I/O 请求的平均大小，单位是扇区，扇区的大小是 512 字节。一般而言，I/O 请求越大，耗时越长。 avgqu-sz：队列里的平均 I/O 请求数量。 await：I/O 请求的平均耗时，包括磁盘的实际处理时间及队列中的等待时间，单位 ms 。 其中，r_await 是读请求的平均耗时，w_await 是写请求的平均耗时。