Docs: rolling upgrade process seems incorrect

When reading the [rolling upgrade process](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades), you can see that we wrote:

* disable allocation
* upgrade node1
* upgrade node2
* upgrade node3
* ...
* enable allocation

That won't work as after a node has been removed and restarted, no shard will be allocated anymore.
So closing node2 and remaining nodes, won't help to serve index and search request anymore.

We should write:

* disable allocation
* upgrade node1
* enable allocation
* wait for shards being recovered on node1
* disable allocation
* upgrade node2
* enable allocation
* wait for shards being recovered on node2
* disable allocation
* upgrade node3
* enable allocation
* wait for shards being recovered on node3
* disable allocation
* ...
* enable allocation

I think this documentation update should go in 1.3, 1.4, 1.x and master branches.

Closes #8218
Closes #7973.
This commit is contained in:
David Pilato 2014-10-24 11:39:43 +02:00 committed by Clinton Gormley
parent ed86d925cd
commit 62d8b7ab97
1 changed files with 4 additions and 3 deletions

View File

@ -111,9 +111,7 @@ curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
* Start the now upgraded node. Confirm that it joins the cluster. * Start the now upgraded node. Confirm that it joins the cluster.
* Repeat this process for all remaining nodes. * Re-enable shard reallocation:
* When the process is complete on all nodes, you can re-enable shard reallocation:
[source,sh] [source,sh]
-------------------------------------------------- --------------------------------------------------
@ -126,6 +124,9 @@ curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
* Observe that all shards are properly allocated on all nodes. Balancing may take some time. * Observe that all shards are properly allocated on all nodes. Balancing may take some time.
* Repeat this process for all remaining nodes.
It may be possible to perform the upgrade by installing the new software while the service is running. This would reduce downtime by ensuring the service was ready to run on the new version as soon as it is stopped on the node being upgraded. This can be done by installing the new version in its own directory and using the symbolic link method outlined above. It is important to test this procedure first to be sure that site-specific configuration data and production indices will not be overwritten during the upgrade process. It may be possible to perform the upgrade by installing the new software while the service is running. This would reduce downtime by ensuring the service was ready to run on the new version as soon as it is stopped on the node being upgraded. This can be done by installing the new version in its own directory and using the symbolic link method outlined above. It is important to test this procedure first to be sure that site-specific configuration data and production indices will not be overwritten during the upgrade process.
[float] [float]