elasticsearch之節點重啓

Elasticsearch節點重啓時背後發生的故事有哪些，應該注意哪些配置內容，本篇文章作一個簡單的探討。

節點離開

在elasticsearch集羣中，假設NodeA由於種種緣由退出集羣，在NodeA上的Shard分片狀況(ShardA是主分片，ShardB是某一分片副本)

1. 在存活節點上找到ShardA的副本，將該副本升格爲主分片
2. 因爲ShardB這一分片副本丟失，因此會從新建立相應的分片副本
3. 在存活的節點中對於分片進行再平衡
   這樣作的目的是保證每一個分片都有足夠的副本，能夠避免數據丟失。須要注意的是，步驟二和步驟三牽涉到大量的網絡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