blocks|key|2983275|text|好的，我已经在ES支持的帮助下解决了这个问题。在所有节点(或您认为是导致问题的节点)上向API下发以下命令：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983276|curl+-XPUT+'localhost:9200/<index>/_settings'+\
++++-d+'{"index.routing.allocation.disable_allocation":+false}'|code-block|syntax|javascript|2983277|其中，<index>是您认为是罪魁祸首的索引。如果您不知道，只需在所有节点上运行以下命令：|offset|length|style|CODE|2983278|curl+-XPUT+'localhost:9200/_settings'+\
++++-d+'{"index.routing.allocation.disable_allocation":+false}'|2983279|我还将这一行添加到我的yaml配置中，从那时起，服务器/服务的任何重新启动都没有问题。碎片会立即重新分配回来。|2983280|FWIW，为了回答一个经常被追问的问题，将MAX_HEAP_SIZE设置为30G，除非您的计算机的内存小于60G，在这种情况下，将其设置为可用内存的一半。|2983281|参考文献|2983282|2983283|Shard+Allocation+Awareness|unordered-list-item|2983284|2983285|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html^0|0|0|3|7|0|0|0|0|0|0|0|Q|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|18|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|19|8|@$I|1A|J|1B|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|1C|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1E|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1F|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|V|3|W|5|X|7|1H|8|@]|9|@$I|1I|J|1J|1|1K]]|A|$]]|$1|Y|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]]]

OK, I've solved this with some help from ES support. Issue the following command to the API on all nodes (or the nodes you believe to be the cause of the problem):

<pre><code>curl -XPUT 'localhost:9200/&lt;index&gt;/_settings' \
 -d '{"index.routing.allocation.disable_allocation": false}'
</code></pre>

where <code>&lt;index&gt;</code> is the index you believe to be the culprit. If you have no idea, just run this on all nodes:

<pre><code>curl -XPUT 'localhost:9200/_settings' \
 -d '{"index.routing.allocation.disable_allocation": false}'
</code></pre>

I also added this line to my yaml config and since then, any restarts of the server/service have been problem free. The shards re-allocated back immediately.

FWIW, to answer an oft sought after question, set MAX_HEAP_SIZE to 30G unless your machine has less than 60G RAM, in which case set it to half the available memory.

<h3>References</h3>

<ul>
<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html" rel="noreferrer">Shard Allocation Awareness</a></li>
</ul>

blocks|key|2770291|text|默认情况下，Elasticsearch会动态地为节点重新分配分片。但是，如果您已经关闭了分片分配(可能您做了一个rolling+restart，但忘记重新启用)，您可以重新启用分片分配。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2770292|#+v0.90.x+and+earlier
curl+-XPUT+'localhost:9200/_settings'+-d+'{
++++"index.routing.allocation.disable_allocation":+false
}'

#+v1.0%2B
curl+-XPUT+'localhost:9200/_cluster/settings'+-d+'{
++++"transient"+:+{
++++++++"cluster.routing.allocation.enable"+:+"all"
++++}
}'|code-block|syntax|javascript|2770293|然后Elasticsearch会像往常一样重新分配分片。这可能会很慢，可以考虑提高indices.recovery.max_bytes_per_sec和cluster.routing.allocation.node_concurrent_recoveries来加快速度。|style|CODE|2770294|如果您仍然看到问题，可能是其他问题，所以在您的Elasticsearch日志中查找错误。如果你看到EsRejectedExecutionException，你的线程池may+be+too+small。|2770295|最后，您可以显式地将分片重新分配给具有reroute+API的节点。|2770296|#+Suppose+shard+4+of+index+"my-index"+is+unassigned,+so+you+want+to
#+assign+it+to+node+search03:
curl+-XPOST+'localhost:9200/_cluster/reroute'+-d+'{
++++"commands":+[{
++++++++"allocate":+{
++++++++++++"index":+"my-index",
++++++++++++"shard":+4,
++++++++++++"node":+"search03",
++++++++++++"allow_primary":+1
++++++++}
++++}]
}'|2770297|entityMap|0|LINK|mutability|MUTABLE|url|http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-nodes-shutdown.html#_rolling_restart_of_nodes_full_cluster_restart|1|http://jontai.me/blog/2013/06/esrejectedexecutionexception-rejected-execution-of-messagechannelhandler-requesthandler/|2|http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-reroute.html^0|1K|F|0|0|0|15|Y|24|1H|0|1D|S|2B|G|1|0|J|B|2|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|F|7|18|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|19|8|@$A|1A|B|1B|K|L]|$A|1C|B|1D|K|L]]|9|@]|C|$]]|$1|M|3|N|5|6|7|1E|8|@$A|1F|B|1G|K|L]]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|O|3|P|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|Q|3|R|5|F|7|1O|8|@]|9|@]|C|$G|H]]|$1|S|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]|10|$5|V|W|X|C|$Y|11]]|12|$5|V|W|X|C|$Y|13]]]]

By default, Elasticsearch will re-assign shards to nodes dynamically. However, if you've disabled shard allocation (perhaps you did a <a href="http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-nodes-shutdown.html#_rolling_restart_of_nodes_full_cluster_restart" rel="noreferrer">rolling restart</a> and forgot to re-enable it), you can re-enable shard allocation.

<pre class="lang-bash prettyprint-override"><code># v0.90.x and earlier
curl -XPUT 'localhost:9200/_settings' -d '{
 "index.routing.allocation.disable_allocation": false
}'

# v1.0+
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
 "transient" : {
 "cluster.routing.allocation.enable" : "all"
 }
}'
</code></pre>

