在es的维护中少不了要重启节点,毕竟重启可以解决80%的问题,那么你知道怎么正确的重启es节点么?
es版本 6.5.4
1、禁用分片分配
执行下面的配置,就可以禁用分片分配
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "none" } }
我们在重启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
- 对于不再写入的冷分片,设置同步刷新, master知道这些数据在重启的结点上存在并且和primary一致,只需要更新一下集群的状态,将他们allocate到刚启动的结点,并且状态置为started。所以这个过程非常快,看起来瞬间可以完成。
3、干掉一个节点
别管你的es是怎么部署的,这个时候干掉一个节点即可(需要注意的是k8s集群会自动拉起来一个,可以通过修改deployment配置设置两个es节点)
4、Do what you want for this node!
做你该做的事情,换镜像还是改配置
5、重启该节点
- 启动新升级的节点,并通过检查日志文件或提交_cat / nodes请求来确认它已加入集群
6、重新启用分片分配
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
7、等待同步
- 在升级下一个节点之前,请等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度
- 未同步刷新的碎片可能需要更长的时间才能恢复。您可以通过提交_cat/recovery请求来监视各个分片的恢复状态
8、等你的头上。。。不对,等集群绿了就完成一个节点的重启了。