@@ -7,11 +7,27 @@ a time so upgrading does not interrupt service. Running multiple versions of
7
7
not supported, as shards cannot be replicated from upgraded nodes to nodes
8
8
running the older version.
9
9
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.
10
+ We strongly recommend that when you upgrade you divide your cluster's nodes
11
+ into the following two groups and upgrade the groups in this order:
12
+
13
+ . Nodes that are not <<master-node,master-eligible>>. You can retrieve a list
14
+ of these nodes with `GET /_nodes/_all,master:false` or by finding all the nodes
15
+ configured with `node.master: false`.
16
+
17
+ . Master-eligible nodes, which are the remaining nodes. You can retrieve a list
18
+ of these nodes with `GET /_nodes/master:true`.
19
+
20
+ You may upgrade the nodes within each of these groups in any order.
21
+
22
+ Upgrading the nodes in this order ensures that the master-ineligible nodes are
23
+ always running a version at least as new as the master-eligible nodes. Newer
24
+ nodes can always join a cluster with an older master, but older nodes cannot
25
+ always join a cluster with a newer master. By upgrading the master-eligible
26
+ nodes last you ensure that all the master-ineligible nodes will be able to join
27
+ the cluster whether the master-eligible nodes have been upgraded or not. If you
28
+ upgrade any master-eligible nodes before the master-ineligible nodes then there
29
+ is a risk that the older nodes will leave the cluster and will not be able to
30
+ rejoin until they have been upgraded.
15
31
16
32
Rolling upgrades are supported:
17
33
0 commit comments