Elasticsearch will then reassign shards as normal. This can be slow, consider raising <code>indices.recovery.max_bytes_per_sec</code> and <code>cluster.routing.allocation.node_concurrent_recoveries</code> to speed it up.

If you're still seeing issues, something else is probably wrong, so look in your Elasticsearch logs for errors. If you see <code>EsRejectedExecutionException</code> your thread pools <a href="http://jontai.me/blog/2013/06/esrejectedexecutionexception-rejected-execution-of-messagechannelhandler-requesthandler/" rel="noreferrer">may be too small</a>.

Finally, you can explicitly reassign a shard to a node with the <a href="http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-reroute.html" rel="noreferrer">reroute API</a>.

<pre class="lang-bash prettyprint-override"><code># Suppose shard 4 of index "my-index" is unassigned, so you want to
# assign it to node search03:
curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
 "commands": [{
 "allocate": {
 "index": "my-index",
 "shard": 4,
 "node": "search03",
 "allow_primary": 1
 }
 }]
}'
</code></pre>

blocks|key|2983339|text|我也遇到了这种情况，并最终解决了它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983340|首先，我会描述一下我的情况。我在ElasticSearch集群中有两个节点，它们可以找到彼此，但当我创建一个索引时，设置为"number_of_replicas“：2，"number_of_shards”：5，ES显示黄色信号，unassigned_shards为5。|offset|length|style|BOLD|2983341|出现这个问题是因为当我用1设置它的值时，number_of_replicas，的值是正常的。|2983342|entityMap^0|0|1P|M|0|C|1|K|I|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|K|$]]

I also meet this situation and finally fixed it.

Firstly, I will describe my situation. I have two nodes in ElasticSearch cluster, they can find each other, but when I created a index with settings "number_of_replicas" : 2, "number_of_shards" : 5, ES show yellow signal and unassigned_shards is 5.

The problem occurs because the value of number_of_replicas, when I set its value with 1, all is fine.

blocks|key|2770334|text|这个小bash脚本将暴力重新分配，你可能会丢失数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2770335|NODE="YOUR+NODE+NAME"
IFS=$'\n'
for+line+in+$(curl+-s+'localhost:9200/_cat/shards'+%7C+fgrep+UNASSIGNED);+do
++INDEX=$(echo+$line+%7C+(awk+'{print+$1}'))
++SHARD=$(echo+$line+%7C+(awk+'{print+$2}'))

++curl+-XPOST+'localhost:9200/_cluster/reroute'+-d+'{
+++++"commands":+[
++++++++{
++++++++++++"allocate":+{
++++++++++++++++"index":+"'$INDEX'",
++++++++++++++++"shard":+'$SHARD',
++++++++++++++++"node":+"'$NODE'",
++++++++++++++++"allow_primary":+true
++++++++++}
++++++++}
++++]
++}'
done|code-block|syntax|javascript|2770336|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

This little bash script will brute force reassign, you may lose data.

<pre><code>NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED); do
 INDEX=$(echo $line | (awk '{print $1}'))
 SHARD=$(echo $line | (awk '{print $2}'))

 curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
 "commands": [
 {
 "allocate": {
 "index": "'$INDEX'",
 "shard": '$SHARD',
 "node": "'$NODE'",
 "allow_primary": true
 }
 }
 ]
 }'
done
</code></pre>

blocks|key|2983419|text|我也有同样的问题，但根本原因是版本号不同(两个节点上的1.4.2(有问题)和两个节点上的1.4.4+(ok))。第一个和第二个答案(将"index.routing.allocation.disable_allocation“设置为false，将"cluster.routing.allocation.enable”设置为"all")不起作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983420|然而，@Wilfred+Hughes+(使用瞬态将"cluster.routing.allocation.enable“设置为"all”)的回答给了我一个错误，如下所示：|2983421|2983422|+[NO(目标节点版本1.4.2早于源节点版本1.4.4)]|blockquote|2983423|2983424|2983425|在将旧节点更新到1.4.4之后，这些节点开始与其他良好节点重新连接。|2983426|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Q|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|M|$]]

I had the same problem but the root cause was a difference in version numbers (1.4.2 on two nodes (with problems) and 1.4.4 on two nodes (ok)). The first and second answers (setting "index.routing.allocation.disable_allocation" to false and setting "cluster.routing.allocation.enable" to "all") did not work. 

However, the answer by @Wilfred Hughes (setting "cluster.routing.allocation.enable" to "all" using transient) gave me an error with the following statement:

<blockquote>
 [NO(target node version [1.4.2] is older than source node version
 [1.4.4])]
</blockquote>

After updating the old nodes to 1.4.4 these nodes started to resnc with the other good nodes.

blocks|key|2770375|text|也许它对某些人有帮助，但我也有同样的问题，这是由于日志变得太大而导致的存储空间不足。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2770376|希望对某些人有帮助！:)|2770377|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Maybe it helps someone, but I had the same issue and it was due to a lack of storage space caused by a log getting way too big.

Hope it helps someone! :)

blocks|key|168561|text|对我来说唯一有效的事情是改变number_of_replicas+(我有2个副本，所以我把它改成了1，然后又改回了2)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|168562|首先：|168563|PUT+/myindex/_settings
{
++++"index"+:+{
++++++++"number_of_replicas"+:+1
+++++}
}|code-block|syntax|javascript|168564|然后：|168565|PUT+/myindex/_settings
{
++++"index"+:+{
++++++++"number_of_replicas"+:+2
+++++}
}|168566|(我已经在this+question中查询过了)|offset|length|168567|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/23656458/elasticsearch-what-to-do-with-unassigned-shards/29589057#29589057^0|0|0|0|0|0|5|D|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|13|8|@]|9|@$O|14|P|15|1|16]]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

