Re: Persisting IndicesRoutingTable
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+unsubscr...@googlegroups.com. To view this discussion on the web visit 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.
Re: Persisting IndicesRoutingTable
Hey, there is a specific setting preventing shard allocation, see 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 < ananthagovindara...@gmail.com> wrote: > Hi , > > In case of planned shutdown (curl -XPOST '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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > 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. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit 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.
Persisting IndicesRoutingTable
Hi , In case of planned shutdown (curl -XPOST '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+unsubscr...@googlegroups.com. To view this discussion on the web visit 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.
