首页 > 其他分享 >kibana启动失败Kibana server is not ready yet,后台日志报错:NoShardAvailableActionException

kibana启动失败Kibana server is not ready yet,后台日志报错:NoShardAvailableActionException

时间:2023-06-25 14:11:24浏览次数:55  
标签:副本 number shards Kibana 分配 报错 分片 NoShardAvailableActionException 节点

kibana.log日志报错信息:

,{"level":"error","message":"Action failed with 'no_shard_available_action_exception'. Retrying attempt 8 out of 10 in 64 seconds."},{"level":"error","message":"Action failed with 'no_shard_available_action_exception'. Retrying attempt 9 out of 10 in 64 seconds."},{"level":"error","message":"Action failed with 'no_shard_available_action_exception'. Retrying attempt 10 out of 10 in 64 seconds."}],"sourceIndex":{"_tag":"None"},"targetIndex":".kibana_7.12.0_001","versionIndexReadyActions":{"_tag":"None"},"updateTargetMappingsTaskId":"7DrpBWixQqirLVwQUONeSg:541034","reason":"Unable to complete the UPDATE_TARGET_MAPPINGS_WAIT_FOR_TASK step after 10 attempts, terminating.","outdatedDocuments":[],"message":"[.kibana] UPDATE_TARGET_MAPPINGS_WAIT_FOR_TASK -> FATAL"}

ES 的 CollectorDBCluster.log日志报错信息如下

org.elasticsearch.action.NoShardAvailableActionException: No shard available for [get [.tasks][task][7DrpBWixQqirLVwQUONeSg:541031]: routing [null]]

问题解决:

查看ES单机状态:

[es@uni-dzkf-elk kibana-log]$  curl -X GET 'http://172.16.1.10:9200/_cluster/health?pretty'
{
  "cluster_name" : "CollectorDBCluster",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 2018,
  "active_shards" : 2018,
  "relocating_shards" : 0,
  "initializing_shards" : 4,
  "unassigned_shards" : 625,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 11,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 165139,
  "active_shards_percent_as_number" : 76.23724971666037
}
[es@uni-dzkf-elk kibana-log]$

  

发现ES单机状态为red且存在大量"unassigned_shards"的分片,各状态代表如下

绿色表示最健康的状态,代表所有的主分片和副本分片都可用; 黄色表示所有的主分片可用,但是部分副本分片不可用; 红色表示部分主分片不可用. (此时执行查询部分数据仍然可以查到)

查看索引,发现"unassigned_shards"的分片状态都为red

 unassigned 分片问题可能的原因?

INDEX_CREATED:  由于创建索引的API导致未分配。
CLUSTER_RECOVERED:  由于完全集群恢复导致未分配。
INDEX_REOPENED:  由于打开open或关闭close一个索引导致未分配。
DANGLING_INDEX_IMPORTED:  由于导入dangling索引的结果导致未分配。
NEW_INDEX_RESTORED:  由于恢复到新索引导致未分配。
EXISTING_INDEX_RESTORED:  由于恢复到已关闭的索引导致未分配。
REPLICA_ADDED:  由于显式添加副本分片导致未分配。
ALLOCATION_FAILED:  由于分片分配失败导致未分配。
NODE_LEFT:  由于承载该分片的节点离开集群导致未分配。
REINITIALIZED:  由于当分片从开始移动到初始化时导致未分配(例如,使用影子shadow副本分片)。
REROUTE_CANCELLED:  作为显式取消重新路由命令的结果取消分配。
REALLOCATED_REPLICA:  确定更好的副本位置被标定使用,导致现有的副本分配被取消,出现未分配。

如何解决 unassigned 分片问题?

方案一:极端情况——这个分片数据已经不可用,直接删除该分片 (即删除索引)
Elasticsearch中没有直接删除分片的接口,除非整个节点数据已不再使用,删除节点。

[root@uni-dzkf-elk logs]# curl -s -XGET 'http://172.16.1.10:9200/_cat/indices?v' | grep ^red | awk '{print $3}' | xargs -I {} curl -XDELETE http://172.16.1.10:9200/{}

方案二:集群中节点数量 >= 集群中所有索引的最大副本数量 +1

N > = R + 1
其中:
N——集群中节点的数目;
R——集群中所有索引的最大副本数目。
注意事项:当节点加入和离开集群时,主节点会自动重新分配分片,以确保分片的多个副本不会分配给同一个节点。换句话说,主节点不会将主分片分配给与其副本相同的节点,也不会将同一分片的两个副本分配给同一个节点。 如果没有足够的节点相应地分配分片,则分片可能会处于未分配状态。

如果Elasticsearch集群就一个节点,即N=1;所以R=0,才能满足公式。这样问题就转嫁为:
1) 添加节点处理,即N增大;
2) 删除副本分片,即R置为0。
R置为0的方式,可以通过如下命令行实现:

[root@elk-test ~]# curl -XPUT "http://172.16.1.10:9200/_settings" -d' {  "number_of_replicas" : 0 } '
{"acknowledged":true}

方案三:allocate重新分配分片
如果方案二仍然未解决,可以考虑重新分配分片。可能的原因:
1) 节点在重新启动时可能遇到问题。正常情况下,当一个节点恢复与群集的连接时,它会将有关其分片的信息转发给主节点,然后主节点将这分片从“未分配”转换为 "已分配/已启动"。
2) 当由于某种原因 (例如节点的存储已被损坏) 导致该进程失败时,分片可能保持未分配状态。

在这种情况下,必须决定如何继续: 尝试让原始节点恢复并重新加入集群(并且不要强制分配主分片);  或者强制使用Reroute API分配分片并重新索引缺少的数据原始数据源或备份。 如果你决定分配未分配的主分片,请确保将"allow_primary":"true"标志添加到请求中。

Elasticsearch5.X使用脚本如下:

#!/bin/bash
NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s '10.0.8.47:9200/_cat/shards' | fgrep UNASSIGNED); do
  INDEX=$(echo $line | (awk '{print $1}'))
  SHARD=$(echo $line | (awk '{print $2}'))
 
  curl -XPOST '10.0.8.47:9200/_cluster/reroute' -d '{
     "commands": [
        {
            " allocate_replica ": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
          }
        }
    ]
  }'
done

Elasticsearch2.X及早期版本,只需将上面脚本中的allocate_replica改为 allocate,其他不变。

上面脚本解读:
步骤1:定位 UNASSIGNED 的节点和分片

curl -s '10.0.8.47:9200/_cat/shards' | fgrep UNASSIGNED

步骤2:通过 allocate_replica 将 UNASSIGNED的分片重新分配。

allocate分配原理
分配unassigned的分片到一个节点。将未分配的分片分配给节点。接受索引和分片的索引名称和分片号,以及将分片分配给它的节点。它还接受allow_primary标志来明确指定允许显式分配主分片(可能导致数据丢失)。

作者通过执行方案一和方案二后单机ES已恢复正常

[es@uni-dzkf-elk kibana-log]$  curl -X GET 'http://172.16.1.10:9200/_cluster/health?pretty'
{
  "cluster_name" : "CollectorDBCluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1915,
  "active_shards" : 1915,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "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" : 100.0
}
[es@uni-dzkf-elk kibana-log]$

  

ES问题可参考这个篇文章,写的非常详细:https://www.cnblogs.com/kevingrace/p/10671063.html

 

标签:副本,number,shards,Kibana,分配,报错,分片,NoShardAvailableActionException,节点
From: https://www.cnblogs.com/yizhipanghu/p/17502796.html

相关文章