MySQL集群節點宕機，數據庫腦裂！如何排障？

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

PROBLEM:Disaster: Galera cluster has node down。我生產環境的Galera集群有一個節點宕機了。

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

PXC：

我們生產上用的是Percona的一個MySQL分支版本，PerconaXtradb Cluster，簡稱PXC，這是一個可以實時同步的MySQL集群，基于廣播write set和事務驗證來實現多節點同時commit，沖突事務回滾的功能。強數據一致性保證。

Galera Replication原理總結：

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

2. 檢測出沖突時，本地事務優先被回滾；

3. 每個節點獨立、異步執行隊列中的WS；

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

Galera復制的架構圖：

Galera flow control：

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

Galera內部實現了flow control，作用就是協調各個節點，保證所有節點執行事務的速度大于隊列增長速度，從而避免丟失事務。

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

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

問題描述

1月29日早10點08分接收到Zabbix告警信息， 生產環境某子系統數據庫集群節點1、2分別報活躍線程數超閥值，而且不斷升高。

從業務側嘗試訪問了一下該子系統，發現系統頁面一直無法正常查詢數據及修改數據。登陸服務器查看CPU、IO、內存情況均空閑。 說明累計的活躍線程過高，已經影響到業務的正常訪問了。

問題分析

1、登陸Zabbix告警節點1、2查看數據庫show global status like ‘Threads_running’情況發現Threads_running線程不斷增高。

節點1：

| Threads_running|  100     |

節點2：

| Threads_running|  110     |

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

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

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

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

此時，問題原因已經明朗了，因為節點3與節點1、2的4567端口一直連接有延遲，所以在節點1、2執行的請求無法及時的復制給節點3執行，導致節點1、2的活躍線程一直執行不完。

節點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             | 節點3:4567 |

+------------------------------+-------------+

節點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             |節點3:4567 |

+------------------------------+-------------+

4、因查詢數據庫狀態除wsrep_evs_delayed報連接延遲，其他并無異常現象，初步懷疑是網絡原因造成，排查網絡后，發現是因核心交換機與接入交換機之間的光模塊損壞導致丟包，所以影響部分數據庫集群之間的通信，才會出現以上問題。

在網絡修復期間，因數據庫集群節點3延遲丟包嚴重，被數據庫集群仲裁后踢出了集群，剩余的節點1和節點2在運行了大約半小時后也因延遲丟包嚴重，出現了腦裂現象。

這時緊急將數據庫集群3個節點關閉，然后在每個節點執行mysqld_safe --wsrep-recover命令找出最新事務號節點作為主節點啟動，并在故障期間保持單節點運行。待網絡故障消除后，逐一啟動節點2、3，系統數據庫集群恢復正常。

問題回顧

1、 在PXC環境中，如果集群各個節點的通信端口(4567)因為網絡的原因出現異常（因為集群節點間通信采用的是同一網段，因此是共性的原因），應及時采取相應措施防止腦裂情況出現。例如上面故障中，因網絡原因導致集群節點數從3個變為2個，這時就應該及時地關閉剩余2個節點中的一個節點，讓業務只跑在單節點上，還能避免出現腦裂的情況。至少業務不會因此終斷。

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

2、可以將wsrep_evs_delayed作為一個監控項進行監控，并結合網絡監控進行適當的告警。

 

來自：http://dbaplus.cn/news-11-1007-1.html