ElasticSearch重启失败的解决方案

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

原文网址: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可能会造成误判。

发表评论

表情:
评论列表 (有 0 条评论,145人围观)

还没有评论,来说两句吧...

相关阅读

    相关 elasticsearch过程

    在es的维护中少不了要重启节点,毕竟重启可以解决80%的问题,那么你知道怎么正确的重启es节点么? es版本 6.5.4 1、禁用分片分配 执行下面的配置,就可以禁用分片