1、elasticsearch重要配置項解釋：
cluster.name: elasticsearch-wylnode.name: "node1"path.data: "/opt/elasticsearch/data"path.logs: "/opt/elasticsearch/logs"node.master: true
.enabled 這個設定把組播的自動發現給關閉了，為了防止其他機器上的節點自動連入。
discovery.zen
.fd.ping_timeout和discovery.zen
.ping
.timeout是設定了節點與節點之間的連線ping時長
discovery.zen
.minimum_master_nodes 這個設定為了避免腦裂。比如5個節點的集群，如果設定為3，那麼當一台節點脫離後，按照上面的情況重新選擇master要超過3個投票才可以成為master節點，並不會出現腦裂現象。
discovery.zen
.ping
.unicast
.hosts 這個設定了自動發現的節點。
action.auto_create_index: false 這個設定了自動發現的節點。
對所有可以成為master的節點根據nodeid排序，每次選舉每個節點都把自己所知道節點排一次序，然後選出第乙個（第0位）節點，暫且認為它是master節點。
如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉。
注意：這裡理解的是有機會成為master節點的機器擁有投票權，如果僅僅是資料節點應該不具備選舉權。
3、可能產生「腦裂」的原因？
（1）網路原因 內網一般不會出現此問題，可以監控內網流量狀態。外網的網路出現問題的可能性大些。
（2）節點負載 由於master節點與data節點都是混合在一起的，所以當工作節點的負載較大（確實也較大）時，導致對應的es例項停止響應，而這台伺服器如果正充當著master節點的身份，那麼一部分節點就會認為這個master節點失效了，故重新選舉新的節點，這時就出現了腦裂； 這裡最好是master節點和資料節點分開。
（3）**記憶體 由於data節點上es程序占用的記憶體較大，較大規模的記憶體**操作也能造成es程序失去響應。
4、應對「腦裂」的解決辦法
node.master: true
node.data: false
node.master: false
node.data: true
監控項解釋
proc.num name,user,state,command user 指定啟動該程序的使用者 state 程序狀態，可能是殭屍程序，正在執行的程序，正在監聽的程序 command 模糊匹配的，在啟動的命令列引數中有的就能被識別到 其實他執行的linux命令就是 ps ef proc.num z...
es配置項分析及腦裂問題
1 elasticsearch重要配置項解釋 集群的名字cluster.name elasticsearch wyl配置當前節點的名字,每個節點的名字都應該是唯一的node.name node1 es儲存資料的地方path.data opt elasticsearch data es儲存日誌的地方p...
ES 集群配置
需要確認其它es節點中的data目錄，一定要清空，不能有資料。修改elasticsearch.yml這個配置檔案如下 配置集群名稱，保證每個節點的名稱相同，如此就能都處於乙個集群之內了 cluster.name es cluster 每乙個節點的名稱，必須不一樣 node.name es node1...