elasticsearch重启过程

在es的维护中少不了要重启节点，毕竟重启可以解决80%的问题，那么你知道怎么正确的重启es节点么？

es版本 6.5.4

1、禁用分片分配

执行下面的配置，就可以禁用分片分配

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "none"
  }
}
1
2
3
4
5
6

我们在重启es的时候一定要知道es发生了那些过程：

1. 该节点所有分片变成UNASSIGNED状态
2. 该节点所包含的主分片在其他结点上对应的副分片被推举为主分片，而本地的这些主分片变成副分片，并且状态变成UNASSIGNED状态
3. cluster.routing.allocation.enable设置为none， 这些replica不会再其他结点上复制恢复，保持在UNASSIGNED状态
4. 集群状态应该是yellow，意味着所有索引的primary都存在可用，只是部分复制片因为上述参数设置的原因，没有立即进行恢复。
5. 启的结点加入集群，通过master恢复状态信息以后，可以得知那些UNASSIGNED的shard，在这个结点上存在数据。

2、同步刷新

POST _flush/synced
1

1. 对于不再写入的冷分片，设置同步刷新， master知道这些数据在重启的结点上存在并且和primary一致，只需要更新一下集群的状态，将他们allocate到刚启动的结点，并且状态置为started。所以这个过程非常快，看起来瞬间可以完成。

3、干掉一个节点

别管你的es是怎么部署的，这个时候干掉一个节点即可（需要注意的是k8s集群会自动拉起来一个，可以通过修改deployment配置设置两个es节点）

4、Do what you want for this node！

做你该做的事情，换镜像还是改配置

5、重启该节点

1. 启动新升级的节点，并通过检查日志文件或提交_cat / nodes请求来确认它已加入集群

6、重新启用分片分配

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
1
2
3
4
5
6

7、等待同步

1. 在升级下一个节点之前，请等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度
2. 未同步刷新的碎片可能需要更长的时间才能恢复。您可以通过提交_cat/recovery请求来监视各个分片的恢复状态

8、等你的头上。。。不对，等集群绿了就完成一个节点的重启了。