MySQL数据延迟跳动的问题解决
今天分析了另外一个关于数据库延迟跳动的问题，也算是比较典型，这个过程中也有一些分析问题的方法和技巧工参考。
首先在高可用检测中，有一套环境的检测时断时续，经过排查发现是数据库产生了延迟，在登录到从库showslavestatus查看，会发现Seconds_behind_master的值是不断跳动的，即从0~39~0~39这样的频率不断跳动，让人很搓火。
查看数据库的相关日志发现竟然没有任何可以参考的日志记录，怎么分析这个问题呢，我们先来复现，于是我按照节奏抓取了3次问题出现的日志，即通过showslavestatus连续监测，抓取showslavestatus输出的结果保存下来，这样我们就得到了一个问题发生过程中的偏移量变化，而这个变化则是在SQLThread在回放过程中产生的问题。
比如下面的一段输出，我截取的是Slave端的relaylog进行分析，相应的字段为Relay_Log_Pos
Slave_IO_State:Waitingformastertosendevent 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张。
#grepINSERTrelaylog_xxxx.dump|awk'{print$3""$4}'|sed's/INTO//g'|sort|uniq
act_action_exec_info
act_join_desc
dic_subsidy_marketing_querylog_202008
我逐步分析了每张表的数据操作情况，得到的信息还是比较有限，继续做更进一步的分析，比如我们分析一下整个日志中的事务量大小：
#mysqlbinlogslave-relay-bin.000066|grep"GTID$(printf'\t')last_committed"-B1\
>|grep-E'^#at'|awk'{print$3}'\
>|awk'NR==1{tmp=$1}NR>1{print($1-tmp);tmp=$1}'\
>|sort-n-r|head-n100
mysqlbinlog:[Warning]unknownvariable'loose-default-character-set=utf8'
5278
5268
5268
5268
5253
5253
5253
5253
5253
可以看到是5K左右，算是比较大了，而这些额外的信息从哪里获得呢，我在主库开启了general_log，这样就能够得到更细粒度的操作日志了。
进一步分析发现，整个业务使用了显示事务的方式：SETautocommit=0，整个事务中包含了几个大SQL,里面存储了很多操作日志明细，而且在事务操作过程中还基于Mybatis框架调用了多次selectcount(1)fromxxx的操作。
经过和业务沟通也基本明确了以上问题。
以上就是MySQL数据延迟跳动的问题解决的详细内容，更多关于MySQL数据延迟跳动的资料请关注毛票票其它相关文章！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。