本篇內(nèi)容主要講解“分析數(shù)據(jù)庫Seconds_Behind_Master延遲的原因”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“分析數(shù)據(jù)庫Seconds_Behind_Master延遲的原因”吧!

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供海南網(wǎng)站建設(shè)、海南做網(wǎng)站、海南網(wǎng)站設(shè)計(jì)、海南網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、海南企業(yè)網(wǎng)站模板建站服務(wù)，10年海南做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

一、總結(jié)

（1）第一類：

這一類延遲情況可能造成服務(wù)器有較高的負(fù)載，可能是CPU/IO的負(fù)載。因?yàn)閺膸煸趯?shí)際執(zhí)行Event，如果我們服務(wù)器的負(fù)載比較高應(yīng)該考慮這幾種情況。

• 大事務(wù)造成的延遲，其延遲會(huì)不會(huì)從0開始增加，而是直接從主庫執(zhí)行了多久開始。比如主庫執(zhí)行這個(gè)事務(wù)花費(fèi)的20秒，要么延遲就會(huì)從20開始，可以自己細(xì)心觀察一下很容易看到。這是因?yàn)镼uery Event中沒有準(zhǔn)確的執(zhí)行時(shí)間。

• 大表DDL造成的延遲，其延遲會(huì)從0開始增加，因?yàn)镼uery Event記錄了準(zhǔn)確的執(zhí)行時(shí)間

• 表沒有合理的使用主鍵或者唯一鍵造成的延遲。這種情況不要以為設(shè)置slave_rows_search_algorithms參數(shù)為 INDEX_SCAN,HASH_SCAN就可以完全解決問題。

• 由于參數(shù)sync_relay_log，sync_master_info，sync_relay_log_info不合理導(dǎo)致，特別是sync_relay_log會(huì)極大的影響從庫的性能。原因我們在第26節(jié)進(jìn)行過描述，因?yàn)閟ync_relay_log設(shè)置為1會(huì)導(dǎo)致大量relay log刷盤操作。

• 是否從庫開啟了記錄binary log功能即log_slave_updates參數(shù)開啟，如果不是必要可以關(guān)閉掉。這種情況我遇到很多次了。

（2）第二類：

這一類延遲情況往往不會(huì)造成服務(wù)器有較高的負(fù)載。它們要么沒有實(shí)際的執(zhí)行Event，要么就是做了特殊的操作造成的。

• 長期未提交的事務(wù)可能造成延遲瞬間增加，因?yàn)镚TID_EVENT和XID_EVENT是提交時(shí)間其他Event是命令發(fā)起的時(shí)間。這個(gè)我們在第27節(jié)中舉例描述過了。

• Innodb層的行鎖造成的延遲，這種是在從庫有修改操作并且和SQL線程修改的數(shù)據(jù)有沖突的情況下造成的，因?yàn)槲覀兦懊?3節(jié)說過SQL線程執(zhí)行Event也會(huì)開啟事務(wù)和獲取行鎖，下面我們進(jìn)行測試。

• MySQL層的MDL LOCK造成的延遲，這種情況可能是由于SQL線程執(zhí)行某些DDL操作但是從庫上做了鎖表操作造成。

• MTS中不合理的設(shè)置參數(shù)slave_checkpoint_period參數(shù)導(dǎo)致。

• 在從庫運(yùn)行期間手動(dòng)改大了從庫服務(wù)器時(shí)間。

二、相關(guān)測試

因?yàn)樯厦娴难舆t情形很多我們都已經(jīng)測試和講述過了。下面我們測試鎖造成的延遲情形。

（1）Innodb層的行鎖造成的延遲

這個(gè)很容測試，我只要先在從庫做一個(gè)事務(wù)和SQL線程修改的數(shù)據(jù)相同即可以出現(xiàn)，大概測試如下：

從庫：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from tmpk;
Query OK, 4 rows affected (0.00 sec)
不要提交
主庫執(zhí)行同樣的語句
mysql> delete from tmpk;
Query OK, 4 rows affected (0.30 sec)

這個(gè)時(shí)候你會(huì)觀察到延遲如下：

如果查看sys.innodb_lock_waits能看到如下的結(jié)果：

當(dāng)然如果查看INNODB_TRX也可以觀察到事務(wù)的存在，這里就不截圖了，大家可以自己試試。

（2）MySQL層的MDL LOCK造成的延遲

這種情況也非常容易測試，我們只需要開啟一個(gè)事務(wù)做一個(gè)select，然后主庫對同樣的表做DDL就可以出現(xiàn)如下：

從庫：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> 
mysql> 
mysql> select * from tkkk limit 1;
+------+------+------+
| a    | b    | c    |
+------+------+------+
|    3 |    3 |  100 |
+------+------+------+
1 row in set (0.00 sec)
不要提交，表上MDL LOCK就不會(huì)釋放
主庫執(zhí)行語句：
mysql> alter table tmpk add testc int ;
Query OK, 0 rows affected (1.14 sec)
Records: 0  Duplicates: 0  Warnings: 0

這個(gè)時(shí)候你將會(huì)看到如下的信息：

我們可以通過state看到這是等待MDL lock獲取而導(dǎo)致的延遲

三、總結(jié)

通過整個(gè)系列，我們應(yīng)該清楚了Seconds_Behind_Master計(jì)算的方法，同時(shí)如果出現(xiàn)了延遲，我們首先查看從庫是否有負(fù)載，根據(jù)是否有負(fù)載進(jìn)行區(qū)別對待，注意這里的負(fù)載一定要使用top -H查看io/sql/woker線程的負(fù)載。我曾不止一次的遇到朋友問我延遲問題，當(dāng)我問他負(fù)載如何的時(shí)候他告訴我負(fù)載不高啊整體負(fù)載也就不到2，這里我們應(yīng)該注意的是對于一個(gè)線程只能使用到一個(gè)CPU核，雖然整體負(fù)載不到2但是可能io/sql/worker線程已經(jīng)跑滿了，實(shí)際上負(fù)載已經(jīng)很高了，我們來看下面的這個(gè)截圖就是sql線程負(fù)載高的截圖如下：

這個(gè)截圖我們發(fā)現(xiàn)雖然整體負(fù)載不高在1多一點(diǎn)，但是Lwp號20092的線程已經(jīng)跑滿了，這個(gè)線程就是我們的sql線程，這個(gè)時(shí)候出現(xiàn)延遲是很可能的，這個(gè)截圖正是來自一個(gè)沒有合理使用主鍵或者唯一鍵造成的延遲的案例。

我們查看CPU負(fù)載應(yīng)該使用top -H去查看，查看io負(fù)載可以使用iotop，iostat等工具。我需要強(qiáng)調(diào)一下看MySQL負(fù)載的時(shí)候我們必須用線程的眼光去看。

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

網(wǎng)頁題目：分析數(shù)據(jù)庫Seconds_Behind_Master延遲的原因-創(chuàng)新互聯(lián)
本文鏈接：http://jinyejixie.com/article38/dedpsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、企業(yè)網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)公司、小程序開發(fā)、外貿(mào)建站、虛擬主機(jī)

廣告

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