------ 什么是腦裂（split-brain）
在"雙機熱備"高可用（HA）系統中，當聯系兩個節點的"心跳線"斷開時(即兩個節點斷開聯系時)，本來為一個整體、動作協調的HA系統，就分裂成為兩個獨立的節點(即兩個獨立的個體)。由於相互失去了聯系，都以為是對方出了故障，兩個節點上的HA軟件像"裂腦人"一樣，"本能"地爭搶"共享資源"、爭起"應用服務"。就會發生嚴重后果：1）或者共享資源被瓜分、兩邊"服務"都起不來了；2）或者兩邊"服務"都起來了，但同時讀寫"共享存儲"，導致數據損壞（常見如數據庫輪詢着的聯機日志出錯）。
兩個節點相互爭搶共享資源，結果會導致系統混亂，數據損壞。對於無狀態服務的HA，無所謂腦裂不腦裂，但對有狀態服務(比如MySQL)的HA，必須要嚴格防止腦裂
[但有些生產環境下的系統按照無狀態服務HA的那一套去配置有狀態服務，結果就可想而知]。
------ 集群腦裂產生的原因
一般來說，裂腦的發生，有以下幾種原因：
1. 高可用服務器各節點之間心跳線鏈路發生故障，導致無法正常通信。
2. 因心跳線壞了（包括斷了，老化）。
3. 因網卡及相關驅動壞了，ip配置及沖突問題（網卡直連）。
4. 因心跳線間連接的設備故障（網卡及交換機）。
5. 因仲裁的機器出問題（采用仲裁的方案）。
6. 高可用服務器上開啟了iptables防火牆阻擋了心跳消息傳輸。
7. 高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗。
8. 其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟件Bug等。
提示： Keepalived配置里同一VRRP實例如果virtual_router_id兩端參數配置不一致也會導致裂腦問題發生。
------ 如何預防HA集群腦裂 [目前達成共識的有下面四種對策]
第一種：添加冗余的心跳線 [即冗余通信的方法]
同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路 (即心跳線也HA)，這樣一條線路壞了，另一個還是好的，依然能傳送心跳消息，盡量減少"腦裂"現象的發生幾率。
第二種方法：設置仲裁機制
當兩個節點出現分歧時，由第3方的仲裁者決定聽誰的。這個仲裁者，可能是一個鎖服務，一個共享盤或者其它什么東西。例如設置參考IP（如網關IP），當心跳線完全斷開時，2個節點都各自ping一下參考IP，不通則表明斷點就出在本端。不僅"心跳"、還兼對外"服務"的本端網絡鏈路斷了，即使啟動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓能夠ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方干脆就自我重啟，以徹底釋放有可能還占用着的那些共享資源。
第三種方法：fence機制 [即共享資源的方法] [前提是必須要有可靠的fence設備]
當不能確定某個節點的狀態時 ，通過fence設備強行關閉該心跳節點，確保共享資源被完全釋放！相當於Backup備節點接收不到心跳信息，通過單獨的線路發送關機命令關閉主節點的電源。
理想情況下，以上第二、三兩者一個都不能少。但是如果節點沒有使用共享資源，比如基於主從復制的數據庫HA，也可以安全的省掉fence設備，只保留仲裁，而且很多時候線上環境里也也可能沒有可用的fence設備，比如在雲主機里。
那么可不可以省掉仲裁機制，只留fence設備呢？這是不可以的。因為，當兩個節點互相失去聯絡時會同時fencing對方。如果fencing的方式是reboot，那么兩台機器就會不停的重啟。如果fencing的方式是power off，那么結局有可能是2個節點同歸於盡，也有可能活下來一個。但是如果兩個節點互相失去聯絡的原因是其中一個節點的網卡故障，而活下來的正好又是那個有故障的節點，那么結局一樣是悲劇。所以說: 單純的雙節點，無論如何也防止不了腦裂。
第四種：啟用磁盤鎖
正在服務一方鎖住共享磁盤，"裂腦"發生時，讓對方完全"搶不走"共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的一方不主動"解鎖"，另一方就永遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰，就不可能執行解鎖命令。后備節點也就接管不了共享資源和應用服務。於是有人在HA中設計了"智能"鎖。即：正在服務的一方只在發現心跳線全部斷開（察覺不到對端）時才啟用磁盤鎖。平時就不上鎖了。
檢查腦裂腳本
可以ping通主 備份節點上有vip 說明是腦裂了
#!/bin/sh
while true
do
ping -c 2 -w 3 主ip &>/dev/null
if [ $? -eq 0 -a `ip add|grep vip |wc -l` -eq 1 ]
then
echo "ha is split brain.warning."mail -s 異常告警-keepalived xxxxxx@qq.com
else
echo "ha is ok"
fi
sleep 5
done