# Elasticsearch cluster leaving shards unassigned

**URL:** <https://discuss.elastic.co/t/elasticsearch-cluster-leaving-shards-unassigned/19178>\
**Category:** Elasticsearch\
**Created:** [August 9, 2014, 9:42pm UTC](https://discuss.elastic.co/t/elasticsearch-cluster-leaving-shards-unassigned/19178 "2014-08-09T21:42:15Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steve\_Elliott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steve_elliott/32/1348_2.png) [@Steve\_Elliott](https://discuss.elastic.co/u/Steve_Elliott)\
**Post date:** [August 9, 2014, 9:42pm UTC](https://discuss.elastic.co/t/elasticsearch-cluster-leaving-shards-unassigned/19178/1 "2014-08-09T21:42:15Z")

</div>

We're running an elasticsearch cluster for logging, indexing logs from  
multiple locations using logstash. We recently added two additional nodes  
for additional capacity whilst we await further hardware for the cluster's  
expansion. Ultimately we aim to have 2 nodes for "realtime" data running on  
SSDs to provide fast access to recent data, and ageing the data over to  
HDDs for older indicies. The new nodes we put in had a lot less memory than  
the existing boxes (700GB vs 5TB), but given this will be similar to the  
situation we'd have when we implemented SSDs, I didn't forsee it being much  
of a problem.

As a first attempt, I threw the nodes into the cluster trusting the new  
Disk spaced based allocation rules would mean they wouldn't instantly get  
filled up. This unfortunately wasn't the case, I awoke to find the cluster  
had merrily reallocated shards onto the new nodes, in excess of 99%. After  
some jigging of settings I managed to remove all data from these nodes and  
return the cluster to it's previous state (all shards assigned, cluster  
state green).

As a next approach I tried to implement index/node tagging similar to my  
plans for when we implement SSDs. This left us with the following  
configuration:

- Node 1 - 5TB, tags: realtime, archive
- Node 2 - 5TB, tags: realtime, archive
- Node 3 - 5TB, tags: realtime, archive
- Node 4 - 700GB, tags: realtime
- Node 5 - 700GB, tags: realtime

(all nodes running elasticsearch 1.3.1 and oracle java 7 u55)

Using curator I then tagged indicies older than 10days as "archive" and  
more recent ones "realtime". This in the background sets the index shard  
allocation "Require". Which my understanding is it will require the node to  
have the tag, but not ONLY that tag.

Unfortunately this doesn't appeared to have had the desired effect. Most  
worryingly, no indices tagged as archive are allocating their replica  
shards, leaving 295 unassigned shards. Additionally the realtime tagged  
indicies are only using nodes 4, 5 and oddly 3. Node 3 has no shards except  
the very latest index and some kibana-int shards.

If I remove the tags and use exclude.\_ip to pull shards off the new nodes,  
I can (slowly) return the cluster to green, as this is the approach I took  
when the new nodes had filled up completely, but I'd really like to get  
this setup sorted so I can have confidence the SSD configuration will work  
when the new kit arrives.

I have attempted to enable: cluster.routing.allocation.allow\_rebalance to  
always, on the theory the cluster wasn't rebalancing due to the unassigned  
replicas. I've also tried: cluster.routing.allocation.enable to all, but  
again, this has had no discernable impact.

Have I done something obviously wrong? Or is there disagnostics of some  
sort I could use? I've been visualising the allocation of shards using  
Elasticsearch Head plugin.

Any assistance would be appreciated, hopefully it's just a stupid mistake  
that I can fix easily!

Thanks in advance

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/73ada837-c455-4d47-8583-f7fd753f76e1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/73ada837-c455-4d47-8583-f7fd753f76e1%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Kumar\_Narottam](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kumar_narottam/32/18959_2.png) [@Kumar\_Narottam](https://discuss.elastic.co/u/Kumar_Narottam)\
**Post date:** [June 10, 2017, 1:48pm UTC](https://discuss.elastic.co/t/elasticsearch-cluster-leaving-shards-unassigned/19178/2 "2017-06-10T13:48:36Z")

</div>

Did you solve the problem, i am stuck with same issue. Any luck ??

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 4, 2022, 4:01am UTC](https://discuss.elastic.co/t/elasticsearch-cluster-leaving-shards-unassigned/19178/3 "2022-11-04T04:01:25Z")

</div>

Closed on November 4, 2022, 4:01am UTC


