# Persisting IndicesRoutingTable

**URL:** <https://discuss.elastic.co/t/persisting-indicesroutingtable/15463>\
**Category:** Elasticsearch\
**Created:** [January 29, 2014, 3:11am UTC](https://discuss.elastic.co/t/persisting-indicesroutingtable/15463 "2014-01-29T03:11:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ananth](https://avatars.discourse-cdn.com/v4/letter/a/dfb087/32.png) [@ananth](https://discuss.elastic.co/u/ananth)\
**Post date:** [January 29, 2014, 3:11am UTC](https://discuss.elastic.co/t/persisting-indicesroutingtable/15463/1 "2014-01-29T03:11:07Z")

</div>

Hi ,

In case of planned shutdown (curl -XPOST '[http://localhost:9200/\_shutdown](http://localhost:9200/_shutdown)')  
, is it possible to persist the RoutingTable in master node. (In case , we  
are using separate master and data nodes.) So that when we start the  
cluster node by node (starting from master) along with  
gateway.expectednodes setting , then master node can re-use the persisted  
RoutingTable instead of constructing new one (New one causing unnecessary  
shard relocation, that too we have shards in big sizes). Once the expected  
nodes are available in cluster reusing the same avoids unnecessary movement  
of shrads with-in cluster.

Anantha Govindarajan.

--  
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/47ce730a-8521-463e-82e8-8eb271548664%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/47ce730a-8521-463e-82e8-8eb271548664%40googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [February 3, 2014, 7:44am UTC](https://discuss.elastic.co/t/persisting-indicesroutingtable/15463/2 "2014-02-03T07:44:21Z")

</div>

Hey,

there is a specific setting preventing shard allocation, see  
[Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html)(the  
disable\_allocation setting). Alternatively you can also the gateway  
recovery to start after a couple of minutes in addition to the expected  
nodes, which might give you more time to fire up all nodes?

--Alex

On Wed, Jan 29, 2014 at 4:11 AM, Anantha Govindarajan \<  
[ananthagovindarajan@gmail.com](mailto:ananthagovindarajan@gmail.com)\> wrote:

> Hi ,
> 
> In case of planned shutdown (curl -XPOST '[http://localhost:9200/\_shutdown](http://localhost:9200/_shutdown)')  
> , is it possible to persist the RoutingTable in master node. (In case , we  
> are using separate master and data nodes.) So that when we start the  
> cluster node by node (starting from master) along with  
> gateway.expectednodes setting , then master node can re-use the persisted  
> RoutingTable instead of constructing new one (New one causing unnecessary  
> shard relocation, that too we have shards in big sizes). Once the expected  
> nodes are available in cluster reusing the same avoids unnecessary movement  
> of shrads with-in cluster.
> 
> Anantha Govindarajan.
> 
> --  
> 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/47ce730a-8521-463e-82e8-8eb271548664%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/47ce730a-8521-463e-82e8-8eb271548664%40googlegroups.com)  
> .  
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
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/CAGCwEM9r5ukL%2B5gHww%3DeRGrZ7QJEZ0vjMzwNLn2%3D7n0SeoGLWg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM9r5ukL%2B5gHww%3DeRGrZ7QJEZ0vjMzwNLn2%3D7n0SeoGLWg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![ananth](https://avatars.discourse-cdn.com/v4/letter/a/dfb087/32.png) [@ananth](https://discuss.elastic.co/u/ananth)\
**Post date:** [February 4, 2014, 8:16am UTC](https://discuss.elastic.co/t/persisting-indicesroutingtable/15463/3 "2014-02-04T08:16:56Z")

</div>

Hi Alex ,

Thanks for replaying. gateway.expected\_datanodes settings works nicely , it  
starts recovery once all the datanodes (i configured) arrived.

Before performing full cluster restart , if the cluster in green state  
,then no need for BalancedShardAllocator on initial recovery after restart  
.There should be different recovery instead of normal procedure since  
shards are already allocated and balanced before cluster restart.

If i understand correctly, BalancedShardsAllocator can be turned off  
in-case of initial\_recovery\_from gateway, because while building  
cachedShardsState in LocalGatewayAllocator-\>allocateUnassigned() , itself  
we know the list of nodes which has the corresponding shard. Since initial  
recovery index/search wont be possible at this stage, rather than going through  
list of allocation deciders and BalancedShardsAllocator , we can directly  
assign all the shards immediately to the corresponding nodes with out  
throttling allocation. It avoids unnecessary shards movement across cluster due  
to BalancedShardAllocator.

Some one correct me if am wrong here !

--  
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/505bed3b-9fba-4ac2-af39-fca57df45b40%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/505bed3b-9fba-4ac2-af39-fca57df45b40%40googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<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:** [July 6, 2017, 1:52am UTC](https://discuss.elastic.co/t/persisting-indicesroutingtable/15463/4 "2017-07-06T01:52:54Z")

</div>


