Elasticsearch集群所謂腦裂的問題是怎樣的

這篇文章將為大家詳細講解有關Elasticsearch集群所謂腦裂的問題是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

所謂腦裂問題（類似于精神分裂），就是同一個集群中的不同節點，對于集群的狀態有了不一樣的理解。

今天，Elasticsearch集群出現了查詢極端緩慢的情況，通過以下命令查看集群狀態：

curl -XGET 'es-1:9200/_cluster/health'

發現，集群的總體狀態是red，本來9個節點的集群，在結果中只顯示了4個；但是，將請求發向不同的節點之后，我卻發現即使是總體狀態是red的，但是可用的節點數量卻不一致。

正 常情況下，集群中的所有的節點，應該對集群中master的選擇是一致的，這樣獲得的狀態信息也應該是一致的，不一致的狀態信息，說明不同的節點對 master節點的選擇出現了異?！簿褪撬^的腦裂問題。這樣的腦裂狀態直接讓節點失去了集群的正確狀態，導致集群不能正常工作。

可能導致的原因：

1. 網絡：由于是內網通信，網絡通信問題造成某些節點認為master死掉，而另選master的可能性較??；進而檢查Ganglia集群監控，也沒有發現異常的內網流量，故此原因可以排除。
2. 節點負載：由于master節點與data節點都是混合在一起的，所以當工作節點的負載較大（確實也較大）時，導致對應的ES實例停止響應，而這臺服務器 如果正充當著master節點的身份，那么一部分節點就會認為這個master節點失效了，故重新選舉新的節點，這時就出現了腦裂；同時由于data節點 上ES進程占用的內存較大，較大規模的內存回收操作也能造成ES進程失去響應。所以，這個原因的可能性應該是最大的。
 

應對問題的辦法：
 

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

1. node.master: true  

2. node.data: false

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

1. discovery.zen.ping.multicast.enabled: false  

2. 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臺服務器了，這點需要注意）。

以上的解決方法只能是減緩這種現象的發生，并不能從根本上杜絕。

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