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臺服務器了，這點須要注意）。 以上的解決方法只能是減緩這種現象的發生，並不能從根本上杜絕。