处理elastic中参与分片（上）

一.简介

我们通过 GET _cat/allocation?v 可以查看每个节点分片的分配数量以及它们所使用的硬盘空间大小

发现其有51个shard是unassigned状态，再通过命令GET _cat/health?v：查看集群健康状态

可以看到其active_shards_percent为63.3%，原因就是其存在UNASSIGNED shards的情况，不过即使存在unassigned shard，也并不会影响es的使用的，只是部分数据所在的索引没法展示。

二.产生unassigned shards的原因

如果你只有一台机器，跑了es，但是你却在index中的settings中设置了replica为1，显然这个replica shard就会成为unassigned shards

如果是集群的话，可能是在集群重启过程中出现分片问题

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

三.如何解决

删除分片

1.首先精确定位unassigned shard的位置，每行列出索引的名称，分片编号，是主分片p还是副本分片r，以及其未分配的原因 curl -H "Content-Type: application/json" --user elastic:123456 -XGET 172.16.5.35:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason| grep UNASSIGNED

可以通过以下语句查看具体原因： GET _cluster/allocation/explain?pretty

2.对于没有再使用价值的index，直接删除掉 curl -H "Content-Type: application/json" --user elastic:123456 -XDELETE 172.16.5.35:9200/索引名