MySQL中腦裂指的是什么

本文小編為大家詳細(xì)介紹“MySQL中腦裂指的是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“MySQL中腦裂指的是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來(lái)學(xué)習(xí)新知識(shí)吧。

在MySQL中，腦裂是指在一個(gè)高可用（HA）系統(tǒng)中，當(dāng)聯(lián)系著的兩個(gè)節(jié)點(diǎn)斷開聯(lián)系時(shí)，本來(lái)為一個(gè)整體的系統(tǒng)，分裂為兩個(gè)獨(dú)立節(jié)點(diǎn)，這時(shí)兩個(gè)節(jié)點(diǎn)開始爭(zhēng)搶共享資源，結(jié)果會(huì)導(dǎo)致系統(tǒng)混亂，數(shù)據(jù)損壞。 對(duì)于無(wú)狀態(tài)服務(wù)的HA系統(tǒng)，無(wú)所謂腦裂不腦裂；但對(duì)有狀態(tài)服務(wù)（比如MySQL）的HA，必須要嚴(yán)格防止腦裂。

本教程操作環(huán)境：windows7系統(tǒng)、mysql8版本、Dell G3電腦。

腦裂（split-brain）

指在一個(gè)高可用（HA）系統(tǒng)中，當(dāng)聯(lián)系著的兩個(gè)節(jié)點(diǎn)斷開聯(lián)系時(shí)，本來(lái)為一個(gè)整體的系統(tǒng)，分裂為兩個(gè)獨(dú)立節(jié)點(diǎn)，這時(shí)兩個(gè)節(jié)點(diǎn)開始爭(zhēng)搶共享資源，結(jié)果會(huì)導(dǎo)致系統(tǒng)混亂，數(shù)據(jù)損壞。

在一個(gè)高可用性集群環(huán)境中有一個(gè)活動(dòng)節(jié)點(diǎn)和一個(gè)或多個(gè)備用節(jié)點(diǎn)，當(dāng)活動(dòng)節(jié)點(diǎn)發(fā)生故障或停止響應(yīng)時(shí)，它們將接管服務(wù)。

在考慮節(jié)點(diǎn)之間的網(wǎng)絡(luò)層之前，這聽起來(lái)像是一個(gè)合理的假設(shè)。 如果節(jié)點(diǎn)之間的網(wǎng)絡(luò)路徑出現(xiàn)故障怎么辦？

任何一個(gè)節(jié)點(diǎn)現(xiàn)在都不能與另一個(gè)節(jié)點(diǎn)通信，在這種情況下，備用服務(wù)器可能會(huì)在它認(rèn)為活動(dòng)節(jié)點(diǎn)發(fā)生故障的基礎(chǔ)上將自己提升為活動(dòng)服務(wù)器。 這導(dǎo)致兩個(gè)節(jié)點(diǎn)都變得“活躍”，因?yàn)槊總€(gè)節(jié)點(diǎn)都會(huì)認(rèn)為另一個(gè)節(jié)點(diǎn)已經(jīng)死了。 結(jié)果，數(shù)據(jù)完整性和一致性受到損害，因?yàn)閮蓚€(gè)節(jié)點(diǎn)上的數(shù)據(jù)都會(huì)發(fā)生變化。 這被稱為“裂腦” .

對(duì)于無(wú)狀態(tài)服務(wù)的HA，無(wú)所謂腦裂不腦裂；但對(duì)有狀態(tài)服務(wù)(比如MySQL)的HA，必須要嚴(yán)格防止腦裂。（但有些生產(chǎn)環(huán)境下的系統(tǒng)按照無(wú)狀態(tài)服務(wù)HA的那一套去配置有狀態(tài)服務(wù)，結(jié)果可想而知...）

如何防止HA集群腦裂

一般采用2個(gè)方法 1）仲裁 當(dāng)兩個(gè)節(jié)點(diǎn)出現(xiàn)分歧時(shí)，由第3方的仲裁者決定聽誰(shuí)的。這個(gè)仲裁者，可能是一個(gè)鎖服務(wù)，一個(gè)共享盤或者其它什么東西。

