【Elasticsearch】es 集群健康值红色 red 分片未分配

深藏阁楼爱情的钟 2022-10-09 14:27 968阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70_pic_center]

# 1.概述 #

转载：[https://zhuanlan.zhihu.com/p/101608973][https_zhuanlan.zhihu.com_p_101608973]

转载这篇文章是因为根据我的文章

[【Elasticsearch】elasticsearch 7.x 查看分片未分配 (UNASSIGNED) 的原因][Elasticsearch_elasticsearch 7.x _ _UNASSIGNED_]

[【Elasticsearch】Elasticsearch 集群健康值红色 解决方案 或者 分片 未分配][Elasticsearch_Elasticsearch _ _ _ _]

讲解了大部分分片未分配的原因，但是一步一步的排查，深入的排查，这篇文章可以弥补。

# 前言 #

可能你经历过这些Red.

![在这里插入图片描述][20210625091010190.png]  
。。。等等

那ES的Red是神么意思？

这里说的red,是指es集群的状态，一共有三种，green、red、yellow。具体含义：

![在这里插入图片描述][20210625091040392.png]  
冷静分析  
从上图可知，集群red是由于有主分片不可用，这种情况一般是由于节点宕机。

有什么影响呢？

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

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

集群节点是否都存在、查看集群状态。

curl -uelastic:pwd  -XGET "http://ip:9200/_cluster/health?pretty"

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70]

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 1]

## unassigned\_shards原因1 ##

上面说了一种造成 unassigned\_shards的原因，就是副本太多，节点太少，es无法完成分片。  
举一反三！由于索引的副本是可以动态修改的，那么，如果在修改时分配的副本数大于节点数目，那么肯定会有分片是这个状态。  
这种情况的解决办法有两种：  
1、是动态调整一下副本数量。  
2、新加入一个节点来平衡。

## unassigned还有其他原因？ ##

目前集群爆红，但是所有节点都还在，有点诡异，从集群状态看，一共是两个分片有问题，一个正在初始化，一个是unassigned。确定了故障范围后，我们再来从索引层面、分片层面深入的分析具体原因把。

![在这里插入图片描述][20210625091156276.png]  
![在这里插入图片描述][20210625091202552.png]

# 索引层面分析 #

再执行

curl -uelastic:pwd  -XGET "http://ip:9200/_cluster/health?pretty&level=indices"

没错，还是这个api,不过值得注意的是level=indices，想必读者已经心领神会。这个api返回的是一个格式化后的json，如果太长，推荐输出到一个文本里面看。

!\[从返回的信息中，我们可以看到，01-04索引目前状态为red,它有2个分片，0个副本，有一个分片正在初始化，从这个数据可以看出，受影响的是主分片，想到这里，感到慌不择路。

# 分片层面分析 #

少侠，莫慌

知道了索引层面的故障信息，我们继续深究，看看分片层面。

curl -uelastic:pwd  -XGET "http://ip:9200/_cluster/health?level=shards"

当然，重点还是level=shards，显示如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 2]  
至此，我们可以得到更多的线索：

索引名：xxx-01-04。  
分片数量：2。  
副本数：0。  
有问题的分片号：0。并且是主分片。  
分片状态：initializing。说明正在初始化，自我恢复中。  
既然是在恢复，那找恢复相关的api，看看。

curl -u elastic:pwd -XGET http://ip:9200/索引名/_recovery?pretty=true

![在这里插入图片描述][20210625091309879.png]  
从上图可以看到，花费了14.1个小时，从translog中恢复！目前进度很是堪忧。配合kibana看一下：

![在这里插入图片描述][20210625091322569.png]

# 插播一下，translog的知识 #

我们把数据写到磁盘后,还要调用fsync才能把数据刷到磁盘中,如果不这样做在系统掉电的时候就会导致数据丢失,这个原理相信大家都清楚,elasticsearch为了高可靠性必须把所有的修改持久化到磁盘中。

我们的数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中。如果buffer快满了，或是一段时间之后，就会将buffer数据refresh到一个新的OS cache之中。

translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，  
一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志文件之中。

一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件数据，恢复到内存buffer和OS cache之中。  
整个commit过程就叫做一个flush操作

其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，  
可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，  
会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。

上述摘录于互联网，写得清晰明了，可以参考一下，分析看了日志也没有找到其他有用的信息，由于是历史索引，就将其删除掉了，虽然没有定位到根本原因，不过记录一下排查过程总是好的。

# 剩下的unassigned分片 #

解决了一个问题，那么还剩下一个分片是未分配的，还是从索引层面和分片层面查询检查，发现同样是0号主分片出问题。  
尝试手动分配

curl -uelastic:pwd -XPOST 'http://ip:9200/_cluster/reroute' -H"Content-Type:application/json" -d '{ 
            "commands" : [ { 
                  "allocate_stale_primary" : { 
                      "index" : "B_2020-01-05",
                      "shard" : 0,
                      "node" : "SL8u8zKESy6rSHjHO0jEvA"
                   
                  }
                }
            ]
        }'

报错：

No data for shard [0] of index [B_2020-01-05] found on node [SL8u8zKESy6rSHjHO0jEvA]"},"status":400}

尝试手动分配失败后，更换思路。摆脱掉各种复杂的查询API，使用es为我们提供的一个Explain API，它会解释为什么分片没有分配，解决问题之前，先诊断诊断。

curl -uelastic:pwd -XGET "http://ip:9200/_cluster/allocation/explain" -H"Content-Type:application/json" -d '{ 
      "index": "B_2020-01-05",
      "shard": 0,
      "primary": true
    }'

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 3]  
看上述错误，分片被锁住了，尝试分配，但是被拒绝，手动分配时，可以指定"acceptdataloss" : true。但这样会导致数据完全丢失。

这种情况一般出现在有结点短暂离开集群，然后马上重新加入，并且有线程正在对某个shard做bulk或者scroll等长时间的写入操作。等结点重新加入集群的时候，由于shard lock没有释放，master无法allocate这个shard。 通常/cluster/reroute?retryfailed=true可以解决问题，如果按照你说的依然无法解决，可能还有其他原因导致锁住该shard的线程长时间操作该shard无法释放锁（长时间GC?)。

如果retryfailed无法解决问题，可以尝试一下allocatestale\_primary，前提是需要知道这个shard的primary在哪个结点上。实在解决不了，又不想丢数据，还可以重启一下该结点，内存锁应该可以释放。

执行集群reroute命令：

curl -XPOST "http://ip:9200/_cluster/reroute?retry_failed=true"

再看分片状态：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 4]  
此时集群已经恢复Green。大功告成。

# 总结 #

一、遇到集群Red时，我们可以从如下方法排查：

集群层面：/\_cluster/health。  
索引层面：/\_cluster/health?pretty&level=indices。  
分片层面：/\_cluster/health?pretty&level=shards。  
看恢复情况：/\_recovery?pretty。

二、有unassigned分片的排查思路

\_cluster/allocation/explain，先诊断。  
/\_cluster/reroute尝试重新分配。

三、数据重放

如果实在恢复不了，那只能索引重建了。提供一种思路：

先新建备份索引

curl -XPUT ‘http://xxxx:9200/a_index_copy/‘ -d ‘{ 
    “settings”:{ 
            “index”:{ 
                    “number_of_shards”:3,
                    “number_of_replicas”:2
                }
        }
    }

通过reindex，将目前可用的数据导入：

POST _reindex{ "source": { "index": "a_index"},"dest": { "index": "aindexcopy","op_type": "create"}}

删除a\_index索引，这个必须要先做，否则别名无法添加

.curl -XDELETE ‘http://xxxx:9200/a\_index’

创建aindexcopy索引

curl -XPUT ‘http://xxxx:9200/a_index_copy/‘ -d ‘{ 
    “settings”:{ 
                    “index”:{ 
                    “number_of_shards”:3,
                    “number_of_replicas”:2
                }
        }
    }

通过reindex api将aindex数据copy到aindex\_copy。

POST _reindex
    { 
    "source": { 
                "index": "a_index"
                },
                "dest": { 
                "index": "a_index_copy",
                "op_type": "create"
        }
    }

删除a\_index索引，这个必须要先做，否则别名无法添加

curl -XDELETE 'http://xxxx:9200/a_index'

给aindexcopy添加别名a\_index

curl -XPOST 'http://xxxx:9200/_aliases' -d '
    { 
            "actions": [
                { "add": { "index": "a_index_copy", "alias": "a_index"}}
        ]
    }'

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70_pic_center]: /images/20221005/6796a05b90fa468b89daec6e525a6b0e.png
[https_zhuanlan.zhihu.com_p_101608973]: https://zhuanlan.zhihu.com/p/101608973
[Elasticsearch_elasticsearch 7.x _ _UNASSIGNED_]: https://blog.csdn.net/qq_21383435/article/details/108987730
[Elasticsearch_Elasticsearch _ _ _ _]: https://blog.csdn.net/qq_21383435/article/details/109016714
[20210625091010190.png]: /images/20221005/07ff307331c24aa89948d9aa1ba77c57.png
[20210625091040392.png]: /images/20221005/71c8ab26cb0a4b3999200d4953940934.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70]: /images/20221005/8b29e22958894a9e86f137f6e86cc109.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 1]: /images/20221005/a33fdf09390c4e04a23850bcae843aab.png
[20210625091156276.png]: /images/20221005/5a45c1525f2a4e1eaada212bbae110c3.png
[20210625091202552.png]: /images/20221005/12706182aded4d7ea441edd7c460b9e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 2]: /images/20221005/86d806ea913248879f44efdf2966f16c.png
[20210625091309879.png]: /images/20221005/83fc33acd5ab41fb819617f464f2ee9f.png
[20210625091322569.png]: /images/20221005/931a0be27c504c53b003a661eab7fad4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 3]: /images/20221005/b08e9a55e02e4c938294a1b169341a43.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 4]: /images/20221005/1c01bd2e8b0a430789be130da5ed6322.png