es只是在選舉的時候用了raft，日志復制沒有用，同步狀態是二階段

請求攜帶的term是為了讓選舉成功概率更高一些么

多個node都可以成為leader,但是最后一個leader會成為leader

node只要看到其他節點發送了請求選票的請求就會推出leader

這種情況可能產生腦裂

這就是cluster_state上的新舊兩種配置

7之前的版本這個rpc可能非常長，在集群分片很多的情況下

total_shard_per_node阻止了

水位線在混部的時候有講究的

close也費勁，因為也會使用refresh

nginx只看看9200是活的，所以就會無腦轉發，導致了tcp99暴漲
協調節點內存加到100G
G1進行gc
g1加到過300G，region很多導致時間比較長

協調節點的是更加吃內存的，數據節點正常就是31g，協調節點可以放成更大，關于 g1 的 也可以看下： https://elasticsearch.cn/question/4589

glibc max_arrang 設置為1

兩個master導致的隱患，master掛了被回收了，后來再加入新的加兩個也不認識了，沒法選出master了
這個問題做一下測試

export MALLOC_ARENA_MAX=1
參考這個博客的解釋
https://www.easyice.cn/archives/341

總結

以上是生活随笔為你收集整理的es最新的集群选举策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。