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
running the older version.
It is best to upgrade the master-ineligible nodes in your cluster first and then
upgrade the master-eligible nodes. Once enough of the master-eligible nodes have
been upgraded 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.
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.
Rolling upgrades are supported: