@@ -7,19 +7,23 @@ 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
- 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:
10
+ When performing a rolling upgrade:
12
11
13
- . Nodes that are not <<master-node,master-eligible>>. You can retrieve a list
12
+ . Upgrade nodes that are not <<master-node,master-eligible>>. You can retrieve a list
14
13
of these nodes with `GET /_nodes/_all,master:false` or by finding all the nodes
15
14
configured with `node.master: false`.
16
15
17
- . Master-eligible nodes, which are the remaining nodes. You can retrieve a list
18
- of these nodes with `GET /_nodes/master:true`.
16
+ . Upgrade nodes tier-by-tier, starting with the frozen tier.
17
+ Complete the upgrade for all nodes in each data tier before moving to the next.
18
+ Upgrade the frozen tier, then the cold tier, then the warm tier, and upgrade
19
+ the hot tier last. This ensures {ilm-init} can continue to move data through
20
+ the tiers during the upgrade. You can get the list of nodes in a specific tier
21
+ with a `GET /_nodes` request, for example: `GET /_nodes/data_frozen:true/_none`.
19
22
20
- You may upgrade the nodes within each of these groups in any order.
23
+ . Upgrade the master-eligible nodes last. You can retrieve a list
24
+ of these nodes with `GET /_nodes/master:true`.
21
25
22
- Upgrading the nodes in this order ensures that the master-ineligible nodes are
26
+ This order ensures that the master-ineligible nodes are
23
27
always running a version at least as new as the master-eligible nodes. Newer
24
28
nodes can always join a cluster with an older master, but older nodes cannot
25
29
always join a cluster with a newer master. By upgrading the master-eligible
0 commit comments