ElasticSearch 集群与索引Red&Yellow状态分析思路

Posted 2023-04-02

参考技术A ES的索引有红，黄，绿三种状态，其中绿色代表正常状态，红色和黄色则说明多少有一些问题。我们在正常的ES运维过程中常常需要处理这些情况。

先说明索引的三种颜色代表的意义吧：

绿色：索引的所有分片都正常分配。

黄色：至少有一个副本没有得到正确的分配。

红色：至少有一个主分片没有得到正确的分配。

集群和节点同样有三种颜色，这个颜色取决于相关索引的最差状况。比如说，整个集群中有3个节点，10个索引，每个索引分成3个分片，并有一份副本。如果其中有一个节点离线，上面有多个索引的主分片。那么集群的状态就是红色(red)

事实上，索引状态变成红色或者黄色并不一定是出了问题。这些情况可以通过 cat API查询获知，参考文档： https://www.elastic.co/guide/en/elasticsearch/reference/7.1/cat-shards.html

下面这些情况有可能是正常的情况，可能导致索引的状态临时性的变成红色和黄色。

INDEX_CREATED : 集群正在创建索引。

CLUSTER_RECOVERED : 集群处于重启阶段。

INDEX_OPENED : 正在重新打开一个已经关闭的索引。

NEW_INDEX_RESTORED :还原数据到一个新索引。

EXISTING_INDEX_RESTORED : 还原数据到一个已经关闭的索引。

REPLICA_ADDED : 索引的设置被修改，副本数增加。

REROUTE_CANCELLED : 由于reroute命令被取消导致有一些分片没有被分配。

REINITIALIZED :由于一个分片的状态重新退回到初始化导致。

REALLOCATED_REPLICA :副本位置变化导致未分配。

只有下面几个状态是明确地由于分片错误导致的：

ALLOCATION_FAILED : 由于配置原因或者资源问题导致未分配情况。

DANGLING_INDEX_IMPORTED : 副本在节点离线情况下被修改，在这个副本回到集群中时会产生此问题。

在运维的过程中，如果发现集群的状态变成黄色或者红色，我们不妨等一等，很多问题会在短时间消失。然而，并不是所有错误都能自动修复，如果发现集群状态一直不正常的情况下，我们需要分析具体情况，找出导致问题的根本原因，再将其修复。

ES提供了 health API供我们查询集群的状态和发现问题的原因：

参考文档： https://www.elastic.co/guide/en/elasticsearch/reference/7.1/cluster-health.html

我们可以看到一些用法：

GET _cluster/health ：检测集群的健康状态，可以使用这个API检测集群的节点数量

GET _cluster/health?level=indices : 查看全部索引的状态，找出有问题的索引

GET _cluster/health/index_name ： 检测某个索引的状态，分析问题

GET _cluster/health?level=shards : 查看分片分配的情况，寻找未分配的分片

GET _cluster/allocation/explain : 查看第一个未分配分配的故障原因

在找到原因后，需要对一些不能自动恢复的问题进行修复。

比如，由于routing的设置，某些索引需要在标记为hot的节点上进行分配，但是集群内并没有标记为hot的节点，这时，索引就会由于主分片无法分配而处于红色状态。解决这种问题，可以向集群中添加或者将集群中某些节点标记为hot来解决，也可以改变routing的策略使得索引主分片可以被正确分配。

又比如，如果当前集群只有一个节点，但是索引的副本配置并非是0，这时副本分片会由于没有多余的节点而无法分配。需要往集群中添加新节点或者将副本配置设为0。

节点的磁盘空间不足可能导致相关分片无法分配，解决方法是增加新节点或者修改分片方案。

上述有一个状态 DANGLING_INDEX_IMPORTED ，是由于节点离线后，其上的索引被修改导致，这种情况是无法自动恢复的。解决方法是删除该有问题的节点。

集群中如果有节点离线，在相关分片重新分配之前，状态也会变为红色或者黄色。重新分配也也会加到集群剩余节点的压力。需要尽快修复问题，将节点重新上线。

集群状态变成红色或者黄色是运维时经常会出现的状况，并不是所有的情况都是因为故障导致，一些正常的操作也会导致红色或者黄色的状况，并且会在一段时间之内自动恢复。由于故障导致的状态变化往往不会自动恢复，需要通过一些手段进行调查，寻找解决方案并修复问题。

Elasticsearch6.4集群报yellow和red状态问题

集群非green状态都是非健康状态，是需要处理的

集群 red 状态
原因： 表示所有的主分片都未必健康可用，一般是由于某个索引的主分片为 unassigned 状态引起的
处理方法： 找出分片为 unassigned 状态的索引，手工分配即可。

官方文档的详细说明请添加链接描述

通过curl GET http://{ESIP}:9200/_cluster/health?level=indices 找出是哪个索引状态为 red ，如果索引重要则修复，如果不重要则delete掉，方法见下面 “修复 red 或 yellow 方法实践”

集群 yellow 状态
原因： 表示所有主分片健康可用，但副片都未必可用，最常见的情景是单节点时，主分片和副本不能在同一个节点上，所以副本就是未分配unassigned
处理方法： 过滤查看所有未分配索引的方式， curl -s "http://localhost:9200/_cat/shards" | grep UNASSIGNED结果，第一列表示索引名，第二列表示分片编号，第三列p是主分片，r是副本

`curl -s "http://{ESIP}:9200/_cat/shards" | grep UNASSIGNED

eslog1 3 p UNASSIGNED
eslog1 3 r UNASSIGNED
eslog1 1 p UNASSIGNED
eslog1 1 r UNASSIGNED`

修复 red 或 yellow 方法实践
知道哪个索引的哪个分片就开始手动修复，通过reroute的allocate分配

curl -XPOST ‘{ESIP}:9200/_cluster/reroute‘ -d ‘{
    "commands" : [ {
          "allocate" : {
              "index" : "eslog1",     --索引名
              "shard" : 4,
              "node" : "es1",           --分配的节点名
              "allow_primary" : true
          }
        }
    ]
}‘

分配副本时必须要带参数"allow_primary" : true, 不然会报错
当集群中es版本不同时，如果这个未分配的分片是高版本生成的，不能分配到低版本节点上，反过来低版本的分片可以分配给高版本，如果遇到了，只要升级低版本节点的ES版本即可