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