The only thing that worked for me was changing the number_of_replicas (I had 2 replicas, so I changed it to 1 and then changed back to 2).

First:

<pre><code>PUT /myindex/_settings
{
 "index" : {
 "number_of_replicas" : 1
 }
}
</code></pre>

Then:

<pre><code>PUT /myindex/_settings
{
 "index" : {
 "number_of_replicas" : 2
 }
}
</code></pre>

(I Already asnwered it in <a href="https://stackoverflow.com/questions/23656458/elasticsearch-what-to-do-with-unassigned-shards/29589057#29589057">this question</a>)

blocks|key|170632|text|可能会有帮助，但我在嵌入式模式下运行ES时遇到了这个问题。修复方法是确保Node设置了local(true)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|170633|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Might help, but I had this issue when trying to run ES in embedded mode. Fix was to make sure the Node had local(true) set.

blocks|key|169708|text|在我的示例中，一个具有旧共享的旧节点正在加入集群，因此我们必须关闭旧节点，并删除具有未分配分片的索引。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169709|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case an old node with old shares was joining the cluster, so we had to shutdown the old node and delete the indices with unassigned shards.

blocks|key|2983637|text|未分配分片的另一个可能原因是您的集群正在运行多个版本的Elasticsearch二进制文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983638|从较新版本到以前版本的|2983639|分片复制将不起作用|blockquote|2983640|2983641|2983642|这可能是未分配分片的根本原因。|2983643|Elastic+Documentation+-+Rolling+Upgrade+Process|offset|length|2983644|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades^0|0|0|0|0|0|0|0|1B|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@$M|13|N|14|1|15]]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

Another possible reason for unassigned shards is that your cluster is running more than one version of the Elasticsearch binary.

<blockquote>
 shard replication from the more recent version to the previous
 versions will not work
</blockquote>

This can be a root cause for unassigned shards. 

<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades" rel="nofollow">Elastic Documentation - Rolling Upgrade Process</a>

blocks|key|2983675|text|我遇到了完全相同的问题。这可以通过在重新启动elasticsearch之前将分片分配临时设置为false来防止，但如果未分配的分片已经存在，这并不会修复它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983676|在我的例子中，它是由数据节点上的空闲磁盘空间不足引起的。未分配的分片在重启后仍在数据节点上，但它们不被主节点识别。|2983677|只需清除磁盘中的1个节点，就可以为我启动复制过程。这是一个相当慢的过程，因为所有数据都必须从一个数据节点复制到另一个数据节点。|2983678|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I ran into exactly the same issue. This can be prevented by temporarily setting the shard allocation to false before restarting elasticsearch, but this does not fix the unassigned shards if they are already there.

In my case it was caused by lack of free disk space on the data node. The unassigned shards where still on the data node after the restart but they where not recognized by the master. 

Just cleaning 1 of the nodes from the disk got the replication process started for me. This is a rather slow process because all the data has to be copied from 1 data node to the other.

blocks|key|2770595|text|在我的示例中，当我创建一个新的索引时，默认的number_of_replicas设置为1。并且我的集群中的节点数只有一个，因此没有额外的节点来创建副本，因此运行状况变为黄色。因此，当我使用设置创建索引时，设置属性并将number_of_replicas设置为0。然后它工作得很好。希望这能有所帮助。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2770596|PUT+/customer
{
++++"settings":+{
++++++++"number_of_replicas":+0
++++}
}|code-block|syntax|javascript|2770597|entityMap^0|F|2|M|I|2M|A|30|I|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|L|$]]

In my case, when I create a new index then the default number_of_replicas is set as 1. And the number of nodes in my cluster was only one so there was no extra node to create the replica, so the health was turning to yellow. 
So when I created the index with settings property and set the number_of_replicas as 0. Then it worked fine. Hope this helps.

<pre><code>PUT /customer
{
 "settings": {
 "number_of_replicas": 0
 }
}
</code></pre>

blocks|key|2770712|text|我今天坚持使用同样的分片分配问题。W.+Andrew+Loe+III在他的回答中提出的脚本对我不起作用，所以我对它做了一些修改，最终它起作用了：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2770713|#!/usr/bin/env+bash

#+The+script+performs+force+relocation+of+all+unassigned+shards,+
#+of+all+indices+to+a+specified+node+(NODE+variable)

ES_HOST="<elasticsearch+host>"
NODE="<node+name>"

curl+${ES_HOST}:9200/_cat/shards+>+shards
grep+"UNASSIGNED"+shards+>+unassigned_shards

while+read+LINE;+do
++IFS="+"+read+-r+-a+ARRAY+<<<+"$LINE"
++INDEX=${ARRAY[0]}
++SHARD=${ARRAY[1]}

++echo+"Relocating:"
++echo+"Index:+${INDEX}"
++echo+"Shard:+${SHARD}"
++echo+"To+node:+${NODE}"

++curl+-s+-XPOST+"${ES_HOST}:9200/_cluster/reroute"+-d+"{
++++\"commands\":+[
+++++++{
+++++++++\"allocate\":+{
+++++++++++\"index\":+\"${INDEX}\",
+++++++++++\"shard\":+${SHARD},
+++++++++++\"node\":+\"${NODE}\",
+++++++++++\"allow_primary\":+true
+++++++++}
+++++++}
+++++]
++}";+echo
++echo+"------------------------------"
done+<unassigned_shards

rm+shards
rm+unassigned_shards

exit+0|code-block|syntax|javascript|2770714|现在，我不是一个Bash专家，但是这个脚本真的很适合我的情况。注意，您需要为"ES_HOST“和"NODE”变量指定适当的值。|2770715|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/544065/w-andrew-loe-iii^0|H|H|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

