honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-02-24 13:55:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clarify futher the order for a rolling upgrade (#52964)

Browse Source 
Expands the "master-ineligible then master-eligible" sentence into a list and
specifies that within these subsets the order doesn't matter.
This commit is contained in:
David Turner 2020-03-05 15:27:56 +00:00
parent 58ce56f6c8
commit c2627aa22f
1 changed files with 21 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/reference/upgrade/rolling_upgrade.asciidoc
View File

@ -7,11 +7,27 @@ a time so upgrading does not interrupt service. Running multiple versions of
not supported, as shards cannot be replicated from upgraded nodes to nodes
running the older version.
It is best to upgrade the master-eligible nodes in your cluster after all of
the other nodes. Once you have started to upgrade the master-eligible nodes
they may form a cluster that nodes of older versions cannot join. If you
upgrade the master-eligible nodes last then all the other nodes will not be
running an older version and so they will be able to join the cluster.
We strongly recommend that when you upgrade you divide your cluster's nodes
into the following two groups and upgrade the groups in this order:
. Nodes that are not <<master-node,master-eligible>>. You can retrieve a list
of these nodes with `GET /_nodes/_all,master:false` or by finding all the nodes
configured with `node.master: false`.
. Master-eligible nodes, which are the remaining nodes. You can retrieve a list
of these nodes with `GET /_nodes/master:true`.
You may upgrade the nodes within each of these groups in any order.
Upgrading the nodes in this order ensures that the master-ineligible nodes are
always running a version at least as new as the master-eligible nodes. Newer
nodes can always join a cluster with an older master, but older nodes cannot
always join a cluster with a newer master. By upgrading the master-eligible
nodes last you ensure that all the master-ineligible nodes will be able to join
the cluster whether the master-eligible nodes have been upgraded or not. If you
upgrade any master-eligible nodes before the master-ineligible nodes then there
is a risk that the older nodes will leave the cluster and will not be able to
rejoin until they have been upgraded.
Rolling upgrades are supported: