腦裂現象
同時如果由於網路或其他原因導致集群中選舉出多個master節點，使得資料更新時出現不一致，這種現象稱之為腦裂，即集群中不同的節點對於master的選擇出現了分歧，出現了多個master競爭。
「腦裂」問題可能有以下幾個原因造成：
網路問題：集群間的網路延遲導致一些節點訪問不到master，認為master掛掉了從而選舉出新的master，並對master上的分片和副本標紅，分配新的主分片
節點負載：主節點的角色既為master又為data，訪問量較大時可能會導致es停止響應（假死狀態）造成大面積延遲，此時其他節點得不到主節點的響應認為主節點掛掉了，會重新選取主節點。
記憶體**：主節點的角色既為master又為data，當data節點上的es程序占用的記憶體較大，引發jvm的大規模記憶體**，造成es程序失去響應。
為了避免腦裂現象的發生，我們可以從原因著手通過以下幾個方面來做出優化措施：
適當調大響應時間，減少誤判通過引數 discovery.zen.ping_timeout設定節點狀態的響應時間，預設為3s，可以適當調大，如果master在該響應時間的範圍內沒有做出響應應答，判斷該節點已經掛掉了。調大引數（如6s，discovery.zen.ping_timeout:6），可適當減少誤判。
選舉觸發我們需要在候選集群中的節點的配置檔案中設定引數 discovery.zen.munimum_master_nodes的值，這個引數表示在選舉主節點時需要參與選舉的候選主節點的節點數，預設值是1，官方建議取值 (master_eligibel_nodes/2)+1，其中 master_eligibel_nodes為候選主節點的個數。這樣做既能防止腦裂現象的發生，也能最大限度地提公升集群的高可用性，因為只要不少於discovery.zen.munimum_master_nodes個候選節點存活，選舉工作就能正常進行。當小於這個值的時候，無法觸發選舉行為，集群無法使用，不會造成分片混亂的情況。
角色分離即是上面我們提到的候選主節點和資料節點進行角色分離，這樣可以減輕主節點的負擔，防止主節點的假死狀態發生，減少對主節點「已死」的誤判。
來自<
>
es的基本概念和基本操作介紹完了之後我們可能還有很多疑惑，它們內部是如何執行的？主分片和副本分片是如何同步的？建立索引的流程是什麼樣的？es如何將索引資料分配到不同的分片上的？以及這些索引資料是如何儲存的？為什麼說es是近實時搜尋引擎而文件的 crud (建立-讀取-更新-刪除) 操作是實時的？以及elasticsearch 是怎樣保證更新被持久化在斷電時也不丟失資料？還有為什麼刪除文件不會立刻釋放空間？帶著這些疑問我們進入接下來的內容。
來自<
>
ElasticSearch常見問題
針對index數量 1 根據業務增量需求，採取基於日期模板建立索引，通過roll over api滾動索引 2 使用別名進行索引管理 3 採取curator進行索引的生命週期管理 針對儲存 4 每天凌晨定時對索引做force merge操作，以釋放空間 5 採取冷熱分離機制，熱資料儲存到ssd，提高...
elasticsearch常見問題總結
原因 主要是linux的版本過低 解決方案 重新安裝新版本的linux系統 原因 無法建立本地檔案問題,使用者最大可建立檔案數太小 解決方案 切換到root使用者，編輯limits.conf配置檔案，新增類似如下內容 vi etc security limits.conf 新增如下內容 soft n...
elasticsearch常見問題總結
原因 主要是linux的版本過低 解決方案 重新安裝新版本的linux系統 原因 無法建立本地檔案問題,使用者最大可建立檔案數太小 解決方案 切換到root使用者，編輯limits.conf配置檔案，新增類似如下內容 vi etc security limits.conf 新增如下內容 soft n...