MySQL数据延迟跳动的问题分析

 今天分析了另外一个关于数据库延迟跳动的据延问题，也算是迟跳比较典型，这个过程中也有一些分析问题的问题方法和技巧工参考。

首先在高可用检测中，分析有一套环境的据延检测时断时续，经过排查发现是迟跳数据库产生了延迟，在登录到从库show slave status查看，问题会发现Seconds_behind_master的分析值是不断跳动的，即从0~39~0~39这样的据延频率不断跳动，让人很搓火。迟跳

查看数据库的问题相关日志发现竟然没有任何可以参考的日志记录，怎么分析这个问题呢，分析我们先来复现，据延于是迟跳我按照节奏抓取了3次问题出现的b2b信息网日志，即通过show slave status连续监测，问题抓取show slave status输出的结果保存下来，这样我们就得到了一个问题发生过程中的偏移量变化，而这个变化则是在SQLThread在回放过程中产生的问题。

比如下面的一段输出，我截取的是Slave端的relay log进行分析，相应的字段为Relay_Log_Pos

Slave_IO_State: Waiting for master to send event                   Master_Host: xxxx                   Master_User: dba_repl                   Master_Port: 4306                 Connect_Retry: 60               Master_Log_File: mysqlbin.000044           Read_Master_Log_Pos: 386125369                Relay_Log_File: slave-relay-bin.000066                 Relay_Log_Pos: 386125580         Relay_Master_Log_File: mysqlbin.000044

所以很快得到了偏移量的变化情况：385983806 ，386062813 ，386125580

接着我使用mysqlbinlog开始分析这些日志过程中的明细，根据如下的命令可以很快得到转储的日志中相关的表有3张。免费信息发布网

# grep INSERT  relaylog_xxxx.dump |awk { print $3 " " $4}|sed s/INTO//g|sort|uniq  act_action_exec_info  act_join_desc  dic_subsidy_marketing_querylog_202008 

我逐步分析了每张表的数据操作情况，得到的信息还是比较有限，继续做更进一步的分析，比如我们分析一下整个日志中的事务量大小：

# mysqlbinlog slave-relay-bin.000066 | grep "GTID$(printf \t)last_committed" -B 1 \ >                                     | grep -E ^# at | awk { print $3} \ >                                     | awk NR==1 { tmp=$1} NR>1 { print ($1-tmp);tmp=$1} \ >                                     | sort -n -r | head -n 100 mysqlbinlog: [Warning] unknown variable loose-default-character-set=utf8 5278 5268 5268 5268 5253 5253 5253 5253 5253

可以看到是5K左右，算是比较大了，而这些额外的信息从哪里获得呢，我在主库开启了general_log，这样就能够得到更细粒度的操作日志了。

进一步分析发现，整个业务使用了显示事务的方式：SET autocommit=0，整个事务中包含了几个大SQL,里面存储了很多操作日志明细，而且在事务操作过程中还基于Mybatis框架调用了多次select count(1) from xxx的操作。

经过和业务沟通也基本明确了以上问题。

云服务器提供商

很赞哦!（69852）