如何理解MySQL数据延迟跳动的问题

60次阅读
没有评论

共计 1660 个字符,预计需要花费 5 分钟才能阅读完成。

本篇内容主要讲解“如何理解 MySQL 数据延迟跳动的问题”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让丸趣 TV 小编来带大家学习“如何理解 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: 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 的操作。

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

到此,相信大家对“如何理解 MySQL 数据延迟跳动的问题”有了更深的了解,不妨来实际操作一番吧!这里是丸趣 TV 网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-27发表,共计1660字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)