ElasticSearch重启失败的解决方案

向右看齐 2023-09-26 11:07 18阅读 0赞

原文网址：[ElasticSearch重启失败的解决方案\_IT利刃出鞘的博客-CSDN博客][ElasticSearch_IT_-CSDN]

## 简介 ##

本文介绍ES重启失败的解决方法。

## **问题描述** ##

对ES集群进行了重启，集群重启几分钟后，部分实例开始逐渐下线，导致集群不可恢复。

## **集群规模** ##

普通模式，3EsMaster，40EsNode，每实例均为31GB内存。

数据量：

1000多index, 38365个shard，其中主分片28695个，数据量100T。

## **日志分析** ##

ES集群重启，恢复几分钟后，出现大量ping Master节点超时的错误，然后ES节点实例开始逐渐下线，导致集群恢复不了。

## **原因分析** ##

集群分片数过多，并发恢复过程中，同时业务没有停止，导致EsMaster处理压力过大，number\_of\_pending\_tasks(挂起的任务)逐渐增加，到达4W多，大量的任务阻塞。

此时\_cluster/health命令已无法正常返回结果，导致大量ES实例处于恢复中状态，连续3次检查超时后，Manager会重启实例。这会导致挂起的任务越来越多，集群不可恢复。

## **处理步骤** ##

1.  重启的过程中，发现大量ES实例执行\_cluster/health命令超时错误，但其实数据仍在缓慢恢复中。于是注释\_cluser/health检查脚本，防止实例多次失败后，被manager重启。
2.  再次重启后，发现大量分片处于未分配状态，执行\_cluster/allocation/explain查看分片未被分配的原因，发现shard恢复时的cluster.routing.allocation.node\_current\_incoming达到了最大值。鉴于集群主分片数太多，于是调大恢复参数至：cluster.routing.allocation.node\_initial\_primaries\_recoveries 200 cluster.routing.allocation.node\_concurrent\_recoveries 100 cluster.routing.allocation.cluster\_concurrent\_rebalance 100  
    同时因为有业务数据写入，将分片分配设置为none:cluster.routing.allocation.enable none
3.  再次重启后，集群开始恢复，查看\_cat/thread\_pool/，generic 线程池（分片恢复会用到该线程池）已经到达128，查看界面CPU使用率也在70-80，查看日志，分片正在恢复中。
4.  10分钟左右，集群恢复到80%左右，开始恢复缓慢，初始化分片（initializing\_shards）有2000多个，这些分片初始化的过程耗时接近2小时。
    
    1.  原因分析：在多次重启的过程中，业务侧并没有停止，由于有些primary新写入了数据，在数据的recovery过程中，需要从主副本之间拷贝数据，或者利用translog恢复数据。直到primary-replica完全in-sync后，才会完成初始化。 这个过程取决于shard的大小和新写入量的大小（初始化的分片普遍数据量较大）。
        
        1.  最后有一个分片无法分配，查看原因，该分片无法从translog in-sync（同步）。查看该索引settings，sync\_interval设置为360s，设置同步刷新时间过多，会有一定几率发生数据丢失（客户有原数据备份）。
        2.  集群恢复后，还原集群参数配置和健康检查脚本。

## **问题根因** ##

1.  集群的分片数过多，按一个实例管理600shard为标准，该集群分片数过度超标的。合 理设置索引分片，定期对历史索引进行处理（关闭或删除不需要的索引）。
2.  目前的健康检查机制需要优化，使用\_cluster/health去判断各实例的健康是否合理，包 括检查周期等。在EsMaster压力过大的情况下，\_cluster/health可能会造成误判。

[ElasticSearch_IT_-CSDN]: https://knife.blog.csdn.net/article/details/127264312