作者介紹

王晶，中國移動DBA，負(fù)責(zé)“移動云”業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫集成架構(gòu)設(shè)計、運(yùn)維、優(yōu)化等工作；擅長技術(shù)領(lǐng)域MySQL，獲Oracle頒發(fā)的“MySQL DBA”官方認(rèn)證，熟悉MySQL復(fù)制結(jié)構(gòu)、MHA、cluster等多種架構(gòu)及運(yùn)維優(yōu)化。

?

發(fā)現(xiàn)故障的時間正值大年初二，在各種鋪天蓋地的拜年信息和微信紅包之中，我發(fā)現(xiàn)了手機(jī)上的這條告警通知：

?

PROBLEM:Disaster:?Galera?cluster?has?node?down。我生產(chǎn)環(huán)境的Galera集群有一個節(jié)點宕機(jī)了。

可能有的人不太熟悉MySQL Galera集群，下面先介紹一下出故障的集群信息。

PXC：

我們生產(chǎn)上用的是Percona的一個MySQL分支版本，PerconaXtradb Cluster，簡稱PXC，這是一個可以實時同步的MySQL集群，基于廣播write set和事務(wù)驗證來實現(xiàn)多節(jié)點同時commit，沖突事務(wù)回滾的功能。強(qiáng)數(shù)據(jù)一致性保證。

Galera Replication原理總結(jié)：

1. 事務(wù)在本地節(jié)點執(zhí)行時采取樂觀策略，成功廣播到所有節(jié)點后再做沖突檢測；

2. 檢測出沖突時，本地事務(wù)優(yōu)先被回滾；

3. 每個節(jié)點獨(dú)立、異步執(zhí)行隊列中的WS；

4. 事務(wù)T在A節(jié)點執(zhí)行成功返回客戶端后，其他節(jié)點保證T一定會被執(zhí)行，因此有可能存在延遲，即虛擬同步。

Galera復(fù)制的架構(gòu)圖：

Galera flow control：

Galera是同步復(fù)制（虛擬同步）方案，事務(wù)在本地節(jié)點（客戶端提交事務(wù)的節(jié)點）上提交成功時，其它節(jié)點保證執(zhí)行該事務(wù)。在提交事務(wù)時，本地節(jié)點把事務(wù)復(fù)制到所有節(jié)點，之后各個節(jié)點獨(dú)立異步地進(jìn)行certification test、事務(wù)插入待執(zhí)行隊列、執(zhí)行事務(wù)。然而，由于不同節(jié)點之間執(zhí)行事務(wù)的速度不一樣，長時間運(yùn)行后，慢節(jié)點的待執(zhí)行隊列可能會越積越長，最終可能導(dǎo)致事務(wù)丟失。

Galera內(nèi)部實現(xiàn)了flow control，作用就是協(xié)調(diào)各個節(jié)點，保證所有節(jié)點執(zhí)行事務(wù)的速度大于隊列增長速度，從而避免丟失事務(wù)。

實現(xiàn)原理很簡單。整個Galera Cluster中，同時只有一個節(jié)點可以廣播消息（數(shù)據(jù)），每個節(jié)點都會獲得廣播消息的機(jī)會（獲得機(jī)會后也可以不廣播），當(dāng)慢節(jié)點的待執(zhí)行隊列超過一定長度后，它會廣播一個FC_PAUSE消息，所以節(jié)點收到消息后都會暫緩廣播消息，直到該慢節(jié)點的待執(zhí)行隊列長度減小到一定長度后，Galera Cluster數(shù)據(jù)同步又開始恢復(fù)。

搞清楚上面的背景原理之后，繼續(xù)說明我的排障過程。

問題描述

1月29日早10點08分接收到Zabbix告警信息，生產(chǎn)環(huán)境某子系統(tǒng)數(shù)據(jù)庫集群節(jié)點1、2分別報活躍線程數(shù)超閥值，而且不斷升高。

從業(yè)務(wù)側(cè)嘗試訪問了一下該子系統(tǒng)，發(fā)現(xiàn)系統(tǒng)頁面一直無法正常查詢數(shù)據(jù)及修改數(shù)據(jù)。登陸服務(wù)器查看CPU、IO、內(nèi)存情況均空閑。說明累計的活躍線程過高，已經(jīng)影響到業(yè)務(wù)的正常訪問了。

問題分析

1、登陸Zabbix告警節(jié)點1、2查看數(shù)據(jù)庫show global status like ‘Threads_running’情況發(fā)現(xiàn)Threads_running線程不斷增高。

節(jié)點1：

| Threads_running| ?100?????|

節(jié)點2：

| Threads_running| ?110?????|

