Elasticsearch集群异常状态(RED、YELLOW)原因分析

2022-04-26 16:22:56 浏览数 (1)

说明

本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)

集群状态为什么会异常?

想知道这个,我们首先需要了解一下集群的几种状态。

Elasticsearch 集群健康状态分为三种:

  • GREEN
  • YELLOW
  • RED

GREEN是最健康的状态,说明所有的分片包括副本都可用。这种情况Elasticsearch集群所有的主分片和副本分片都已分配,Elasticsearch集群是100%可用的。

那么,集群状态在什么情况下发生RED和YELLOW呢?

YELLOW:主分片可用,但是副本分片不可用。这种情况Elasticsearch集群所有的主分片已经分配了,但至少还有一个副本是未分配的。不会有数据丢失,所以搜索结果依然是完整的。不过,集群高可用性在某种程度上会被弱化。可以把yellow想象成一个需要关注的warnning,该情况不影响索引读写,一般会自动恢复。

RED:存在不可用的主分片。此时执行查询虽然部分数据仍然可以查到,但实际上已经影响到索引读写,需要重点关注。这种情况Elasticsearch集群至少一个主分片(以及它的全部副本)都在缺失中。这意味着索引已缺少数据,搜索只能返回部分数据,而分配到这个分片上的请求都返回异常。

查看集群状态

使用kibana开发工具,查看集群状态:

代码语言:javascript复制
GET /_cluster/health

这里可以看到,当前集群状态为red,有9个未分配的分片

ES健康接口返回内容官方解释

指标

含义

cluster_name

集群的名称

status

集群的运行状况,基于其主要和副本分片的状态。状态为:– green所有分片均已分配。– yellow所有主分片均已分配,但未分配一个或多个副本分片。如果群集中的某个节点发生故障,则在修复该节点之前,某些数据可能不可用。– red未分配一个或多个主分片,因此某些数据不可用。在集群启动期间,这可能会短暂发生,因为已分配了主要分片。

timed_out

如果false响应在timeout参数指定的时间段内返回(30s默认情况下)

number_of_nodes

集群中的节点数

number_of_data_nodes

作为专用数据节点的节点数

active_primary_shards

活动主分区的数量

active_shards

活动主分区和副本分区的总数

relocating_shards

正在重定位的分片的数量

initializing_shards

正在初始化的分片数

unassigned_shards

未分配的分片数

delayed_unassigned_shards

其分配因超时设置而延迟的分片数

number_of_pending_tasks

尚未执行的集群级别更改的数量

number_of_in_flight_fetch

未完成的访存数量

task_max_waiting_in_queue_millis

自最早的初始化任务等待执行以来的时间(以毫秒为单位)

active_shards_percent_as_number

群集中活动碎片的比率,以百分比表示

问题分析

当集群状态异常时,需要重点关注unassigned_shards没有正常分配的分片,这里举例说明其中一种场景。

找到异常索引

查看索引情况,并根据返回找到状态异常的索引

代码语言:javascript复制
GET /_cat/indices

查看详细的异常信息

代码语言:javascript复制
GET /_cluster/allocation/explain

这里通过异常信息可以看出:

  1. 主分片当前处于未分配状态(current_state),发生这个问题的原因是因为分配了该分片的节点已从集群中离开(unassigned_info.reason);
  2. 发生了上诉问题之后,分片无法自动分配分片的原因是集群中没有该分片的可用副本( can_allocate );
  3. 同时也给出了更详细的信息(allocate_explanation

这种情况发生的原因是因为集群有节点下线,导致主分片已没有任何可用的分片数据,当前唯一能做的事就是等待节点恢复并重新加入集群。

注:某些极端场景,比如单副本集群的分片发生了损坏,或是文件系统故障导致该节点被永久移除,而此时只能接受数据丢失的事实,并通过reroute commends来重新分配空的主分片。

分片未分配(unassigned_info.reason)的所有可能

reason

原因

INDEX_CREATED

索引创建,由于API创建索引而未分配的

CLUSTER_RECOVERED

集群恢复,由于整个集群恢复而未分配

INDEX_REOPENED

索引重新打开

DANGLING_INDEX_IMPORTED

导入危险的索引

NEW_INDEX_RESTORED

重新恢复一个新索引

EXISTING_INDEX_RESTORED

重新恢复一个已关闭的索引

REPLICA_ADDED

添加副本

ALLOCATION_FAILED

分配分片失败

NODE_LEFT

集群中节点丢失

REROUTE_CANCELLED

reroute命令取消

REINITIALIZED

重新初始化

REALLOCATED_REPLICA

重新分配副本

可以通过上诉分析方式初步判断集群产生未分配分片的原因,一般都可以在allocation explain api中得到想要的答案。

小结

可见,集群状态和分片是否分配有直接关系。所以遇到集群状态异常时,直接分析分片没有分配的原因即可,对症下药,从根本解决问题。

0 人点赞