Clearer language around upgrade sequence (#47422)
This commit is contained in:
parent
1cecbd0cd3
commit
98c1c2f650
|
@ -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:
|
||||
|
||||
|
|
Loading…
Reference in New Issue