zhmg23

我们是如此的不同

Elasticsearch状态为red产生大量UNASSIGNED解决办法

昨天测试环境Elasticsearch集群状态突然为red了,原因是新起了一个集群,集群配置未及时调整,跟这个集群融入到一起,导致原集群状态产生大量UNASSIGNED。

1、简单的说一下Elasticsearch的三种状态:

green

所有的主分片和副本分片都已分配。你的集群是 100% 可用的。

yellow

所有的主分片已经分片了,但至少还有一个副本是缺失的。不会有数据丢失,所以搜索结果依然是完整的。不过,你的高可用性在某种程度上被弱化。如果 更多的 分片消失,你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。

red

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


2、简单过程回顾

Elasticsearch状态异常时,通过如下命令,查看一下

# curl -s 'localhost:8200/_cat/shards' | fgrep UNASSIGNED


注:第一列表示索引名,第二列表示分片编号,第三列p是主分片,r是副本

unassigned_shards 是已经在集群状态中存在的分片,但是实际在集群里又找不着。通常未分配分片的来源是未分配的副本。比如,一个有 5 分片和 1 副本的索引,在单节点集群上,就会有 5 个未分配副本分片。如果你的集群是 red 状态,也会长期保有未分配分片(因为缺少主分片)。


解决办法一:

手动删除这些(生产环境谨慎):

curl -XDELETE 'localhost:8200/user_re_3/'

curl -XDELETE 'localhost:8200/user_error_2/'



解决办法二:

重新分配索引

#!/bin/bash

range=2

IFS=$'\n'

for line in $(curl -s 'localhost:8200/_cat/shards' | fgrep UNASSIGNED); do

  INDEX=$(echo $line | (awk '{print $1}'))

  SHARD=$(echo $line | (awk '{print $2}'))

  number=$RANDOM

  let "number %= ${range}"


  curl -H "Content-Type: application/json" -XPOST https://localhost:8200/_cluster/reroute? -d '{

  "commands" : [ {

  "allocate_empty_primary" :

  {

    "index" : '\"${INDEX}\"',

    "shard" : '\"${SHARD}\"',

    "node" : "master_node",

    "accept_data_loss" : true

  }

}

]

}'

done


注:master_node为你的集群主节点



解决办法三:

新开启一个节点,此方案未验证,前面两个都已验证,一般推荐方案二

新启动一个节点,自动恢复后,在关闭


评论