I've stuck today with the same issue of shards allocation. The script that
<a href="https://stackoverflow.com/users/544065/w-andrew-loe-iii">W. Andrew Loe III</a> has proposed in his answer didn't work for me, so I modified it a little and it finally worked:

<pre><code>#!/usr/bin/env bash

# The script performs force relocation of all unassigned shards, 
# of all indices to a specified node (NODE variable)

ES_HOST="&lt;elasticsearch host&gt;"
NODE="&lt;node name&gt;"

curl ${ES_HOST}:9200/_cat/shards &gt; shards
grep "UNASSIGNED" shards &gt; unassigned_shards

while read LINE; do
 IFS=" " read -r -a ARRAY &lt;&lt;&lt; "$LINE"
 INDEX=${ARRAY[0]}
 SHARD=${ARRAY[1]}

 echo "Relocating:"
 echo "Index: ${INDEX}"
 echo "Shard: ${SHARD}"
 echo "To node: ${NODE}"

 curl -s -XPOST "${ES_HOST}:9200/_cluster/reroute" -d "{
 \"commands\": [
 {
 \"allocate\": {
 \"index\": \"${INDEX}\",
 \"shard\": ${SHARD},
 \"node\": \"${NODE}\",
 \"allow_primary\": true
 }
 }
 ]
 }"; echo
 echo "------------------------------"
done &lt;unassigned_shards

rm shards
rm unassigned_shards

exit 0
</code></pre>

Now, I'm not kind of a Bash guru, but the script really worked for my case. Note, that you'll need to specify appropriate values for "ES_HOST" and "NODE" variables.

blocks|key|2983860|text|我也遇到了这个问题，我找到了一个简单的方法来解决它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983861|2983862|获取未分配分片的索引|unordered-list-item|2983863|2983864|$+curl+-XGET+http://172.16.4.140:9200/_cat/shards|offset|length|2983865|Install+curator工具，并使用它删除索引|2983866|2983867|$+curator+--host+172.16.4.140删除索引--旧于1\--时间字符串'%25Y.%25m.%25d‘--时间单位天--前缀logstash|2983868|2016-04-21|2983869|Then注意:在我的例子中，索引是+of+the+day+再次检查分片，所有未分配的分片都会消失！|style|BOLD|2983870|2983871|entityMap|0|LINK|mutability|MUTABLE|url|http://172.16.4.140:9200//_cat/shards^0|0|0|0|0|D|10|0|0|0|0|0|0|H|C|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|16|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|18|8|@]|9|@$I|19|J|1A|1|1B]]|A|$]]|$1|K|3|L|5|E|7|1C|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1F|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1G|8|@$I|1H|J|1I|T|U]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

I was having this issue as well, and I found an easy way to resolve it.

<ul>
<li>Get the index of unassigned shards

<pre><code>$ curl -XGET http://172.16.4.140:9200/_cat/shards
</code></pre></li>
<li>Install curator Tools, and use it to delete index

<pre><code>$ curator --host 172.16.4.140 delete indices --older-than 1 \
 --timestring '%Y.%m.%d' --time-unit days --prefix logstash
</code></pre>

NOTE: In my case, the index is logstash of the day 2016-04-21</li>
<li>Then check the shards again, all the unassigned shards go away!</li>
</ul>

blocks|key|172377|text|我尝试了上面的几个建议，不幸的是它们都不起作用。我们在较低的环境中有一个"Log“索引，在那里应用程序会写入它们的错误。它是一个单节点集群。对我来说，解决这个问题的方法是检查节点的YML配置文件，发现它仍然具有默认设置"gateway.expected_nodes:+2“。这覆盖了我们拥有的任何其他设置。每当我们在这个节点上创建索引时，它都会尝试将5个分片中的3个扩展到幻影的第2个节点。因此，这些节点将显示为未分配，并且它们永远不会移动到第一个也是唯一的节点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|172378|解决方案是编辑配置，将设置"gateway.expected_nodes“更改为1，这样它就会停止在集群中寻找它永远找不到的兄弟，并重新启动弹性服务实例。此外，我必须删除索引，并创建一个新的索引。创建索引后，所有分片都显示在第一个也是唯一的节点上，并且没有一个是未分配的。|172379|#+Set+how+many+nodes+are+expected+in+this+cluster.+Once+these+N+nodes
#+are+up+(and+recover_after_nodes+is+met),+begin+recovery+process+immediately
#+(without+waiting+for+recover_after_time+to+expire):
#
#+gateway.expected_nodes:+2
gateway.expected_nodes:+1|code-block|syntax|javascript|172380|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I tried several of the suggestions above and unfortunately none of them worked. We have a "Log" index in our lower environment where apps write their errors. It is a single node cluster. What solved it for me was checking the YML configuration file for the node and seeing that it still had the default setting "gateway.expected_nodes: 2". This was overriding any other settings we had. Whenever we would create an index on this node it would try to spread 3 out of 5 shards to the phantom 2nd node. These would therefore appear as unassigned and they could never be moved to the 1st and only node.

The solution was editing the config, changing the setting "gateway.expected_nodes" to 1, so it would quit looking for its never-to-be-found brother in the cluster, and restarting the Elastic service instance. Also, I had to delete the index, and create a new one. After creating the index, the shards all showed up on the 1st and only node, and none were unassigned.

<pre><code># Set how many nodes are expected in this cluster. Once these N nodes
# are up (and recover_after_nodes is met), begin recovery process immediately
# (without waiting for recover_after_time to expire):
#
# gateway.expected_nodes: 2
gateway.expected_nodes: 1
</code></pre>