2）fencing 當(dāng)不能確定某個(gè)節(jié)點(diǎn)的狀態(tài)時(shí)，通過fencing把對(duì)方干掉，確保共享資源被完全釋放，前提是必須要有可靠的fence設(shè)備。

理想的情況下，以上兩者一個(gè)都不能少。 但是，如果節(jié)點(diǎn)沒有使用共享資源，比如基于主從復(fù)制的數(shù)據(jù)庫(kù)HA，也可以安全的省掉fence設(shè)備，只保留仲裁。而且很多時(shí)候我們的環(huán)境里也沒有可用的fence設(shè)備，比如在云主機(jī)里。

那么可不可以省掉仲裁，只留fence設(shè)備呢？ 不可以。因?yàn)椋?dāng)兩個(gè)節(jié)點(diǎn)互相失去聯(lián)絡(luò)時(shí)會(huì)同時(shí)fencing對(duì)方。如果fencing的方式是reboot，那么兩臺(tái)機(jī)器就會(huì)不停的重啟。如果fencing的方式是power off，那么結(jié)局有可能是2個(gè)節(jié)點(diǎn)同歸于盡，也有可能活下來(lái)一個(gè)。但是如果兩個(gè)節(jié)點(diǎn)互相失去聯(lián)絡(luò)的原因是其中一個(gè)節(jié)點(diǎn)的網(wǎng)卡故障，而活下來(lái)的正好又是那個(gè)有故障的節(jié)點(diǎn)，那么結(jié)局一樣是悲劇。 所以，單純的雙節(jié)點(diǎn)，無(wú)論如何也防止不了腦裂。

如何實(shí)現(xiàn)上面的策略

可以自己完全從頭開始實(shí)現(xiàn)一套符合上述邏輯的腳本。推薦使用基于成熟的集群軟件去搭建，比如Pacemaker+Corosync+合適的資源Agent。Keepalived不太適合用于有狀態(tài)服務(wù)的HA，即使把仲裁和fence那些東西都加到方案里，總覺得別扭。

使用Pacemaker+Corosync的方案也有一些注意事項(xiàng) 1）了解資源Agent的功能和原理 了解資源Agent的功能和原理，才能知道它適用的場(chǎng)景。比如pgsql的資源Agent是比較完善的，支持同步和異步流復(fù)制，并且可以在兩者之前自動(dòng)切換，并且可以保證同步復(fù)制下數(shù)據(jù)不會(huì)丟失。但目前MySQL的資源Agent就很弱了，沒有使用GTID又沒有日志補(bǔ)償，很容易丟數(shù)據(jù)，還是不要用的好，繼續(xù)用MHA吧（但是，部署MHA時(shí)務(wù)必要防范腦裂）。

2）確保法定票數(shù)(quorum) quorum可以認(rèn)為是Pacemkaer自帶的仲裁機(jī)制，集群的所有節(jié)點(diǎn)中的多數(shù)選出一個(gè)協(xié)調(diào)者，集群的所有指令都由這個(gè)協(xié)調(diào)者發(fā)出，可以完美的杜絕腦裂問題。為了使這套機(jī)制有效運(yùn)轉(zhuǎn)，集群中至少有3個(gè)節(jié)點(diǎn)，并且把no-quorum-policy設(shè)置成stop，這也是默認(rèn)值。（很多教程為了方便演示，都把no-quorum-policy設(shè)置成ignore，生產(chǎn)環(huán)境如果也這么搞，又沒有其它仲裁機(jī)制，是很危險(xiǎn)的?。?/p>

但是，如果只有2個(gè)節(jié)點(diǎn)該怎么辦？

• 一是拉一個(gè)機(jī)子借用一下湊足3個(gè)節(jié)點(diǎn)，再設(shè)置location限制，不讓資源分配到那個(gè)節(jié)點(diǎn)上。

• 二是把多個(gè)不滿足quorum小集群拉到一起，組成一個(gè)大的集群，同樣適用location限制控制資源的分配的位置。

