Clearer language around upgrade sequence (#47422)

This commit is contained in:
Robin Clarke 2019-10-02 10:22:02 +02:00 committed by David Turner
parent 1cecbd0cd3
commit 98c1c2f650
1 changed files with 5 additions and 5 deletions

View File

@ -7,11 +7,11 @@ a time so upgrading does not interrupt service. Running multiple versions of
not supported, as shards cannot be replicated from upgraded nodes to nodes not supported, as shards cannot be replicated from upgraded nodes to nodes
running the older version. running the older version.
It is best to upgrade the master-ineligible nodes in your cluster first and then It is best to upgrade the master-eligible nodes in your cluster after all of
upgrade the master-eligible nodes. Once enough of the master-eligible nodes have the other nodes. Once you have started to upgrade the master-eligible nodes
been upgraded they may form a cluster that nodes of older versions cannot join. they may form a cluster that nodes of older versions cannot join. If you
If you upgrade the master-eligible nodes last then all the other nodes will not upgrade the master-eligible nodes last then all the other nodes will not be
be running an older version and so they will be able to join the cluster. running an older version and so they will be able to join the cluster.
Rolling upgrades are supported: Rolling upgrades are supported: