ElasticSearch- 单节点 unassigned_shards 故障排查（NoShardAvailableActionException）

帅大大的架构之路

已于 2023-08-24 15:19:58 修改

阅读量2.7k

点赞数

分类专栏： # elfk 文章标签： elasticsearch jenkins 大数据

于 2023-08-24 15:09:19 首次发布

原文链接：https://www.cnblogs.com/FLY_DREAM/p/14269859.html

版权

elfk 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

原文

ElasticSearch- 单节点 unassigned_shards 故障排查

故障现象#

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PeRa51Gj-1692860881533)(https://cdn.devopsing.site/2020/20210112231802.png)]

在部署ELK的单机环境，当连接Kibana时候提示下面错误，即使重启整个服务也是提示Kibana server is not ready.

{"message":"all shards failed: [search_phase_execution_exception] all shards failed","statusCode":503,"error":"Service Unavailable"}

排查过程#

前段时间ELK服务还是正常的，进入容器去ping ip 也都没问题，服务也都是Up 状态； ElasticSearch 服务也可以通过http://localhost:9200/ 访问到，但是就是kibana 不能连接ElasticSearch

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BisIggL7-1692860881534)(https://cdn.devopsing.site/2020/20210112231919.png)]

再查看 kibana 日志发现如下信息, 其中包含了no_shard_available_action_exception, 看起来是分片 的问题。

{
    "type": "error",
    "@timestamp": "2020-09-15T00:41:09Z",
    "tags": [
        "warning",
        "stats-collection"
    ],
    "pid": 1,
    "level": "error",
    "error": {
        "message": "[no_shard_available_action_exception] No shard available for [get [.kibana][doc][config:6.8.11]: routing [null]]",
        "name": "Error",
        "stack": "[no_shard_available_action_exception] No shard available for [get [.kibana][doc][config:6.8.11]: routing [null]] :: {\"path\":\"/.kibana/doc/config%3A6.8.11\",\"query\":{},\"statusCode\":503,\"response\":\"{\\\"error\\\":{\\\"root_cause\\\":[{\\\"type\\\":\\\"no_shard_available_action_exception\\\",\\\"reason\\\":\\\"No shard available for [get [.kibana][doc][config:6.8.11]: routing [null]]\\\"}],routing [null]]"
    }

通过 ES可视化工具-cerebro 查看

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d7QeDaSy-1692860881534)(https://cdn.devopsing.site/2020/20210112231922.png)]

实际当时情况是"红色"的，而不是目前看到的 “黄色”， heap/disk/cup/load 基本都是红色的, 可能因为当时手动删除了几个index原因

黄色虽然kibana可以访问ES了，但是黄色代表ES仍然是不健康的

查看单节点Elasticsearch健康状态#

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 677,
  "active_shards" : 677,
  "relocating_shards" : 0,
  "initializing_shards" : 4,
  "unassigned_shards" : 948,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 5,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 599,
  "active_shards_percent_as_number" : 41.559238796807854
}

从上面的 unassigned_shards 可以存在大量分片没有被分配，当时看到的实际有1000多个。

查询 UNASSIGNED 类型的索引名字#

curl -XGET http://localhost:9200/_cat/shards

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VwYjYF2W-1692860881534)(https://cdn.devopsing.site/2020/20210112231926.png)]

故障原因大概确定了，应该就是unassigned_shards导致的下面就看如何解决

解决方案#

如果是集群环境，可以考虑使用 POST /_cluster/reroute 强制把问题分片分配到其中一个节点上了
但是对于目前的单机环境，从上面截图可以看出存在5个 unassigned 的分片，新建索引时候，分片数为5，副本数为1，新建之后集群状态成为yellow，其根本原因是因为集群存在没有启用的副本分片。

解决办法就是，在单节点的elasticsearch集群，删除存在副本分片的索引，新建索引的副本都设为0。然后再查看集群状态

通过如果下命令，设置number_of_replicas=0,将副本调整为0. 如下图所示，es变成了“绿色”
```
curl -XPUT 'http://localhost:9200/_settings' -H 'content-Type:application/json' -d'
{
"number_of_replicas": 0
}'
```
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3CO57mHy-1692860881535)(https://cdn.devopsing.site/2020/20210112231930.png)]

知识点#

副本分片 主要目的就是为了故障转移，如果持有主分片的节点挂掉了，一个副本分片就会晋升为主分片的角色。

所以副本分片和主分片是不能放到一个节点上面的，可是在只有一个节点的集群里，副本分片没有办法分配到其他的节点上，所以出现所有副本分片都unassigned得情况。因为只有一个节点，如果存在主分片节点挂掉了，那么整个集群理应就挂掉了，不存在副本分片升为主分片的情况。

参考#

https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/#monitoring-for-unassigned-shards
https://stackoverflow.com/questions/19967472/elasticsearch-unassigned-shards-how-to-fix
https://www.cnblogs.com/ningskyer/articles/5986642.html

你好！当Elasticsearch单节点出现unassigned_shards故障时，可以按照以下步骤进行故障排查：

首先，检查Elasticsearch日志，特别是主节点（master node）和数据节点（data node）的日志。查找任何与unassigned shards相关的错误或警告信息。
确保所有的节点都处于运行状态。使用Elasticsearch的API或命令行工具（如curl或Kibana Dev Tools）检查节点的健康状态。例如，可以使用以下命令获取集群的健康状态：

GET /_cluster/health

确保集群的状态是“green”或“yellow”，而不是“red”。"red"意味着有unassigned shards存在。

如果集群状态是“red”，则说明有一些问题需要解决。查看集群状态响应中的详细信息，了解unassigned shards的原因。例如，可以使用以下命令获取详细信息：

GET /_cluster/allocation/explain

这将提供有关为什么分配失败的信息。

检查分片分配策略和设置。确保分片分配设置（allocation settings）允许分片在节点之间进行平衡。您可以使用以下命令获取当前的分片分配设置：

GET /_cluster/settings

确保cluster.routing.allocation.enable设置为all或primaries，这样分片才会在节点之间进行平衡。

检查集群可用的资源。确保节点上有足够的磁盘空间和内存可用于分片的分配。如果某个节点资源不足，Elasticsearch可能会拒绝分配新的分片。
如果您尝试过以上步骤仍然无法解决问题，您可以尝试手动分配unassigned shards到可用节点。首先，使用以下命令获取未分配的分片列表：

GET /_cat/shards?h=index,shard,prirep,state,unassigned.reason

然后，使用以下命令手动分配一个未分配的分片：

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate": {
        "index": "your_index",
        "shard": shard_number,
        "node": "your_node",
        "allow_primary": true
      }
    }
  ]
}

将your_index替换为未分配分片所属的索引，shard_number替换为未分配分片的编号（例如0或1），your_node替换为您要分配给的节点名称。

这些是故障排查unassigned_shards问题的一些常见步骤。希望对你有所帮助！如果你还有其他问题，请随时提问。

没事就去问 chatgpt -_-