2、繼續(xù)查看節(jié)點1、2數(shù)據(jù)庫的show processlist的情況，發(fā)現(xiàn)存在很多線程停在wsrep in pre-commit stage狀態(tài)(這意味著很多線程已經(jīng)在節(jié)點發(fā)出commit，但將該SQL發(fā)送到其他節(jié)點是處于獨(dú)立異步地進(jìn)行certification test、事務(wù)插入待執(zhí)行隊列的狀態(tài)）。這里就明了為什么會有活躍線程不斷增加了，原來是線程都停留在wsrep in pre-commit stage狀態(tài)。

3、進(jìn)一步查找為什么會有線程一直停留在wsrep in pre-commit stage狀態(tài)，show global status like ‘%wsrep%’，發(fā)現(xiàn)1、2節(jié)點接受隊列并無阻塞，也沒有發(fā)出流控。

但wsrep_evs_delayed報節(jié)點3的4567端口連接延遲。查看節(jié)點1、2錯誤日志發(fā)現(xiàn)報“WSREP: (40a252ac, ‘tcp://節(jié)點2:4567’) reconnecting to 67f667d2 (tcp://節(jié)點3:4567), attempt 0”。查看節(jié)點3的錯誤日志與wsrep_evs_delayed運(yùn)行參數(shù)則報相反信息，連接節(jié)點1和節(jié)點2的4567端口延遲。

這里需要解釋一下4567端口的作用(wsrep_provider_options中的gmcast.listen_addr項：主要作用是集群內(nèi)監(jiān)聽組員狀態(tài)，組員之間的通信(握手，鑒權(quán)，廣播，寫入集的復(fù)制)。

此時，問題原因已經(jīng)明朗了，因為節(jié)點3與節(jié)點1、2的4567端口一直連接有延遲，所以在節(jié)點1、2執(zhí)行的請求無法及時的復(fù)制給節(jié)點3執(zhí)行，導(dǎo)致節(jié)點1、2的活躍線程一直執(zhí)行不完。

節(jié)點1：

+——————————+————-+

?

| Variable_name ???????????????| Value ??????|

+——————————+————-+

| wsrep_local_recv_queue ??????| 0??????????|

| wsrep_local_recv_queue_avg ??| 0.008711 ???|

| wsrep_flow_control_paused ???| 0.000000????|

| wsrep_flow_control_sent ?????| 0??????????|

| wsrep_flow_control_recv ?????| 0??????????|

| wsrep_evs_delayed?????????????| 節(jié)點3:4567 |

+——————————+————-+

節(jié)點2：

+——————————+————-+

?

| Variable_name ? ? ? ? ? ? ? ?| Value ? ? ? |

+——————————+————-+

| wsrep_local_recv_queue ? ? ? | 0 ? ? ? ? ? |

| wsrep_local_recv_queue_avg ? | 0.006193 ? ?|

| wsrep_flow_control_paused ? ?| 0.000000 ? ?|

| wsrep_flow_control_sent ? ? ?| 0 ? ? ? ? ? |

| wsrep_flow_control_recv ? ? ?| 0 ? ? ? ? ?|

| wsrep_evs_delayed ? ? ? ? ? ? |節(jié)點3:4567 |

+——————————+————-+

4、因查詢數(shù)據(jù)庫狀態(tài)除wsrep_evs_delayed報連接延遲，其他并無異?，F(xiàn)象，初步懷疑是網(wǎng)絡(luò)原因造成，排查網(wǎng)絡(luò)后，發(fā)現(xiàn)是因核心交換機(jī)與接入交換機(jī)之間的光模塊損壞導(dǎo)致丟包，所以影響部分?jǐn)?shù)據(jù)庫集群之間的通信，才會出現(xiàn)以上問題。

在網(wǎng)絡(luò)修復(fù)期間，因數(shù)據(jù)庫集群節(jié)點3延遲丟包嚴(yán)重，被數(shù)據(jù)庫集群仲裁后踢出了集群，剩余的節(jié)點1和節(jié)點2在運(yùn)行了大約半小時后也因延遲丟包嚴(yán)重，出現(xiàn)了腦裂現(xiàn)象。

這時緊急將數(shù)據(jù)庫集群3個節(jié)點關(guān)閉，然后在每個節(jié)點執(zhí)行mysqld_safe –wsrep-recover命令找出最新事務(wù)號節(jié)點作為主節(jié)點啟動，并在故障期間保持單節(jié)點運(yùn)行。待網(wǎng)絡(luò)故障消除后，逐一啟動節(jié)點2、3，系統(tǒng)數(shù)據(jù)庫集群恢復(fù)正常。

問題回顧

1、 在PXC環(huán)境中，如果集群各個節(jié)點的通信端口(4567)因為網(wǎng)絡(luò)的原因出現(xiàn)異常（因為集群節(jié)點間通信采用的是同一網(wǎng)段，因此是共性的原因），應(yīng)及時采取相應(yīng)措施防止腦裂情況出現(xiàn)。例如上面故障中，因網(wǎng)絡(luò)原因?qū)е录汗?jié)點數(shù)從3個變?yōu)?個，這時就應(yīng)該及時地關(guān)閉剩余2個節(jié)點中的一個節(jié)點，讓業(yè)務(wù)只跑在單節(jié)點上，還能避免出現(xiàn)腦裂的情況。至少業(yè)務(wù)不會因此終斷。

否則剩余的兩個節(jié)點很快也會被網(wǎng)絡(luò)丟包拖垮，會導(dǎo)致整個集群都停止服務(wù)，影響業(yè)務(wù)。當(dāng)然在非多主的集群中也可以通過設(shè)置“SET?GLOBAL?wsrep_provider_options=’pc.ignore_sb=true’;”來取消集群判斷腦裂的情況(多主環(huán)境中不建議使用)。

2、可以將wsrep_evs_delayed作為一個監(jiān)控項進(jìn)行監(jiān)控，并結(jié)合網(wǎng)絡(luò)監(jiān)控進(jìn)行適當(dāng)?shù)母婢?/p>

轉(zhuǎn)載于:https://www.cnblogs.com/syncnavigator/p/10189311.html

總結(jié)

以上是生活随笔為你收集整理的MySQL集群节点宕机，数据库脑裂！如何排障？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。