如何理解MySQL數(shù)據(jù)延遲跳動的問題

本篇內(nèi)容主要講解“如何理解MySQL數(shù)據(jù)延遲跳動的問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解MySQL數(shù)據(jù)延遲跳動的問題”吧!

按需制作網(wǎng)站可以根據(jù)自己的需求進行定制，網(wǎng)站制作、成都網(wǎng)站建設(shè)構(gòu)思過程中功能建設(shè)理應排到主要部位公司網(wǎng)站制作、成都網(wǎng)站建設(shè)的運用實際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實際意義

首先在高可用檢測中，有一套環(huán)境的檢測時斷時續(xù)，經(jīng)過排查發(fā)現(xiàn)是數(shù)據(jù)庫產(chǎn)生了延遲，在登錄到從庫show slave  status查看，會發(fā)現(xiàn)Seconds_behind_master的值是不斷跳動的，即從0~39~0~39這樣的頻率不斷跳動，讓人很搓火。

查看數(shù)據(jù)庫的相關(guān)日志發(fā)現(xiàn)竟然沒有任何可以參考的日志記錄，怎么分析這個問題呢，我們先來復現(xiàn)，于是我按照節(jié)奏抓取了3次問題出現(xiàn)的日志，即通過show  slave status連續(xù)監(jiān)測，抓取show slave  status輸出的結(jié)果保存下來，這樣我們就得到了一個問題發(fā)生過程中的偏移量變化，而這個變化則是在SQLThread在回放過程中產(chǎn)生的問題。

比如下面的一段輸出，我截取的是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開始分析這些日志過程中的明細，根據(jù)如下的命令可以很快得到轉(zhuǎn)儲的日志中相關(guān)的表有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

我逐步分析了每張表的數(shù)據(jù)操作情況，得到的信息還是比較有限，繼續(xù)做更進一步的分析，比如我們分析一下整個日志中的事務量大?。?/p>

# 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，這樣就能夠得到更細粒度的操作日志了。

進一步分析發(fā)現(xiàn)，整個業(yè)務使用了顯示事務的方式：SET  autocommit=0，整個事務中包含了幾個大SQL,里面存儲了很多操作日志明細，而且在事務操作過程中還基于Mybatis框架調(diào)用了多次select  count(1) from xxx的操作。

經(jīng)過和業(yè)務溝通也基本明確了以上問題。

到此，相信大家對“如何理解MySQL數(shù)據(jù)延遲跳動的問題”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！

當前文章：如何理解MySQL數(shù)據(jù)延遲跳動的問題
轉(zhuǎn)載來源：http://muchs.cn/article16/gcehdg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計、商城網(wǎng)站、品牌網(wǎng)站建設(shè)、網(wǎng)站收錄、建站公司、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)