mysql延迟同步sql_delay_彻底终结MySQL同步延迟问题

作为一名DBA，在工作中会经常遇到一些MySQL主从同步延迟的问题，这些同步慢的问题，其实原因非常多，可能是因为主从的网络问题导致，可能是因为网络带宽问题导致，可能是因为大事务导致，也可能是因为单线程复制导致的延迟。最近遇到一个很典型的同步延迟问题，将分析过程写出来，希望对广大DBA在排查同步延迟问题有比较系统的方法论。

首先交代一下背景(不交代背景和场景的问题分析都是耍流氓)

最近有一组DB出现比较大的延迟，这组DB是专门用来存储监控数据，每分钟会使用load data的方式导入大量的数据。为了节省空间，将原来使用压缩表的innodb引擎转换成了TokuDB引擎，使用的版本和引擎如下：MySQL Version： 5.7

Storage Engine： TokuDB

转换后，发现主从延迟逐渐增大，基本每天落后主机大概50个binlog左右，大概延迟7.5个小时左右的数据，主机每天大概产生160个binlog，binlog列表如下图所示：

由于对该业务非常熟悉，因此很快就定位到造成主从同步延迟的原因，并很快就解决了延迟的问题。这里不直接说解决办法，而是想描述一套完整的解决主从延迟问题的思考方式，和大家一起来系统的做一些思考。带着问题去思考延迟的根本原因和解决办法。我想，这也许会更有意义。授人以鱼，不如授人以渔。接下来我们就一起开脑洞。

首先，既然产生了主从延迟，就说明在从机上的消费速度赶不上主机binlog产生的速度。我们先来思考一下可能的原因，并根据现场的蛛丝马迹去验证猜想的正确性。其实所谓的问题排查，就是提出可能问题猜想，然后不断去证明的过程。不同的是，每个人的经验不同，排查的质量也不尽头相同，仅此而已。那就来从各个可能的方面开脑洞吧。

网络

网络可能导致主从延迟的问题，比如主机或者从机的带宽打满、主从之间网络延迟很大，有可能会导致主上的binlog没有全量传输到从机，造成延迟。

我的那组DB的IO线程已经将对应的binlog近乎实时的拉取到了从机DB上，基本排除网络导致的延迟。还可以结合网络质量相关监控来进一步确认是网络的问题。

机器性能

从机使用了烂机器ÿ