blocks|key|170825|text|在我的例子中，达到了硬盘空间的上限。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|170826|看看这篇文章：https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html|offset|length|170827|基本上，我运行：|170828|PUT+/_cluster/settings
{
++"transient":+{
++++"cluster.routing.allocation.disk.watermark.low":+"90%25",
++++"cluster.routing.allocation.disk.watermark.high":+"95%25",
++++"cluster.info.update.interval":+"1m"
++}
}|code-block|syntax|javascript|170829|因此，如果硬盘空间使用率小于90%25，则会进行分配；如果硬盘空间使用率>95%25，则会将分片移动到集群中的另一台机器上；并且每1分钟检查一次。|170830|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html^0|0|7|2B|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

In my case, the hard disk space upper bound was reached.

Look at this article: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html" rel="noreferrer">https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html</a>

Basically, I ran:

<pre><code>PUT /_cluster/settings
{
 "transient": {
 "cluster.routing.allocation.disk.watermark.low": "90%",
 "cluster.routing.allocation.disk.watermark.high": "95%",
 "cluster.info.update.interval": "1m"
 }
}
</code></pre>

So that it will allocate if &lt;90% hard disk space used, and move a shard to another machine in the cluster if >95% hard disk space used; and it checks every 1 minute.

blocks|key|172397|text|我尝试删除未分配的分片或手动将它们分配给特定的数据节点。它不起作用，因为未分配的碎片不断出现，并且健康状态一遍又一遍地为“红色”。然后，我注意到其中一个数据节点处于“重新启动”状态。我减少了数据节点的数量，杀死了它。问题不再可重现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|172398|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I tried to delete unassigned shards or manually assign them to particular data node. It didn't work because unassigned shards kept appearing and health status was "red" over and over.
Then I noticed that one of the data nodes stuck in "restart" state. I reduce number of data nodes, killed it. Problem is not reproducible anymore.

blocks|key|2770863|text|如果下面的配置设置为all，Elasticsearch会自动分配分片。可以使用rest+api+as+well+cluster.routing.allocation.enable:+all来设置此配置|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2770864|如果在应用以下配置后，es无法自动分配分片，则您必须自己强制分配分片。ES+official+link+for+this|2770865|我已经写了一个脚本来强制分配集群中所有未分配的分片。|2770866|下面的数组包含要在其中平衡未分配的分片的节点列表|2770867|#!/bin/bash
array=(+node1+node2+node3+)
node_counter=0
length=${#array[@]}
IFS=$'\n'
for+line+in+$(curl+-s+'http://127.0.0.1:9200/_cat/shards'%7C++fgrep+UNASSIGNED);+do
++++INDEX=$(echo+$line+%7C+(awk+'{print+$1}'))
++++SHARD=$(echo+$line+%7C+(awk+'{print+$2}'))
++++NODE=${array[$node_counter]}
++++echo+$NODE
++++curl+-XPOST+'http://127.0.0.1:9200/_cluster/reroute'+-d+'{
++++++++"commands":+[
++++++++{
++++++++++++"allocate":+{
++++++++++++++++"index":+"'$INDEX'",
++++++++++++++++"shard":+'$SHARD',
++++++++++++++++"node":+"'$NODE'",
++++++++++++++++"allow_primary":+true
++++++++++++}
++++++++}
++++++++]
++++}'
++++node_counter=$(((node_counter)%25length+%2B1))
done|code-block|syntax|javascript|2770868|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/1.4/cluster-update-settings.html|1|https://www.elastic.co/guide/en/elasticsearch/reference/2.1/cluster-reroute.html^0|1K|12|13|G|0|0|Z|P|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@$9|13|A|14|1|15]]|E|$]]|$1|F|3|G|5|6|7|16|8|@]|D|@$9|17|A|18|1|19]]|E|$]]|$1|H|3|I|5|6|7|1A|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1B|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1C|8|@]|D|@]|E|$O|P]]|$1|Q|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]|Y|$5|T|U|V|E|$W|Z]]]]

Elasticsearch automatically allocates shards if the below config is set to all. This config can be set using a <a href="https://www.elastic.co/guide/en/elasticsearch/reference/1.4/cluster-update-settings.html" rel="noreferrer">rest api as well</a> 
cluster.routing.allocation.enable: all

If even after application of the below config, es fails to assign the shards automatically, then you have to force assign the shards yourself. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/2.1/cluster-reroute.html" rel="noreferrer">ES official link for this</a> 

I have written a script to force assign all unassigned shards across cluster.

below array contains list of nodes among which you want to balance the unassigned shards

<pre><code>#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=${#array[@]}
IFS=$'\n'
for line in $(curl -s 'http://127.0.0.1:9200/_cat/shards'| fgrep UNASSIGNED); do
 INDEX=$(echo $line | (awk '{print $1}'))
 SHARD=$(echo $line | (awk '{print $2}'))
 NODE=${array[$node_counter]}
 echo $NODE
 curl -XPOST 'http://127.0.0.1:9200/_cluster/reroute' -d '{
 "commands": [
 {
 "allocate": {
 "index": "'$INDEX'",
 "shard": '$SHARD',
 "node": "'$NODE'",
 "allow_primary": true
 }
 }
 ]
 }'
 node_counter=$(((node_counter)%length +1))
done
</code></pre>

blocks|key|169920|text|对我来说，这是通过从开发控制台运行以下命令来解决的："POST+/_cluster/reroute?retry_failed“|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169921|.|169922|我首先查看索引列表，查看哪些索引是红色的，然后运行|169923|get/_cat/shards?H=索引名称、shard、prirep、state、unassigned.reason|169924|并看到它的分片卡在ALLOCATION_FAILED状态，所以运行上面的重试会导致它们重试分配。|169925|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

