浅谈MySQL主从复制延迟

什么是主从延迟
在讨论如何解决主从延迟之前，我们先了解下什么是主从延迟。

为了完成主从复制，从库需要通过 I/O 线程获取主库中 dump 线程读取的 binlog 内容并写入到自己的中继日志 relay log 中，从库的 SQL 线程再读取中继日志，重做中继日志中的日志，相当于再执行一遍 SQL，更新自己的数据库，以达到数据的一致性。

与数据同步有关的时间点主要包括以下三个：

主库执行完一个事务，写入 binlog，将这个时刻记为 T1；
之后传给从库，将从库接收完这个 binlog 的时刻记为 T2；
从库执行完成这个事务，将这个时刻记为 T3。
所谓主从延迟，就是同一个事务，从库执行完成的时间与主库执行完成的时间之差，也就是 T3 - T1。

1  在网络正常的时候，日志从主库传给从库所需的时间是很短的，即 T2 - T1 的值是非常小的。也就是说，网络正常情况下，主从延迟的主要来源是从库接收完 binlog 和执行完这个事务之间的时间差。

由于主从延迟的存在，我们可能会发现，数据刚写入主库，结果却查不到，因为可能还未同步到从库。主从延迟越严重，该问题也愈加明显。
 

这种情况下需要优化网络，减少延迟。

主从延迟的来源
主库和从库在执行同一个事务的时候出现时间差的问题，主要原因包括但不限于以下几种情况：

有些部署条件下，从库所在机器的性能要比主库性能差。
从库的压力较大，即从库承受了大量的请求。
执行大事务。因为主库上必须等事务执行完成才会写入 binlog，再传给备库。如果一个主库上语句执行 10 分钟，那么这个事务可能会导致从库延迟 10 分钟。
从库的并行复制能力。

需要提高从库的性能，或者使用多从，也可以添加缓存软件如redis。

主从延迟的解决方案
解决主从延迟主要有以下方案：

配合 semi-sync 半同步复制；
一主多从，分摊从库压力；
强制走主库方案（强一致性）；
sleep 方案：主库更新后，读从库之前先 sleep 一下；
判断主备无延迟方案（例如判断 seconds_behind_master 参数是否已经等于 0、对比位点）；
并行复制 — 解决从库复制延迟的问题；
这里主要介绍我在项目中使用的几种方案，分别是半同步复制、实时性操作强制走主库、并行复制。