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"]

https://github.com/elastic/elasticsearch/issues/2488

真的高枕無憂了？ 其實問題依然存在，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的優勢：由於它的開箱即用、天生集羣、自動容錯、擴展性強等優勢，仍是選擇它來作全文檢索