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
|
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:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue