elasticsearch 節點重啟問題

elasticsearch集群的高可用和自平衡方案會在節點掛掉（重啟）後自動在別的結點上覆制該結點的分片，這將導致了大量的io和網路開銷。

如果離開的節點重新加入集群，elasticsearch為了對資料分片(shard)進行再平衡，會為重新加入的節點再次分配資料分片(shard), 當一台es因為壓力過大而掛掉以後，其他的es服務會備份本應那台es儲存的資料，造成更大壓力，於是整個集群會發生雪崩。

生產環境下建議關閉自動平衡。

一：關閉自動分片，即使新建index也無法分配資料分片

curl -xput  -d '
}'

二：關閉自動平衡，只在增減es節點時不自動平衡資料分片

curl -xput ?pretty -d '
}'

設定完以後檢視設定是否新增成功：

curl ?pretty

重新啟用自動分片

curl -xput  -d '
}

put /_all/_settings
}

未分配節點重新分配延遲到5分鐘之後

下面是修改 elasticsearch.yml 檔案

gateway.recover_after_nodes: 8

這將防止elasticsearch立即開始資料恢復，直到集群中至少有八個（資料節點或主節點）節點存在。

gateway.expected_nodes: 10 gateway.recover_after_time: 5m

集群開始資料恢復等到5分鐘後或者10個節點加入，以先到者為準。

參考：對某乙個例項進行重啟後，很有可能會導致該例項無法找到master而將自己推舉為master的情況出現，為防止這種情況，需要調整 elasticsearch.yml 中的內容

discovery.zen.minimum_master_nodes: 2

這個配置就是告訴elasticsearch除非有足夠可用的master候選節點，否則就不選舉master，只有有足夠可用的master候選節點才進行選舉。

該設定應該始終被配置為有主節點資格的點數/2 + 1，例如:

有10個符合規則的節點數，則配置為6.

有3個則配置為2.

persistent 重啟後設定也會存在

transient 整個集群重啟後會消失的設定

put /_cluster/settings
}

# 通過配置大多數節點(節點總數/ 2 + 1)來防止腦裂 #discovery.zen.minimum_master_nodes: 2 # 在乙個完整的集群重新啟動到n個節點開始之前，阻止初始恢復 #gateway.recover_after_nodes: 3

**：