但是如果你有很多雙節(jié)點(diǎn)集群，找不到那么多用于湊數(shù)的節(jié)點(diǎn)，又不想把這些雙節(jié)點(diǎn)集群拉到一起湊成一個(gè)大的集群（比如覺得不方便管理）。那么可以考慮第三種方法。 第三種方法是配置一個(gè)搶占資源，以及服務(wù)和這個(gè)搶占資源的colocation約束，誰(shuí)搶到搶占資源誰(shuí)提供服務(wù)。這個(gè)搶占資源可以是某個(gè)鎖服務(wù)，比如基于zookeeper包裝一個(gè)，或者干脆自己從頭做一個(gè)，就像下面這個(gè)例子。這個(gè)例子是基于http協(xié)議的短連接，更細(xì)致的做法是使用長(zhǎng)連接心跳檢測(cè)，這樣服務(wù)端可以及時(shí)檢出連接斷開而釋放鎖）但是，一定要同時(shí)確保這個(gè)搶占資源的高可用，可以把提供搶占資源的服務(wù)做成lingyig高可用的，也可以簡(jiǎn)單點(diǎn)，部署3個(gè)服務(wù)，雙節(jié)點(diǎn)上個(gè)部署一個(gè)，第三個(gè)部署在另外一個(gè)專門的仲裁節(jié)點(diǎn)上，至少獲取3個(gè)鎖中的2個(gè)才視為取得了鎖。這個(gè)仲裁節(jié)點(diǎn)可以為很多集群提供仲裁服務(wù)（因?yàn)橐粋€(gè)機(jī)器只能部署一個(gè)Pacemaker實(shí)例，否則可以用部署了N個(gè)Pacemaker實(shí)例的仲裁節(jié)點(diǎn)做同樣的事情。但是，如非迫不得已，盡量還是采用前面的方法，即滿足Pacemaker法定票數(shù)，這種方法更簡(jiǎn)單，可靠。

--------------------------------------------------------------keepalived的腦裂問題----------------------------------------------

1）解決keepalived腦裂問題

檢測(cè)思路：正常情況下keepalived的VIP地址是在主節(jié)點(diǎn)上的，如果在從節(jié)點(diǎn)發(fā)現(xiàn)了VIP，就設(shè)置報(bào)警信息。腳本（在從節(jié)點(diǎn)上）如下：

[root@slave-ha ~]# vim split-brainc_check.sh
#!/bin/bash
# 檢查腦裂的腳本，在備節(jié)點(diǎn)上進(jìn)行部署
LB01_VIP=192.168.1.229
LB01_IP=192.168.1.129
LB02_IP=192.168.1.130
while true
do
  ping -c 2 -W 3 $LB01_VIP &>/dev/null
    if [ $? -eq 0 -a `ip add|grep "$LB01_VIP"|wc -l` -eq 1 ];then
        echo "ha is brain."
    else
        echo "ha is ok"
    fi
    sleep 5
done

執(zhí)行結(jié)果如下：
[root@slave-ha ~]# bash check_split_brain.sh 
ha is ok
ha is ok
ha is ok
ha is ok
當(dāng)發(fā)現(xiàn)異常時(shí)候的執(zhí)行結(jié)果：
[root@slave-ha ~]# bash check_split_brain.sh 
ha is ok
ha is ok
ha is ok
ha is ok
ha is brain.
ha is brain.

2）曾經(jīng)碰到的一個(gè)keepalived腦裂的問題（如果啟用了iptables，不設(shè)置"系統(tǒng)接收VRRP協(xié)議"的規(guī)則，就會(huì)出現(xiàn)腦裂）

曾經(jīng)在做keepalived+Nginx主備架構(gòu)的環(huán)境時(shí)，當(dāng)重啟了備用機(jī)器后，發(fā)現(xiàn)兩臺(tái)機(jī)器都拿到了VIP。這也就是意味著出現(xiàn)了keepalived的腦裂現(xiàn)象，檢查了兩臺(tái)主機(jī)的網(wǎng)絡(luò)連通狀態(tài)，發(fā)現(xiàn)網(wǎng)絡(luò)是好的。然后在備機(jī)上抓包：

