如何理解MySQL数据延迟跳动的问题
本篇内容主要讲解“如何理解MySQL数据延迟跳动的问题”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“如何理解MySQL数据延迟跳动的问题”吧!
首先在高可用检测中,有一套环境的检测时断时续,经过排查发现是数据库产生了延迟,在登录到从库show slave status查看,会发现Seconds_behind_master的值是不断跳动的,即从0~39~0~39这样的频率不断跳动,让人很搓火。
查看数据库的相关日志发现竟然没有任何可以参考的日志记录,怎么分析这个问题呢,我们先来复现,于是我按照节奏抓取了3次问题出现的日志,即通过show slave status连续监测,抓取show slave status输出的结果保存下来,这样我们就得到了一个问题发生过程中的偏移量变化,而这个变化则是在SQLThread在回放过程中产生的问题。
比如下面的一段输出,我截取的是Slave端的relay log进行分析,相应的字段为Relay_Log_Pos
Slave_IO_State:WaitingformastertosendeventMaster_Host:xxxxMaster_User:dba_replMaster_Port:4306Connect_Retry:60Master_Log_File:mysqlbin.000044Read_Master_Log_Pos:386125369Relay_Log_File:slave-relay-bin.000066Relay_Log_Pos:386125580Relay_Master_Log_File:mysqlbin.000044
所以很快得到了偏移量的变化情况:385983806 ,386062813 ,386125580
接着我使用mysqlbinlog开始分析这些日志过程中的明细,根据如下的命令可以很快得到转储的日志中相关的表有3张。
#grepINSERTrelaylog_xxxx.dump|awk'{print$3""$4}'|sed's/INTO//g'|sort|uniqact_action_exec_infoact_join_descdic_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-n100mysqlbinlog:[Warning]unknownvariable'loose-default-character-set=utf8'527852685268526852535253525352535253
可以看到是5K左右,算是比较大了,而这些额外的信息从哪里获得呢,我在主库开启了general_log,这样就能够得到更细粒度的操作日志了。
进一步分析发现,整个业务使用了显示事务的方式:SET autocommit=0,整个事务中包含了几个大SQL,里面存储了很多操作日志明细,而且在事务操作过程中还基于Mybatis框架调用了多次select count(1) from xxx的操作。
经过和业务沟通也基本明确了以上问题。
到此,相信大家对“如何理解MySQL数据延迟跳动的问题”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。