For me, this was resolved by running this from the dev console: "POST /_cluster/reroute?retry_failed"

.....

I started by looking at the index list to see which indices were red and then ran 

"get /_cat/shards?h=[INDEXNAME],shard,prirep,state,unassigned.reason"

and saw that it had shards stuck in ALLOCATION_FAILED state, so running the retry above caused them to re-try the allocation.

blocks|key|2770914|text|我只是首先增加了|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2770915|2770916|+"index.number_of_replicas“|blockquote|2770917|2770918|2770919|减1(等待节点同步)，然后减1，这有效地删除了未分配的分片，集群再次变为绿色，而不会有丢失任何数据的风险。|2770920|我相信有更好的方法，但这对我来说更容易。|2770921|希望这能有所帮助。|2770922|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|R|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|O|$]]

I just first increased the 

<blockquote>
 "index.number_of_replicas" 
</blockquote>

by 1 (wait until nodes are synced) then decreased it by 1 afterwards, which effectively removes the unassigned shards and cluster is Green again without the risk of losing any data. 

I believe there are better ways but this is easier for me.

Hope this helps.

blocks|key|2984097|text|在处理损坏的分片时，您可以将复制因子设置为0，然后将其设置回原始值。这应该会清除大部分损坏的碎片，并重新定位集群中的新副本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2984098|将具有未分配副本的索引设置为使用复制因子0：|2984099|curl+-XGET+http://localhost:9200/_cat/shards+%7C\
++grep+UNASSIGNED+%7C+grep+'+r+'+%7C\
++awk+'{print+$1}'+%7C\
++xargs+-I+{}+curl+-XPUT+http://localhost:9200/{}/_settings+-H+"Content-Type:+application/json"+\
++-d+'{+"index":{+"number_of_replicas":+0}}'|code-block|syntax|javascript|2984100|将它们设置回1：|2984101|curl+-XGET+http://localhost:9200/_cat/shards+%7C\
++awk+'{print+$1}'+%7C\
++xargs+-I+{}+curl+-XPUT+http://localhost:9200/{}/_settings+-H+"Content-Type:+application/json"+\
++-d+'{+"index":{+"number_of_replicas":+1}}'|2984102|注意:如果您对不同的索引有不同的复制因子，则不会运行此命令。这将把所有索引的复制因子硬编码为1。|offset|length|style|BOLD|2984103|entityMap^0|0|0|0|0|0|0|M|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

When dealing with corrupted shards you can set the replication factor to 0 and then set it back to the original value. This should clear up most if not all your corrupted shards and relocate the new replicas in the cluster.

Setting indexes with unassigned replicas to use a replication factor of 0:

<pre><code>curl -XGET http://localhost:9200/_cat/shards |\
 grep UNASSIGNED | grep ' r ' |\
 awk '{print $1}' |\
 xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
 -d '{ "index":{ "number_of_replicas": 0}}'
</code></pre>

Setting them back to 1:

<pre><code>curl -XGET http://localhost:9200/_cat/shards |\
 awk '{print $1}' |\
 xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
 -d '{ "index":{ "number_of_replicas": 1}}'
</code></pre>

Note: Do not run this if you have different replication factors for different indexes. This would hardcode the replication factor for all indexes to 1.

blocks|key|2984134|text|这也可能是磁盘空间的一个原因，在Elasticsearch+7.5.2中，默认情况下，如果磁盘使用率高于85%25，则不会将副本碎片分配给任何其他节点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2984135|可以通过设置不同的阈值或在.yml中或通过Kibana禁用它来解决此问题|2984136|PUT+_cluster/settings
{
++"persistent":+{
++++"cluster.routing.allocation.disk.threshold_enabled":+"false"
++}
}|code-block|syntax|javascript|2984137|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

This may be a cause of the disk space as well,
In Elasticsearch 7.5.2, by default, if disk usage is above 85% then replica shards are not assigned to any other node.
This can be fixed by setting a different threshold or by disabling it either in the .yml or via Kibana
<pre><code>PUT _cluster/settings
{
 &quot;persistent&quot;: {
 &quot;cluster.routing.allocation.disk.threshold_enabled&quot;: &quot;false&quot;
 }
}
</code></pre>

blocks|key|169986|text|我也遇到了类似的错误。这发生在我身上，因为我的一个数据节点已满，因此分片分配失败。如果有未分配的分片，你的集群是红色的，很少有索引也是红色的，在这种情况下，我遵循了下面的步骤，这些步骤就像冠军一样工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169987|在kibana+dev工具中-|169988|GET+_cluster/allocation/explain|code-block|syntax|javascript|169989|如果有任何未分配的分片，那么您将获得详细信息，否则将抛出错误。|169990|只需运行下面的命令就可以解决所有问题-|169991|POST+_cluster/reroute?retry_failed|169992|多亏了-，|169993|https://github.com/elastic/elasticsearch/issues/23199#issuecomment-280272888|offset|length|style|BOLD|169994|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|24|0|24|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|15|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|16|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1A|8|@$S|1B|T|1C|U|V]]|9|@$S|1D|T|1E|1|1F]]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|R]]]]

I also encountered similar error. It happened to me because one of my data node was full and due to which shards allocation failed. If unassigned shards are there and your cluster is RED and few indices also RED, in that case I have followed below steps and these worked like a champ. 
in kibana dev tool-
<pre><code>GET _cluster/allocation/explain
</code></pre>
If any unassigned shards are there then you will get details else will throw ERROR.
simply running below command will solve everything-
<pre><code>POST _cluster/reroute?retry_failed
</code></pre>
Thanks to - 
<a href="https://github.com/elastic/elasticsearch/issues/23199#issuecomment-280272888" rel="noreferrer">https://github.com/elastic/elasticsearch/issues/23199#issuecomment-280272888</a>

