(轉)Elasticsearch叢集的腦裂問題

標籤：

轉自 http://blog.csdn.net/cnweike/article/details/39083089

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

 

今天，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節點，不擔任儲存和搜尋的角色，故它們是相對輕量級的進程。可以通過以下配置來限制其角色：

 

[plain] view plain copy 

1. node.master: true  
2. node.data: false  

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

 

 

 

[plain] view plain copy 

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叢集的腦裂問題