Skip to content

Commit 8a60f9f

Browse files
robin13DaveCTurner
authored andcommitted
Clearer language around upgrade sequence (#47422)
1 parent 60700ed commit 8a60f9f

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

docs/reference/upgrade/rolling_upgrade.asciidoc

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -7,11 +7,11 @@ a time so upgrading does not interrupt service. Running multiple versions of
77
not supported, as shards cannot be replicated from upgraded nodes to nodes
88
running the older version.
99

10-
It is best to upgrade the master-ineligible nodes in your cluster first and then
11-
upgrade the master-eligible nodes. Once enough of the master-eligible nodes have
12-
been upgraded they may form a cluster that nodes of older versions cannot join.
13-
If you upgrade the master-eligible nodes last then all the other nodes will not
14-
be running an older version and so they will be able to join the cluster.
10+
It is best to upgrade the master-eligible nodes in your cluster after all of
11+
the other nodes. Once you have started to upgrade the master-eligible nodes
12+
they may form a cluster that nodes of older versions cannot join. If you
13+
upgrade the master-eligible nodes last then all the other nodes will not be
14+
running an older version and so they will be able to join the cluster.
1515

1616
Rolling upgrades are supported:
1717

0 commit comments

Comments
 (0)