Elasticsearch節點重啟時背后發生的故事有哪些，應該注意哪些配置內容，本篇文章做一個簡單的探討。
節點離開
在elasticsearch集群中，假設NodeA因為種種原因退出集群，在NodeA上的Shard分片情況(ShardA是主分片，ShardB是某一分片副本)
- 在存活節點上找到ShardA的副本，將該副本升格為主分片
- 由於ShardB這一分片副本丟失，所以會重新創建相應的分片副本
- 在存活的節點中對於分片進行再平衡
這樣做的目的是保證每個分片都有足夠的副本，可以避免數據丟失。需要注意的是，步驟二和步驟三牽涉到大量的網絡I/O操作。
節點返回
如果離開的節點重新加入集群，elasticsearch為了對數據分片(shard)進行再平衡，會為重新加入的NodeA再次分配數據分片(Shard), 這會再次導致大量的網絡I/O操作。
延遲副本的重新分配
如果NodeA在離開前上面存在副本ShardB，重新加入之后還是有副本ShardB，看起來一樣，但其實中間已經進行了大量的網絡I/O，那么有沒有辦法延遲副本的重新分配呢，這樣會冒丟失數據的可能(如果在NodeA重新加入之前，其它節點也掛了), 但是可以節省相應的網絡開銷。
延遲副本分配可以通過設置參數index.unassigned.node_left.delayed_timeout來實現，該參數動態可調，默認值是1分鍾(1m)
PUT /_all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
上述腳本將副本重新分配延遲到5分鍾之后。
查看數據分片分布情況
使用elasticsearch中的marvel插件可以很清楚的看到數據分片的分布情況，選取marvel中右上角 DashBoard 中的 Shard Allocation ， 可以看到類似於下圖的分布情況
更多選項
如果日常維護elasticsearch集群，針對某一節點進行需要重啟的更改，那么可以先禁止分片分配，待重啟完成后，再打開
PUT _cluster/setting
{
"cluster.routing.allocation.disable_allocation": true
}
避免節點重啟導致的腦裂
如果elasticsearch集群中節點數比較多，而且負載也比較高，這個時候對某一個instance進行重啟，很有可能會導致該instance無法找到master而將自己推舉為master的情況出現，如何防止，需要調整 elasticsearch.yml 中的內容
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.timeout: 120s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["host1","host2"]
client.transport.ping_timeout: 60s
加快recovery的進程
Elasticsearch在默認情況下將資源更多的分配給正常的traffic,這樣給recovery的資源相對有限，會導致整個集群長時間處於yellow狀態，如果機器配置很強勁，那么更改如下配置，可以加快elasticsearch instance重啟之后的恢復過程。
cluster.routing.allocation.node_initial_primaries_recoveries: 10
cluster.routing.allocation.node_concurrent_recoveries: 5
indices.recovery.max_bytes_per_sec: 100mb
indices.recovery.concurrent_streams: 5