Elasticsearch集群的腦裂問題該怎么解決

這篇文章給大家介紹Elasticsearch集群的腦裂問題該怎么解決，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

#Elasticsearch集群的腦裂問題 正常情況下，集群中的所有的節點，應該對集群中master的選擇是一致的，這樣獲得的狀態信息也應該是一致的，不一致的狀態信息，說明不同的節點對master節點的選擇出現了異常——也就是所謂的腦裂問題。這樣的腦裂狀態直接讓節點失去了集群的正確狀態，導致集群不能正常工作。

可能導致的原因：

1. 網絡：由于是內網通信，網絡通信問題造成某些節點認為master死掉，而另選master的可能性較小；進而檢查Ganglia集群監控，也沒有發現異常的內網流量，故此原因可以排除。

2. 節點負載：由于master節點與data節點都是混合在一起的，所以當工作節點的負載較大（確實也較大）時，導致對應的ES實例停止響應，而這臺服務器如果正充當著master節點的身份，那么一部分節點就會認為這個master節點失效了，故重新選舉新的節點，這時就出現了腦裂；同時由于data節點上ES進程占用的內存較大，較大規模的內存回收操作也能造成ES進程失去響應。所以，這個原因的可能性應該是最大的。

應對問題的辦法：

1. 對應于上面的分析，推測出原因應該是由于節點負載導致了master進程停止響應，繼而導致了部分節點對于master的選擇出現了分歧。為此，一個直觀的解決方案便是將master節點與data節點分離。為此，我們添加了三臺服務器進入ES集群，不過它們的角色只是master節點，不擔任存儲和搜索的角色，故它們是相對輕量級的進程。可以通過以下配置來限制其角色：

node.master: true  
node.data: false

當然，其它的節點就不能再擔任master了，把上面的配置反過來即可。這樣就做到了將master節點與data節點分離。當然，為了使新加入的節點快速確定master位置，可以將data節點的默認的master發現方式有multicast修改為unicast：

discovery.zen.ping.multicast.enabled: false  
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]

2. discovery.zen.ping_timeout（默認值是3秒）：默認情況下，一個節點會認為，如果master節點在3秒之內沒有應答，那么這個節點就是死掉了，而增加這個值，會增加節點等待響應的時間，從一定程度上會減少誤判。 discovery.zen.minimum_master_nodes（默認是1）：這個參數控制的是，一個節點需要看到的具有master節點資格的最小數量，然后才能在集群中做操作。官方的推薦值是(N/2)+1，其中N是具有master資格的節點的數量（我們的情況是3，因此這個參數設置為2，但對于只有2個節點的情況，設置為2就有些問題了，一個節點DOWN掉后，你肯定連不上2臺服務器了，這點需要注意）。

discovery.zen.ping.multicast.enabled: false
discovery.zen.ping_timeout: 120s
discovery.zen.minimum_master_nodes: 2 
client.transport.ping_timeout: 60s
discovery.zen.ping.unicast.hosts: ["10.0.31.2", "10.0.33.2"]

真的高枕無憂了？ 其實問題依然存在，ES的issue空間也在討論一個特例情況《#2488》：即使 minimum_master_nodes 設置了一個正確的值，腦裂也有可能發生。

如何識別這個問題？ 在您的集群里面盡快識別這個問題非常重要。一個比較容易的方法是定時獲取每一個節點/_nodes響應，它返回了集群中所有節點的狀態報告，如果兩個節點返回的集群狀態不一樣，就是一個腦裂情況發生的警示信號。

新增解決方案 對于一個具有全功能的ES節點，必須要有一個活動的Master節點。ES1.4.0.Beta1后，新增了一項沒有Master時阻塞集群操作設置：discovery.zen.no_master_block。

當集群中沒有活動的Master節點后，該設置指定了哪些操作（read、write）需要被拒絕（即阻塞執行）。有兩個設置值：all和write，默認為wirte。

這項配置不會對基本api（例如集群狀態、節點信息和狀態API）產生影響，這些節點在任何節點上執行都不會被阻塞。

ps: es的優點：因為它的開箱即用、天生集群、自動容錯、擴展性強等優點，還是選擇它來做全文檢索

關于Elasticsearch集群的腦裂問題該怎么解決就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。