# Delayed allocation & rolling upgrade

**URL:** <https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356>\
**Category:** Elasticsearch\
**Created:** [May 28, 2017, 6:26am UTC](https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356 "2017-05-28T06:26:33Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Charles.w](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/charles.w/32/15486_2.png) [@Charles.w](https://discuss.elastic.co/u/Charles.w)\
**Post date:** [May 28, 2017, 6:26am UTC](https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356/1 "2017-05-28T06:26:34Z")

</div>

Hi,

When upgrading an ES 5.x cluster to a newer version, the [rolling restart procedure](https://www.elastic.co/guide/en/elasticsearch/guide/current/_rolling_restarts.html) states that you should :

- (stop indexing new data to speed up recovery)
- disable shard allocation to prevent elasticsearch from rebalancing missing shards when you are absolutely sure that node maintenance downtime will be short
- (shut down a single node / perform maintenance / restart this node)
- confirm that the restarted node has successfully joined the cluster
- reenable shard allocation
- wait for the cluster to return to a green status (usually after having rebalanced a few shards)

As this procedure is to be used when the downtime is planned to be quite short and as during this procedure the cluster turns yellow, isn't it simpler to just use [delayed allocation](https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html) ?

Note: this is an open question, so please note that I'm fully aware of the difference between the standard "disable shard allocation" method vs the "delayed allocation" method (as the latter could easily be achieved using the first one). Furthermore, when using IT automation tools such as Ansible, the downtime of a node is usually quite short and using the "delayed allocation" method can relieve many of having to develop their own roles and stick to the default [ansible-elasticsearch role](https://github.com/elastic/ansible-elasticsearch).

Best regards,

Charles.w

---

<div class="post-metadata">

**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:** [May 28, 2017, 7:37am UTC](https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356/2 "2017-05-28T07:37:41Z")

</div>

It is.

You'll note that the definitive guide was written for 2.X, we're in the process of updating it now so things like this will evolve 🙂

---

<div class="post-metadata">

**Author:** ![Charles.w](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/charles.w/32/15486_2.png) [@Charles.w](https://discuss.elastic.co/u/Charles.w)\
**Post date:** [May 28, 2017, 8:23am UTC](https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356/3 "2017-05-28T08:23:04Z")

</div>

Hi Mark,

Thanks for this answer.

Please note that though I linked the definitive guide, the [reference documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/rolling-upgrades.html) states the same thing and could be updated as well 🙂

Best regards,

Charles.w

---

<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:** [June 25, 2017, 8:23am UTC](https://discuss.elastic.co/t/delayed-allocation-rolling-upgrade/87356/4 "2017-06-25T08:23:06Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.