blocks|key|2771111|text|首先使用cluster+health+API获取集群的当前健康状况，其中红色表示缺少一个或多个主分片，黄色表示缺少一个或多个副本分片。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2771112|在此之后，使用cluster+allocation+explain+API来了解为什么某个特定的分片丢失，并且elasticsearch无法在数据节点上分配它。|2771113|一旦你找到了确切的根本原因，尝试解决这个问题，这通常需要更改一些集群设置(在@wilfred+answer+earlier中提到)，但在某些情况下，如果它的副本碎片，并且您有相同碎片的另一个副本(即另一个副本)可用，您可以使用update+replica+setting减少副本数量，稍后如果您需要的话，再次增加它。|2771114|除此之外，如果你的集群分配接口提到它没有有效的数据节点来分配分片，那么你需要添加一个新的数据节点，或者更改shard+allocation+awareness+settings。|2771115|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html|1|https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html|2|https://stackoverflow.com/a/23781013/4039431|3|https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html|4|https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-cluster.html#modules-cluster^0|4|I|0|0|7|U|1|0|1I|7|2|35|M|3|0|1H|Z|4|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]|$A|1B|B|1C|1|1D]]|C|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|J|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]|V|$5|M|N|O|C|$P|W]]|X|$5|M|N|O|C|$P|Y]]]]

First use <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html" rel="nofollow noreferrer">cluster health API</a> to get the current health of cluster, where RED means one or more primary shards missing and Yellow means one of more replica shards are missing.
After this use the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html" rel="nofollow noreferrer">cluster allocation explain API</a> to know why a particular shard is missing and elasticsearch is not able to allocate it on data-node.
Once you get the exact root cause, try to address the issue, which often requires, changing few cluster settings(mentioned in @wilfred answer <a href="https://stackoverflow.com/a/23781013/4039431">earlier</a>) But in some cases, if its replica shards, and you have another copy of same shard(i.e. another replica) available, you can reduce the replica count using <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html" rel="nofollow noreferrer">update replica setting</a> and later on again increase it, if you need it.
Apart from above, if your cluster allocation API mention it doesn't have a valid data nodes to allocate a shard, than you need to add a new data nodes, or change the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-cluster.html#modules-cluster" rel="nofollow noreferrer">shard allocation awareness settings</a>.

blocks|key|2771180|text|如果您有未分配的分片，通常第一步是调用allocation+explain+API并查找原因。根据原因，你会对此做些什么。以下是我脑海中浮现的一些想法：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2771181|2771182|节点磁盘空间不足(请检查disk-based+allocation设置)|unordered-list-item|2771183|节点无法分配分片，原因包括allocation+is+disabled、allocation+filtering或awareness等限制(例如节点位于集群的错误一侧，如其他可用区、热节点或热节点)|2771184|加载分片时出错。例如，文件的校验和失败，analyzer|2771185|引用的同义词文件缺失|2771186|有时它有助于临时启动它，比如使用Cluster+Reroute+API手动分配分片，或者禁用并重新启用副本。|2771187|如果你需要更多关于操作Elasticsearch的信息，请查看Sematext的Elasticsearch+Operations+training+(免责声明:我正在交付它)。|2771188|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html|1|https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation|2|https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#cluster-shard-allocation-settings|3|https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html|4|https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#shard-allocation-awareness|5|https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html|6|https://sematext.com/training/elasticsearch/elasticsearch-operations/^0|J|M|0|0|0|C|L|1|0|D|M|2|10|K|3|1L|9|4|0|0|0|G|J|5|0|14|X|6|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|D|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1G|8|@]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|H|3|I|5|G|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]|$A|1O|B|1P|1|1Q]|$A|1R|B|1S|1|1T]]|C|$]]|$1|J|3|K|5|G|7|1U|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1V|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1W|8|@]|9|@$A|1X|B|1Y|1|1Z]]|C|$]]|$1|P|3|Q|5|6|7|20|8|@]|9|@$A|21|B|22|1|23]]|C|$]]|$1|R|3|-4|5|6|7|24|8|@]|9|@]|C|$]]]|S|$T|$5|U|V|W|C|$X|Y]]|Z|$5|U|V|W|C|$X|10]]|11|$5|U|V|W|C|$X|12]]|13|$5|U|V|W|C|$X|14]]|15|$5|U|V|W|C|$X|16]]|17|$5|U|V|W|C|$X|18]]|19|$5|U|V|W|C|$X|1A]]]]

If you have an unassigned shard, usually the first step is to call the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html" rel="nofollow noreferrer">allocation explain API</a> and look for the reason. Depending on the reason, you'd do something about it. Here are some that come to mind:
<ul>
<li>node doesn't have enough disk space (check <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation" rel="nofollow noreferrer">disk-based allocation</a> settings)</li>
<li>node can't allocate the shard because of some restrictions like <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#cluster-shard-allocation-settings" rel="nofollow noreferrer">allocation is disabled</a> or <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html" rel="nofollow noreferrer">allocation filtering</a> or <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#shard-allocation-awareness" rel="nofollow noreferrer">awareness</a> (e.g. node is on the wrong side of the cluster, like the other availability zone or a hot or a warm node)</li>
<li>there's some error loading the shard. E.g. a checksum fails on files, there's a missing synonyms file referenced by an analyzer</li>
</ul>
Sometimes it helps to bump-start it, like using the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html" rel="nofollow noreferrer">Cluster Reroute API</a> to allocate the shard manually, or disabling and re-enabling replicas.
If you need more info on operating Elasticsearch, check Sematext's <a href="https://sematext.com/training/elasticsearch/elasticsearch-operations/" rel="nofollow noreferrer">Elasticsearch Operations training</a> (disclaimer: I'm delivering it).

