正确重启Elaticsearch集群姿势

遇到的问题

      日常维护Elaticsearch集群，难免会遇到要重启节点甚至重启集群的时候，重启后经常遇到数据恢复缓慢，甚至恢复失败。 之前不明白重启过程中集群在干嘛，为了快速恢复某个异常节点往往直接重启集群，导致搜索业务下线。

观察到的现象

节点异常后，集群开始迁移异常节点数据分片到其它正常的节点上面，尝试自动恢复集群。

如果这时候节点上面的数据量比较大，恢复缓慢是必然的（需要从正常节点把数据完整的复制过去，非常消耗服务器资源）。

如果这时候还有写入索引操作，往往会影响分片的分配恢复（这个原理还没弄清楚，当前骚操作把同步进程关闭了，恢复后再开启）。

 

理解ES自动分配分片机制

Elaticsearch 的allocation 机制尝试寻找最优的节点来分配分片

• 对于新建的索引。allocator按照分片数量升序排序节点列表，注意，是按照分片数量，而不是分片的大小 。然后decider依次遍历节点列表，根据分配规则判断是否要把分片分配到该节点。

• 对于已有的索引。当节点重启时，触发对于已有分片的分配。对于主分片，allocator只允许把主分片分配到拥有分片完整数据的节点上，即只有完整数据的副分片才能升为主节点;对于副分片，allocator优先分配到拥有分片数据(即使数据不是最新的)的节点上。

allocation的细节

• shard allocation发生在：
  (1)创建/删除一个Index
  (2)加入/离开一个Node
  (3)手动执行reroute命令
  (4)修改replication数量
  (5)集群重启

从主分片恢复数据到复制分片的3个阶段：

• 第一阶段，对于主分片上的segment file做一个快照，然后拷贝到复制分片所在的节点，在数据拷贝期间，不会阻塞索引请求，新增的索引操作会记录到translog中（理解为于临时文件）。
• 第二阶段，对于translog做一个快照，此快照包含第一阶段新增的索引请求，然后重放快照里的索引操作，这个阶段仍然不会阻塞索引请求，新增索引操作记录到translog中。
• 第三阶段，为了能达到主副分片完全同步，阻塞新索引请求，然后重放上一阶段新增的translog操作。

 

分析：

当有节点异常或者退出之后，集群会认为该节点挂掉了，就开始转移数据，当重启之后，它又会恢复数据，所以数据量较大的情况，容易引发雪崩效应。

 

解决方法

1、重启前关闭自动分配分片，启动后再开启；

2、修改配置，让集群发现节点后不立刻迁移数据，留出时间让管理员手动修复节点。

 

方法一：（适合正常重启）

1、关闭自动分配分片

curl  -H "Content-Type: application/json"   -XPUT http://localhost:9200/_cluster/settings?pretty -d '{
  "transient" : {
    "cluster.routing.allocation.enable" : "none"
  }
}'

2、关闭异常节点

3、修复异常节点

4、开启自动分配分片

curl  -H "Content-Type: application/json"   -XPUT http://localhost:9200/_cluster/settings?pretty -d '{
  "transient" : { 
    "cluster.routing.allocation.enable" : "all"
  }
}'

 

方法二：（日常运行）

下面是修改 elasticsearch.yml 文件
gateway.recover_after_nodes: 8
防止Elasticsearch集群立即开始数据恢复，直到集群中节点至少有八个节点存在。

一般设置上面这个参数就够用了。

 

以下可选配置，根据自己需求组合配置：

gateway.expected_nodes: 8

gateway.recover_after_time: 30m
集群开始数据恢复等到30分钟后或者10个节点加入，以先到者为准。