# Multiple ES versions in cluster support **URL:** \ **Category:** Elasticsearch\ **Created:** [April 25, 2014, 4:01pm UTC](https://discuss.elastic.co/t/multiple-es-versions-in-cluster-support/17201 "2014-04-25T16:01:41Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [April 26, 2014, 3:44am UTC](https://discuss.elastic.co/t/multiple-es-versions-in-cluster-support/17201/5 "2014-04-26T03:44:20Z")
cluster.routing.allocation.disable\_allocation was deprecated in early v1, its now cluster.routing.allocation.enable as per > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) web: [www.campaignmonitor.com](http://www.campaignmonitor.com) On 26 April 2014 09:31, Brian Flad [bflad417@gmail.com](mailto:bflad417@gmail.com) wrote: > The unassigned shard behavior you witnessed is correct even between 1.1.0 > and 1.1.1 nodes due to a Lucene upgrade (among others). If a primary shard > becomes located on a newer (1.1.1 node in this case), it cannot create a > replica on any older node (such as 1.1.0), leaving in unassigned until you > have more nodes at the same version. > > You can actually see the reasoning behind this behavior if you use the > cluster rerouting API to try to move an unassigned shard to a node: > > curl -X POST [http://hostname:9200/\_cluster/reroute](http://hostname:9200/_cluster/reroute) -d > '{"commands":[{"allocate":{"index":"my\_index","shard":1,"node":"some\_node"}}]}' > > The output of that command will helpfully tell you about the above version > conflict between 1.1.0 and 1.1.1 for example. > > Also, not specifically mentioned in this thread, but if you're just > restarting nodes across a cluster (to upgrade for example), you can > temporarily disable the "rebalancing" of shards so its not needlessly > shuffling data around via disable\_allocation: > > curl -X PUT [http://hostname:9200/\_cluster/settings](http://hostname:9200/_cluster/settings) -d > '{"transient":{"cluster.routing.allocation.disable\_allocation": true}}' > > When you're done: > > curl -X PUT [http://hostname:9200/\_cluster/settings](http://hostname:9200/_cluster/settings) -d > '{"transient":{"cluster.routing.allocation.disable\_allocation": false}}' > > We use this to keep Elasticsearch up to date without downtime across 10s > of clusters. > > Hope this helps, > Brian > > On Fri, Apr 25, 2014 at 1:48 PM, Srividhya Umashanker \< > [srividhya.umashanker@gmail.com](mailto:srividhya.umashanker@gmail.com)\> wrote: > > > Jilles - > > > > > > > > > Thanks for your quick response. > > > > I think, i tired doing a graceful shutdown and then did an upgrade. I > > made sure i did the graceful upgrade as you mentioned. > > > > Now the same problem, I had 3 nodes running 1.0.3, i upgraded two of > > those to 1.1.1 (graceful upgrade), as you see the indexes are > > sharded/replicated among the 1.1.1 nodes alone. > > Later, i shutdown one of the nodes running 1.1.1, I expect the "test1" > > index to be allocated in "victor strange" (1.0.3), but u can see it > > unassigned. > > When i bring back another node running 1.1.1, the indexes/shards are > > allocated properly. > > > > Does that mean, when indexes are places in higher versions, they can > > never be allocated in lower version nodes? I know, vice versa is possible. > > I am trying to relate to a federation topology (where nodes run different > > versions and work together) > > > > [https://lh4.googleusercontent.com/-20qvisNaQ28/U1qe83USfaI/AAAAAAAAAks/44U6xqRIQY4/s1600/problem+2.png](https://lh4.googleusercontent.com/-20qvisNaQ28/U1qe83USfaI/AAAAAAAAAks/44U6xqRIQY4/s1600/problem+2.png) > > > > -- > > 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/6c7fa16b-5b4c-41e0-943c-5250da16995a%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6c7fa16b-5b4c-41e0-943c-5250da16995a%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6c7fa16b-5b4c-41e0-943c-5250da16995a%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6c7fa16b-5b4c-41e0-943c-5250da16995a%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > > Brian Flad > [Brian Flad - Philadelphia | about.me](http://about.me/bflad) > > -- > 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/CAF3hLz%3D7rZczoUPLs8ErVdMRDuXVbmE%3D7306W8VfX9TUV%3De\_Lg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAF3hLz%3D7rZczoUPLs8ErVdMRDuXVbmE%3D7306W8VfX9TUV%3De_Lg%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAF3hLz%3D7rZczoUPLs8ErVdMRDuXVbmE%3D7306W8VfX9TUV%3De\_Lg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAF3hLz%3D7rZczoUPLs8ErVdMRDuXVbmE%3D7306W8VfX9TUV%3De_Lg%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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/CAEM624b874Cz5xbMqXKkpWd98cPv-VhrjHb%3Dk%3DhnGkgzWLvx-g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624b874Cz5xbMqXKkpWd98cPv-VhrjHb%3Dk%3DhnGkgzWLvx-g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). --- _[View the full topic](https://discuss.elastic.co/t/multiple-es-versions-in-cluster-support/17201)._