blocks|key|172634|text|在ES+7.4.2上也存在类似的问题，命令已更改。正如在答案中提到的，首先要检查GET+_cluster/allocation/explain?pretty，然后检查POST+_cluster/reroute?retry_failed|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|172635|主您必须为主分片传递"accept_data_loss":+true|BOLD|172636|POST+_cluster/reroute
{
++++"commands":+[{
++++++++"allocate_stale_primary":+{
++++++++++++"index":+"filebeat-7.4.2-xxxx",
++++++++++++"shard":+0,
++++++++++++"node":+"my_node",
++++++++++++"accept_data_loss":+false
++++++++}
++++}]
}|code-block|syntax|javascript|172637|副本|172638|POST+_cluster/reroute
{
++++"commands":+[{
++++++++"allocate_replica":+{
++++++++++++"index":+"filebeat-7.4.2-xxxx",
++++++++++++"shard":+0,
++++++++++++"node":+"my_other_node"
++++++++}
++++}]
}|172639|cluster-reroute+doc|172640|entityMap|0|LINK|mutability|MUTABLE|url|https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-reroute.html^0|14|12|2B|Y|0|0|1|A|O|0|0|0|2|0|0|0|J|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|16|8|@$9|17|A|18|B|H]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|I|3|J|5|K|7|1B|8|@]|D|@]|E|$L|M]]|$1|N|3|O|5|6|7|1C|8|@$9|1D|A|1E|B|H]]|D|@]|E|$]]|$1|P|3|Q|5|K|7|1F|8|@]|D|@]|E|$L|M]]|$1|R|3|S|5|6|7|1G|8|@]|D|@$9|1H|A|1I|1|1J]]|E|$]]|$1|T|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]]|U|$V|$5|W|X|Y|E|$Z|10]]]]

Similar problem on ES 7.4.2, commands have changed. As already mentionned in answers , first thing to check <code>GET _cluster/allocation/explain?pretty</code> then <code>POST _cluster/reroute?retry_failed</code>
Primary
You have to pass <code>&quot;accept_data_loss&quot;: true</code> for a primary shard
<pre class="lang-json prettyprint-override"><code>POST _cluster/reroute
{
 &quot;commands&quot;: [{
 &quot;allocate_stale_primary&quot;: {
 &quot;index&quot;: &quot;filebeat-7.4.2-xxxx&quot;,
 &quot;shard&quot;: 0,
 &quot;node&quot;: &quot;my_node&quot;,
 &quot;accept_data_loss&quot;: false
 }
 }]
}
</code></pre>
Replica
<pre class="lang-json prettyprint-override"><code>POST _cluster/reroute
{
 &quot;commands&quot;: [{
 &quot;allocate_replica&quot;: {
 &quot;index&quot;: &quot;filebeat-7.4.2-xxxx&quot;,
 &quot;shard&quot;: 0,
 &quot;node&quot;: &quot;my_other_node&quot;
 }
 }]
}
</code></pre>
<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-reroute.html" rel="nofollow noreferrer">cluster-reroute doc</a>

blocks|key|169010|text|如果您使用的是aws+elasticsearch服务，上述建议将无法提供解决方案。在本例中，我使用连接到s3的备份结构备份了索引。然后我删除了索引并恢复了它。这对我很管用。请确保备份成功完成！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169011|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you are using the aws elasticsearch service, the above suggestions will not provide a solution. In this case, I backed up the index with the backup structure connected to s3. Then I deleted the index and restored it. it worked for me. Please make sure the backup completed successfully!

I have an ES cluster with 4 nodes:

<pre><code>number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true
</code></pre>

I had to restart search03, and when it came back, it rejoined the cluster no problem, but left 7 unassigned shards laying about. 

<pre><code>{
 "cluster_name" : "tweedle",
 "status" : "yellow",
 "timed_out" : false,
 "number_of_nodes" : 4,
 "number_of_data_nodes" : 3,
 "active_primary_shards" : 15,
 "active_shards" : 23,
 "relocating_shards" : 0,
 "initializing_shards" : 0,
 "unassigned_shards" : 7
}
</code></pre>

Now my cluster is in yellow state. What is the best way to resolve this issue?

<ul>
<li>Delete (cancel) the shards?</li>
<li>Move the shards to another node?</li>
<li>Allocate the shards to the node?</li>
<li>Update 'number_of_replicas' to 2?</li>
<li>Something else entirely?</li>
</ul>

Interestingly, when a new index was added, that node started working on it and played nice with the rest of the cluster, it just left the unassigned shards laying about.

Follow on question: am I doing something wrong to cause this to happen in the first place? I don't have much confidence in a cluster that behaves this way when a node is restarted. 

NOTE: If you're running a single node cluster for some reason, you might simply need to do the following:

<pre><code>curl -XPUT 'localhost:9200/_settings' -d '
{
 "index" : {
 "number_of_replicas" : 0
 }
}'
</code></pre>

ElasticSearch: Unassigned Shards, how to fix?

我有一个包含4个节点的ES集群：number_of_replicas: 1search01 - master: false, data: falsesearch02 - master: true, data: truesearch03 - master: false, data: truesearch04 - mast...

问ElasticSearch:未分配分片，如何修复？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ElasticSearch:未分配分片，如何修复？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ElasticSearch:未分配分片，如何修复？
EN