[root@localhost ~]#  tcpdump -i eth0|grep VRRP  
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode  
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes  
22:10:17.146322 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:17.146577 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:17.146972 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:18.147136 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:18.147576 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:25.151399 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:25.151942 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:26.151703 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:26.152623 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:27.152456 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:27.153261 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:28.152955 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:28.153461 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:29.153766 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:29.155652 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:30.154275 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:30.154587 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:31.155042 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:31.155428 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:32.155539 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:32.155986 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:33.156357 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:33.156979 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  
22:10:34.156801 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20  
22:10:34.156989 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20  

備機(jī)能接收到master發(fā)過來(lái)的VRRP廣播，那為什么還會(huì)有腦裂現(xiàn)象？
接著發(fā)現(xiàn)重啟后iptables開啟著，檢查了防火墻配置。發(fā)現(xiàn)系統(tǒng)不接收VRRP協(xié)議。
于是修改iptables，添加允許系統(tǒng)接收VRRP協(xié)議的配置：
-A INPUT -i lo -j ACCEPT   
-----------------------------------------------------------------------------------------
我自己添加了下面的iptables規(guī)則：
-A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT       #允許組播地址通信
-A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT             #允許VRRP（虛擬路由器冗余協(xié)）通信
-----------------------------------------------------------------------------------------

最后重啟iptables，發(fā)現(xiàn)備機(jī)上的VIP沒了。
雖然問題解決了，但備機(jī)明明能抓到master發(fā)來(lái)的VRRP廣播包，卻無(wú)法改變自身狀態(tài)。只能說明網(wǎng)卡接收到數(shù)據(jù)包是在iptables處理數(shù)據(jù)包之前發(fā)生的事情。

3）預(yù)防keepalived腦裂問題    

1）可以采用第三方仲裁的方法。由于keepalived體系中主備兩臺(tái)機(jī)器所處的狀態(tài)與對(duì)方有關(guān)。如果主備機(jī)器之間的通信出了網(wǎng)題，就會(huì)發(fā)生腦裂，此時(shí)keepalived體系中會(huì)出現(xiàn)雙主的情況，產(chǎn)生資源競(jìng)爭(zhēng)。     2）一般可以引入仲裁來(lái)解決這個(gè)問題，即每個(gè)節(jié)點(diǎn)必須判斷自身的狀態(tài)。最簡(jiǎn)單的一種操作方法是，在主備的keepalived的配置文件中增加check配置，服務(wù)器周期性地ping一下網(wǎng)關(guān)，如果ping不通則認(rèn)為自身有問題 。    3）最容易的是借助keepalived提供的vrrp_script及track_script實(shí)現(xiàn)。如下所示：

# vim /etc/keepalived/keepalived.conf
   ......
   vrrp_script check_local {
    script "/root/check_gateway.sh" 
    interval 5
    }
   ......

   track_script {     
   check_local                   
   }

   腳本內(nèi)容：
   # cat /root/check_gateway.sh
   #!/bin/sh
   VIP=$1
   GATEWAY=192.168.1.1 
   /sbin/arping -I em1 -c 5 -s $VIP $GATEWAY &>/dev/null

   check_gateway.sh 就是我們的仲裁邏輯，發(fā)現(xiàn)ping不通網(wǎng)關(guān)，則關(guān)閉keepalived service keepalived stop。

4）推薦自己寫腳本

寫一個(gè)while循環(huán)，每輪ping網(wǎng)關(guān)，累計(jì)連續(xù)失敗的次數(shù)，當(dāng)連續(xù)失敗達(dá)到一定次數(shù)則運(yùn)行service keepalived stop關(guān)閉keepalived服務(wù)。如果發(fā)現(xiàn)又能夠ping通網(wǎng)關(guān)，再重啟keepalived服務(wù)。最后在腳本開頭再加上腳本是否已經(jīng)運(yùn)行的判斷邏輯，將該腳本加到crontab里面。

讀到這里，這篇“MySQL中腦裂指的是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。