由於某些節點的失效，部分節點的網路連線會斷開，並形成乙個與原集群一樣名字的集群，這種情況稱為集群腦裂（split-brain）現象。這個問題非常危險，因為兩個新形成的集群會同時索引和修改集群的資料。
避免腦裂現象，用到的乙個引數是：discovery.zen.minimum_master_nodes。這個引數決定了要選舉乙個master需要多少個節點（最少候選節點數）。預設值是1。根據一般經驗這個一般設定成 n/2 + 1，n是集群中節點的數量，例如乙個有3個節點的集群，minimum_master_nodes 應該被設定成 3/2 + 1 = 2（向下取整）。
用到的另外乙個引數是：discovery.zen.ping.timeout，等待ping響應的超時時間，預設值是3秒。如果網路緩慢或擁塞，建議略微調大這個值。這個引數不僅僅適應更高的網路延遲，也適用於在乙個由於超負荷而響應緩慢的節點的情況。
如果您剛開始使用elasticsearch，建議搭建擁有3個節點的集群，這種方式可以把discovery.zen.minimum_master_nodes設定成2，這樣就限制了發生腦裂現象的可能，且保持著高度的可用性：如果你設定了副本，在丟失乙個節點的情況下，集群仍可執行。
其實問題依然存在，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）產生影響，這些節點在任何節點上執行都不會被阻塞。
腦裂問題依然是乙個比較難以解決的問題，最終解決方案也是妥協的結果。這個問題也是分布式系統都會面臨的問題。一下子想到了前幾天看到的cap理論，難道只有cp或者ap？
總體感覺es還很年輕，但因為它的開箱即用、天生集群、自動容錯、擴充套件性強等優點，還是選擇它來做全文檢索。
CronJob刪除ElasticSearch日誌
目前在k8s平台內，通過pod掛載hostpath將程式形成的日誌檔案傳輸儲存到宿主機指定目錄上，然後fluentd根據指定目錄去蒐集日誌檔案 json格式 然後通過呼叫elasticsearch 以下簡稱es 的api將日誌儲存到es中，那麼問題來了，日誌檔案大了怎麼清理？1.每個工作節點上的日誌...
windows下的elasticSearch安裝
es官網 進入bin目錄，雙擊elasticsearch.bat 訪問http localhost 9200可訪問 新增ik分詞器 解壓ik分詞器包，放到es安裝目錄的plugins中的analysis ik 資料夾中 新建analysis ik 資料夾 再次啟動elasticsearch.bat，...
同步LDAP資料到ElasticSearch
純python編寫 支援全量同步ldap資料，包括person 使用者 computer 計算機 group 組 多程序 協程實現快速同步 簡單配置即可使用 clone專案到本地 git clone 安裝依賴 cd ldap2es pip install r requirements.txt 修改配...