ES集群异常Red分析

简介

早上把某个es节点重启后集群就一直是red状态，有个索引一直initializing状态，对ES不懂的我当时慌不择路，下面把排查步骤记录下来。

状态分类

Green：所有的主分片和副本分片都可用
yellow：所有的主分片都可用，但不是所有的副本分片都可用
Red：不是所有的主分片都可用
主分片和副本不能在同一个节点上，所以副本就是未分配unassignea

从上可知，集群red是由于有主分片不可用，这种情况一般是由于节点宕机。

有什么影响呢？

至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。

此时我们可以执行相关的命令进行状态检查。

$ curl -XGET "http://ip:9200/_cluster/health?pretty"
{
  "cluster_name" : "diandian-es-es-appcomment",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 343,
  "active_shards" : 358,
  "relocating_shards" : 0,
  "initializing_shards" : 1,			# 看这里有一个索引在加载
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 99.72144846796658
}

active_shards 是涵盖了所有索引的所有分片的汇总值，其中包括副本分片。
relocating_shards 显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0，不过在 Elasticsearch 发现集群不太均衡时，该值会上涨。比如说：添加了一个新节点，或者下线了一个节点。
initializing_shards 显示的是刚刚创建的分片的个数。比如，当你刚创建第一个索引，分片都会短暂的处于 initializing 状态，分片不应该长期停留在 initializing 状态。你还可能在节点刚重启的时候看到 initializing 分片：当分片从磁盘上加载后，它们会从 initializing 状态开始。所以这一般是临时状态。
unassigned_shards 是已经在集群状态中存在的分片，但是实际在集群里又找不着。最常见的体现在副本上。比如，我有两个es节点，索引设置分片数量为 10， 3 副本，那么在集群上，由于灾备原则，主分片和其对应副本不能同时在一个节点上,es无法找到其他节点来存放第三个副本的分片，所以就会有 10 个未分配副本分片。如果你的集群是 red 状态，也会长期保有未分配分片（因为缺少主分片）。

unassigned_shards原因1
- 上面说了一种造成 unassigned_shards的原因，就是副本太多，节点太少，es无法完成分片。
- 举一反三！由于索引的副本是可以动态修改的，那么，如果在修改时分配的副本数大于节点数目，那么肯定会有分片是这个状态。
- 这种情况的解决办法有两种：
  - 1、是动态调整一下副本数量。
  - 2、新加入一个节点来平衡。
unassigned还有其他原因？
目前集群爆红，但是所有节点都还在，有点诡异，从集群状态看，一共是两个分片有问题，一个正在初始化，一个是unassigned。确定了故障范围后，我们再来从索引层面、分片层面深入的分析具体原因把。