ElasticSearch重启失败的解决方案
原文网址: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会重启实例。这会导致挂起的任务越来越多,集群不可恢复。
处理步骤
- 重启的过程中,发现大量ES实例执行_cluster/health命令超时错误,但其实数据仍在缓慢恢复中。于是注释_cluser/health检查脚本,防止实例多次失败后,被manager重启。
- 再次重启后,发现大量分片处于未分配状态,执行_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 - 再次重启后,集群开始恢复,查看_cat/thread_pool/,generic 线程池(分片恢复会用到该线程池)已经到达128,查看界面CPU使用率也在70-80,查看日志,分片正在恢复中。
10分钟左右,集群恢复到80%左右,开始恢复缓慢,初始化分片(initializing_shards)有2000多个,这些分片初始化的过程耗时接近2小时。
原因分析:在多次重启的过程中,业务侧并没有停止,由于有些primary新写入了数据,在数据的recovery过程中,需要从主副本之间拷贝数据,或者利用translog恢复数据。直到primary-replica完全in-sync后,才会完成初始化。 这个过程取决于shard的大小和新写入量的大小(初始化的分片普遍数据量较大)。
- 最后有一个分片无法分配,查看原因,该分片无法从translog in-sync(同步)。查看该索引settings,sync_interval设置为360s,设置同步刷新时间过多,会有一定几率发生数据丢失(客户有原数据备份)。
- 集群恢复后,还原集群参数配置和健康检查脚本。
问题根因
- 集群的分片数过多,按一个实例管理600shard为标准,该集群分片数过度超标的。合 理设置索引分片,定期对历史索引进行处理(关闭或删除不需要的索引)。
- 目前的健康检查机制需要优化,使用_cluster/health去判断各实例的健康是否合理,包 括检查周期等。在EsMaster压力过大的情况下,_cluster/health可能会造成误判。
还没有评论,来说两句吧...