1、es腦裂問題
由於某些節點的失效，部分節點的網路連線會斷開，並形成乙個與原集群一樣名字的集群，這種情況成為集群腦裂（split-brain）現象。這個問題非常危險，因為兩個新形成的集群會同時索引和修改集群的資料。
正常情況下，集群中的所有的節點，應該對集群中master的選擇是一致的，這樣獲得的狀態資訊也應該是一致的，不一致的狀態資訊，說明不同的節點對master節點的選擇出現了異常——也就是所謂的腦裂問題。這樣的腦裂狀態直接讓節點失去了集群的正確狀態，導致集群不能正常工作。
es集群腦裂導致的原因：
1. 網路： 由於是內網通訊， 網路通訊問題造成某些節點認為 master 死掉， 而另選 master的可能性較小； 進而檢查 ganglia 集群監控， 也沒有發現異常的內網流量， 故此原因可以排除。
內網一般不會出現es集群的腦裂問題，可以監控內網流量狀態。外網的網路出現問題的可能性大些。
2. 節點負載： 由於 master 節點與 data 節點都是混合在一起的， 所以當工作節點的負載較大（ 確實也較大） 時， 導致對應的 es 例項停止響應， 而這台伺服器如果正充當著 master節點的身份， 那麼一部分節點就會認為這個 master 節點失效了， 故重新選舉新的節點， 這時就出現了腦裂； 同時由於 data 節點上 es 程序占用的記憶體較大， 較大規模的記憶體**操作也能造成 es 程序失去響應。 所以， 這個原因的可能性應該是最大的。
3、**記憶體
由於data節點上es程序占用的記憶體較大，較大規模的記憶體**操作也能造成es程序失去響應。
解決方案：
之前的部落格有描述，master節點和data節點分離。
2、 集群中出現大量shard unassiged問題，如何修復？
當集群重啟過程中如果出現unassiged的分片，如何快速修復,下面兩個鏈結都是很好的解決方案
}'3、節點負載過高，gc頻繁？
首先判斷是否cpu過高或部分io等待導致，並排除其他元件的影響，gc的問題可以公升級g1**器（jdk1.8 40版本以上），同時需要考慮降低副本數到0或1、部分增加超時時間來降低影響。一般來說，es配置可優化的點很少，更多的是使用的問題。當使用x-pack外掛程式時要注意，每台機器都需要裝該外掛程式。
4、 es如何安全重啟—–滾動重啟
正常情況下，elasticsearch 希望你的資料被完全的複製和均衡的分布。如果你手動關閉了乙個節點，集群會立刻發現節點的丟失並開始再平衡。如果節點的維護是短期工作的話，這一點就很煩人了，因為大型分片的再平衡需要花費相當的時間（想想嘗試複製 1tb 的資料——即便在高速網路上也是不一般的事情了）。
我們需要的是，告訴 elasticsearch 推遲再平衡，因為對外部因子影響下的集群狀態，我們自己更了解。操作流程如下：
put /_cluster/settings
}
put /_cluster/settings
}
- 7.重複第 2 到 6 步操作剩餘節點。
- 8.到這步你可以安全的恢復索引了（如果你之前停止了的話），不過等待集群完全均衡後再恢復索引，也會有助於提高處理速度.
主要幾個需要注意的點：
1.不要通過kill -9來停止服務
2.滾動重啟時需要等待該節點加入集群，加入集群後再開啟自動分配分片，直到分片分配結束.
3.重啟各台機器前需要先關閉自動分配分片
誰在使用Elasticsearch
github github使用elasticsearch搜尋20tb的資料，包括13億的檔案和1300億行的 這個不用介紹了吧，碼農們都懂的，github在2013年1月公升級了他們的 搜尋，由solr轉為elasticsearch，目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...
ElasticSearch使用入門
es的安裝 啟動 cd.elasticsearch 2 4 3 bin elasticsearch bin elasticsearch d 後台執行 es安裝驗證 注意 預設啟動的時候es繫結的網路ip是本機127.0.0.1，只能通過這個ip訪問 兩種修改方式 1 修改config elastic...
ElasticSearch使用學習
elasticsearch是乙個基於lucene的搜尋服務，它通過倒排索引的方法提供了全文搜尋的能力。1 插入資料 elasticsearch中存放資料的為文件，有索引及型別名，如下插入兩文件 2 檢索文件 1 檢索id為1的文件 curl x get elasticsearch.in.netwa....