unassigned_shards一直无法分配

 

在多次重启节点时,主副分片0出现了无法分配的问题。

elasticsearch 使用 Allocation IDs 的概念,这是区分不同分片的唯一标识(UUIDS)。

Allocation IDs存储在 shard 级元信息中,每个 shard 都有自己的Allocation ID,同时集群级元信息中记录了一个被认为是最新shard 的Allocation ID集合,这个集合称为 in-sync allocation IDs。
如果由于网络或者其他原因,主副shard没有同步,那么副本的shard会将被从in-sync allocation IDs踢出。

猜想可能是出现了上述的问题。

解决

使用下面的命令进行查看:

curl -XGET localhost:9200/_cluster/allocation/explain?pretty

explain API 告诉我们为什么主分片处于未分配状态,同时还提供了基于每个节点上的更详细的分配信息。主节点在集群当前可用节点中无法找到同步的(in-sync)分片副本。

{
  "index" : "my_index",
  "shard" : 0,
  "primary" : true,
  "current_state" : "unassigned",
  "unassigned_info" : {
    "reason" : "NODE_LEFT",
    "at" : "2017-01-26T09:20:24.054Z",
    "last_allocation_status" : "no_valid_shard_copy"
  },
  "can_allocate" : "no_valid_shard_copy",
  "allocate_explanation" : "cannot allocate because all found copies of the shard are either stale or corrupt",
  "node_allocation_decisions" : [
    {
      "node_id" : "0ZJS1ffpRg-E_5L0Q0NnDA",
      "node_name" : "data5-3",
      "transport_address" : "192.168.1.108:9303",
      "node_decision" : "no",
      "store" : {
          "found": false
      }
    },
     {
      "node_id" : "0ZJS1ffpRg-E_5L0Q0NnDA",
      "node_name" : "data5-3",
      "transport_address" : "192.168.1.108:9303",
      "node_decision" : "no",
      "store" : {
          "found": false
      }
    },
    .......
    .......
    {
      "node_id" : "JSofMo_0TSieKnfI4HmEcQ",
      "node_name" : "data6",
      "transport_address" : "192.168.1.109:9300",
      "node_decision" : "no",
      "store" : {
        "in_sync" : false,
        "allocation_id" : "J3gygIvYT06tKSW5rYkGtw"
      }
    }
  ]
}

cannot allocate because all found copies of the shard are either stale or corrupt
从上面的结果中,可以看到在data6节点上可用的分片副本是陈旧的( store.in_sync = false )。启动拥有in-sync 分片副本的那个节点将使集群重新变为 green。如果那个节点永远都回来了呢?

reroute API 提供了一个子命令 allocate_stale_primary ,用于将一个陈旧的分片分配为主分片。使用此命令意味着丢失给定分片副本中缺少的数据。如果同步分片只是暂时不可用,使用此命令意味着在同步副本中最近更新的数据。应该把它看作是使群集至少运行一些数据的最后一种措施。在所有分片副本都不存在的情况下,还可以强制Elasticsearch使用空分片副本分配主分片,这意味着丢失与该分片相关联的所有先前数据。 不言而喻,allocate_empty_primary 命令只能用于最糟糕的情况,其含义很好理解。

使用命令进行恢复:

POST _cluster/reroute?pretty
{
	"commands": [
		{
			"allocate_stale_primary": {
				"index": "my_index",
				"shard": 0,
				"node": "data6",
				"accept_data_loss": true
			}
		}
	]
}


ELK出现unassigned_shards解决办法

elk-cluster一直处于red状态
解决方法
一,查看elasticsearch有3个UNASSIGNED状态的索引
1
2
3
4
5
6
7
8
[root@192-168-x-x ~]# curl -XGET 'http://192.168.x.xx:9200/_cat/shards' |grep UNASSIGNED
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0etl211-online-2017.07.21                                               
xxx11-online-2017.07.21                     0 r UNASSIGNED                              
xx-master201-online-2017.07.18              1 p UNASSIGNED                              
xx-master201-online-2017.07.18              1 r UNASSIGNED                              
100  415k  100  415k    0     0   107k      0  0:00:03  0:00:03 --:--:--  107k
二,删除有问题的索引
1
2
3
4
[root@192-168-x-x ~]#  curl -XDELETE  http://192.168.x.x:9200/xx-master201-online-2017.07.18
{"acknowledged":true}
[root@192-168-x-x ~]#  curl -XDELETE  http://192.168.x.x:9200/xx211-online-2017.07.21
{"acknowledged":true}
三,查看elk-cluster已变为绿色
总结
关于unassigned shards的问题,一般遇到这种情况都是——重启试试, 因为可能是网络通信问题会影响分片分配
另外也可以看看日志,报了什么错,有遇到过硬盘了满了,具体问题具体分析
不行的话,只能强制删除。
一,查看elasticsearch有3个UNASSIGNED状态的索引
 
[root@192-168-x-x ~]# curl -XGET 'http://192.168.x.xx:9200/_cat/shards' |grep UNASSIGNED  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed  0     0    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0etl211-online-2017.07.21                                               xxx11-online-2017.07.21                     0 r UNASSIGNED                              xx-master201-online-2017.07.18              1 p UNASSIGNED                              xx-master201-online-2017.07.18              1 r UNASSIGNED                              100  415k  100  415k    0     0   107k      0  0:00:03  0:00:03 --:--:--  107k

二  删除有问题的索引

[root@192-168-x-x ~]#  curl -XDELETE  http://192.168.x.x:9200/xx-master201-online-2017.07.18
{"acknowledged":true}
[root@192-168-x-x ~]#  curl -XDELETE  http://192.168.x.x:9200/xx211-online-2017.07.21
{"acknowledged":true}
三,查看elk-cluster已变为绿色
总结
关于unassigned shards的问题,一般遇到这种情况都是——重启试试, 因为可能是网络通信问题会影响分片分配
另外也可以看看日志,报了什么错,有遇到过硬盘了满了,具体问题具体分析
不行的话,只能强制删除。
第一看集群状态:
1
curl -XGET 'http://localhost:9200/_cluster/health'
第二,看所有的shards:

curl -XGET 'http://localhost:9200/_cat/shards' | grep UNASSIGNED
第三,看unassignded shards:
1
curl -XGET 'http://localhost:9200/_cat/shards' | grep UNASSIGNED
 
 
 
重新索引
 
 POST /_reindex
  {
    "source": {
      "index": "alarm-2017.08.12"
    }
    , "dest": {
      "index": "alarm-2017.08.12.bak",
      "version_type": "external"
    }
  }

更好的教程https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/?spm=a2c6h.12873639.0.0.278c2acfJx6Ufk
 
原文地址:https://www.cnblogs.com/cheyunhua/p/14801054.html