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:
parent
ed86d925cd
commit
62d8b7ab97
|
@ -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]
|
||||||
|
|
Loading…
Reference in New Issue