說真的，這個主從延遲你還真處理不了

本文做者：張鬆坡，騰訊雲數據庫架構師，主要負責騰訊雲數據庫MySQL、Redis等數據庫架構設計、數據庫運維、運營開發等工做。曾就任於騰訊新聞、騰訊視頻。

寫在前面，感謝騰訊雲數據庫架構師團隊祝海強、杜川、劉志祥在排障思路、源碼分析上面提供的幫助，讓我學習到了不少，不敢居功，特此鳴謝！

本文將以數據庫實際使用中的某典型案例來分析形成主從延遲的緣由。

主從延遲的緣由

一、某用戶在使用數據庫過程當中，出現主從延遲很大的狀況，show slave status\G，已經差了60多個binlog了。

二、觀察發現，應該是卡在一個大事物上面（Retrieved_Gtid_Set一直在上升，可是Executed_Gtid_Set卡在一個點不動了），經過分析relay_log找到這個大事物：是對錶A進行刪除操做的一個事物。

Relay_Log_File: relay-bin.000010
Relay_Log_Pos: 95133771複製代碼

看到這裏，感受又是一例在ROW模式下表沒有主鍵，引發的主從延遲。看看錶結構確認一下，發現這張表不小，字段有上百個，有主鍵，且是一張分區表，分區不少。這就有意思了！並非咱們碰到過屢次的因爲ROW模式下沒有主鍵，DML引發的主從延遲（PS：爲何這種狀況下會引發延遲？而是有主鍵，且走了二級索引，那爲何回放還會這麼慢呢？）。

後來瞭解到用戶是在存儲過程裏面調用detele語句來進行歸檔數據清理，看了一下存儲過程，如今的問題就能夠簡化爲：在存儲過程當中調用delete語句，走了二級索引刪除有主鍵的分區表，從機回放延遲。

這個時候，咱們須要拆解一下問題，控制好變量，一個一個的查：

一、直接執行delete，SQL會以statement的格式出現，且不會產生主從延遲。

二、調用procedure，該delete語句在procedure中執行的時候會變成ROW格式，且會致使延遲。

OK，有以上兩個測試，咱們的問題能夠聚焦爲：

一、爲何一樣delete語句，直接執行和在procedure裏面執行記錄的binlog格式不同（ROW格式的binlog致使回放慢，全局設置在mixed模式下，這條SQL應該走的是statement格式，爲何在procedure裏執行就變成了ROW格式，怎麼樣才能讓這條SQL再procedure裏執行變成statement記錄到binlog裏面）。

delete from xxxxx
where update_datetime < DATE_ADD(B_DATE,INTERVAL -1 day)
and DATE_FORMAT(update_datetime,'%i') not in ('00','05','10','15','20','25','30');複製代碼

經過show processlist，能夠看到這條delete在procedure內部執行的時候，被MySQL自動加上了NAME_CONST函數，因此致使了以ROW模式記錄binlog格式。那爲何在procedure中會被改寫成這樣的SQL呢？怎麼樣才能讓這條SQL記錄爲statement的格式呢？

看了MySQL官方在procedure裏面的限制描述，MySQL會自動加上NAME_CONST主要是爲了從機能夠識別到B_DATE這個SP的Local vairable，不至於從機回放的時候報錯。

二、爲何ROW模式的binlog在從庫回放的時候，即便delete的這張表有主鍵也很慢。

咱們先看一下SQL線程回放是卡在哪裏了？爲何會慢？

經過pstack抓取堆棧，找到SQL_thread線程對應的thread 15，再結合perf信息，能夠看到從機回放慢是卡在了bitmap_get_next_set()。

看一下bitmap_get_next_set()的代碼。

bitmap_get_next_set()都是一些位運算，速度按理來講應該很快。因此不該該是程序卡在了這個函數中，大機率是由於屢次調用了這個函數。因此咱們再往上層繼續看代碼。

get_next_used_partition(uint part_id) 直接調用了bitmap_get_next_set（），繼續往上看。

try_semi_consistent_read() 這個函數中出現了可疑的循環，這裏會調用m_tot_parts次get_next_used_partition。看了一下定義m_tot_parts是分區表的總分區數！！！

看到這裏，就真相大白了。

這個delele的SQL變動的行數大約在300W行左右，總共的分區表數是7200個。那麼這裏調用bitmap_get_next_set的次數就被放大成了216億次！

對比以statement格式回放，從機的堆棧信息，並不會進入bitmap_get_next_set。

解決方案

分析了這麼久，怎麼處理這麼問題呢？

• 方案1：咱們最後在SP中強制制定了session的binlog_format=statement，讓這條delete在從機以statement的模式回放，這樣就避免觸發MySQL中的這個bug。
• 方案2：修復內核。
• 方案3：在shell裏面去調度，而不使用存儲過程。

推薦

騰訊雲分佈式數據庫TDSQL在銀行傳統核心系統中的應用實踐​

迪B課堂 | 深刻淺出解讀MySQL數據行溢出​

騰訊雲國產數據庫TBase在保險行業的應用實踐​

點擊享受MySQL優惠活動