honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Docs: Update rolling upgrade 

Added note about why replica shards may remain unassigned while there is only one node of the higher version in the cluster.

Closes #10951
This commit is contained in:
Clinton Gormley 2015-05-04 16:48:53 +02:00
parent 75cadaff39
commit bffcf5af58
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/reference/setup/upgrade.asciidoc
View File

@ -121,6 +121,20 @@ This syntax applies to Elasticsearch 1.0 and later:
* Repeat this process for all remaining nodes. * Repeat this process for all remaining nodes.
[IMPORTANT]
====================================================
During a rolling upgrade, primary shards assigned to a node with the higher
version will never have their replicas assigned to a node with the lower
version, because the newer version may have a different data format which is
not understood by the older version.
If it is not possible to assign the replica shards to another node with the
higher version -- e.g. if there is only one node with the higher version in
the cluster -- then the replica shards will remain unassigned, i.e. the
cluster health will be status `yellow`. As soon as another node with the
higher version joins the cluster, the replicas should be assigned and the
cluster health will reach status `green`.
====================================================
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.