多從庫時半同步複製不工作的BUG分析
作者:胡呈清、黃炎
問題描述
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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL主從複製之半同步複製MySql
- MySQL5.7主從複製-半同步複製搭建MySql
- MySQL 8 複製(二)——半同步複製MySql
- mysql 5.7半同步複製MySql
- MySQL5.7半同步複製報錯案例分析MySql
- mysql半同步複製的設定MySql
- Mysql5.7半同步複製MySql
- MySQL 5.7 多主一從(多源複製)同步配置MySql
- MySQL主從複製之非同步複製MySql非同步
- Mariadb之半同步複製叢集配置
- 半同步複製報錯mysql8.0.25MySql
- MySQL增強(Loss-less)半同步複製MySql
- 主從複製--非同步篇非同步
- linux下mysql主從複製,實現資料庫同步LinuxMySql資料庫
- #MySQL# mysql5.7新特性之半同步複製MySql
- MySQL 5.7的安裝及主從複製(主從同步)MySql主從同步
- 技術分享 | MySQL:從庫複製半個事務會怎麼樣?MySql
- 資料庫主從複製資料庫
- 淺複製導致的bug
- MySQL-主從複製之同步主從資料MySql
- mysql主從複製(一):一主多從MySql
- MySQL8.0的一個bug導致複製延時MySql
- mysql資料庫的主從複製和主主複製實踐MySql資料庫
- 故障分析 | MySQL 異地從庫複製延遲案例一則MySql
- 用 docker 學習 redis 主從複製2 主從同步的offsetDockerRedis主從同步
- MySQL 8 複製(一)——非同步複製MySql非同步
- Redis主從複製的全量和增量同步介紹Redis
- MySQL叢集之 主從複製 主主複製 一主多從 多主一叢 實現方式MySql
- 深入分析Redis的主從複製機制Redis
- Mysql半同步複製模式說明及配置示例 - 運維小結MySql模式運維
- SqlServer 主從複製錯誤分析--20598SQLServer
- 故障分析 | Redis 主從複製風暴Redis
- Redis主從複製斷點續傳的工作原理概述Redis斷點
- Mysql(Mariadb)資料庫主從複製MySql資料庫
- PostgreSQL 原始碼解讀(157)- 後臺程式#9(同步複製主庫掛起分析)SQL原始碼
- Redis基礎篇(六)資料同步:主從複製Redis
- MySQL並行複製延時時間不準確MySql並行
- MySQL半同步複製資料最終一致性驗證MySql