多從庫時半同步複製不工作的BUG分析

dunne21發表於2021-09-09


作者:胡呈清、黃炎

問題描述

MySQL版本:5.7.16,5.7.17,5.7.21

存在多個半同步從庫時,如果引數 rpl_semi_sync_master_wait_for_slave_count=1,啟動第1個半同步從庫時可以正常啟動,啟動第2個半同步從庫後有很大機率 slave_io_thread 停滯(複製狀態正常,Slave_IO_Running: Yes,Slave_SQL_Running: Yes,但是完全不同步主庫 binlog )

復現步驟

1. 主庫配置引數如下:

rpl_semi_sync_master_wait_for_slave_count = 1

rpl_semi_sync_master_wait_no_slave = OFF

rpl_semi_sync_master_enabled = ON

rpl_semi_sync_master_wait_point = AFTER_SYNC

2. 啟動從庫A的半同步複製 start slave,檢視從庫A複製正常

3. 啟動從庫B的半同步複製 start slave,檢視從庫B,複製執行緒正常,但是不同步主庫 binlog

分析過程

首先弄清楚這個問題 ,需要先結合MySQL其他的一些狀態資訊,尤其是主庫的 dump 執行緒狀態來進行分析:

1. 從庫A啟動複製後,主庫的半同步狀態已啟動:

1.png

再看主庫的 dump 執行緒,也已經啟動:

2.png

再看主庫的 error log,也顯示 dump 執行緒(21824)啟動成功,其啟動的半同步複製:

3_看圖王.png

2. 從庫B啟動複製後,主庫的半同步狀態,還是隻有1個半同步從庫 Rpl_semi_sync_master_clients=1:

4.png

再看主庫的 dump 執行緒,這時有3個 dump 執行緒,但是新起的那兩個一直為 starting 狀態:

5.jpg

6.jpg

再看主庫的 error log,21847 這個新的 dump 執行緒一直沒起來,直到1分鐘之後從庫 retry ( Connect_Retry 和 Master_Retry_Count 相關),主庫上又啟動了1個 dump 執行緒 21850,還是起不來,並且 21847 這個殭屍執行緒還停不掉:

7.png

3. 到這裡我們可以知道,從庫B  slave_io_thread 停滯的根本原因是因為主庫上對應的 dump 執行緒啟動不了。如何進一步分析執行緒呼叫情況?推薦使用 gstack 或者 pstack(實為gstack軟鏈)來檢視執行緒呼叫棧,其用法很簡單:gstack <process-id>

4. 看主庫的 gstack,可以看到 24102 執行緒(舊的複製 dump 執行緒)堆疊:

8.jpg

可以看到 24966 執行緒(新的複製 dump 執行緒)堆疊:

9.jpg

可以看到 24966 執行緒(新的複製 dump 執行緒)堆疊:

10.png

理論上 select 不應hang, Ack_receiver 中的邏輯也不會死迴圈,請教公司大神黃炎進行一波原始碼分析。

5.  semisync_master_ack_receiver.cc 的以下程式碼形成了對互斥鎖的搶佔, 餓死了其他競爭者:

11.png

在 mysql_mutex_unlock 呼叫後,應適當增加其他執行緒的排程機會。

試驗: 在 mysql_mutex_unlock 呼叫後增加 sched_yield();,可驗證問題現象消失。

結論

從庫 slave_io_thread 停滯的根本原因是主庫對應的 dump thread 啟動不了;

rpl_semi_sync_master_wait_for_slave_count=1 時,啟動第一個半同步後,主庫 ack_receiver 執行緒會不斷的迴圈判斷收到的 ack 數量是否 >= rpl_semi_sync_master_wait_for_slave_count,此時判斷為 true,ack_receiver基本不會空閒一直持有鎖。此時啟動第2個半同步,對應主庫要啟動第2個 dump thread,啟動 dump thread 要等待 ack_receiver 鎖釋放,一直等不到,所以第2個 dump thread 啟動不了。

 

相信各位DBA同學看了後會很震驚,“什麼?居然還有這樣的bug...”,這裡要說明一點,這個bug 觸發是有機率的,但是機率又很大。這個問題已經由我司大神在1月份提交了 bug 和 patch:,加上本人提交SR後時不時的催一催,昨天官方終於確認將修復在 5.7.23(官方最終另有修復方法,沒采納這個 patch,期待我司大神下期分析官方的修復程式碼)。

©著作權歸作者所有:來自51CTO部落格作者愛可生的原創作品,如需轉載,請註明出處,否則將追究法律責任


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/1600/viewspace-2820427/,如需轉載,請註明出處,否則將追究法律責任。

相關文章