ES跨版本升级？——难道升级集群发生shard allocation是因为要分配replica节点？？？

Full cluster restart upgrade

Elasticsearch requires a full cluster restart when upgrading across major versions. Rolling upgrades are not supported across major versions. Consult this table to verify that a full cluster restart is required.

The process to perform an upgrade with a full cluster restart is as follows:

1. Disable shard allocation——防止分片大量复制数据

   When you shut down a node, the allocation process will immediately try to replicate the shards that were on that node to other nodes in the cluster, causing a lot of wasted I/O. This can be avoided by disabling allocation before shutting down a node:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": "none"
     }
   }

   COPY AS CURLVIEW IN CONSOLE

2. Perform a synced flush

   Shard recovery will be much faster if you stop indexing and issue a synced-flush request:

   POST _flush/synced

   COPY AS CURLVIEW IN CONSOLE

   A synced flush request is a “best effort” operation. It will fail if there are any pending indexing operations, but it is safe to reissue the request multiple times if necessary.

3. Shutdown and upgrade all nodes

   Stop all Elasticsearch services on all nodes in the cluster. Each node can be upgraded following the same procedure described in [upgrade-node].

4. Upgrade any plugins

   Elasticsearch plugins must be upgraded when upgrading a node. Use the elasticsearch-plugin script to install the correct version of any plugins that you need.

5. Start the cluster——先启动主节点，然后再是数据节点

   If you have dedicated master nodes — nodes with node.master set to true(the default) and node.data set to false —  then it is a good idea to start them first. Wait for them to form a cluster and to elect a master before proceeding with the data nodes. You can check progress by looking at the logs.

   As soon as the minimum number of master-eligible nodes have discovered each other, they will form a cluster and elect a master. From that point on, the _cat/health and _cat/nodesAPIs can be used to monitor nodes joining the cluster:

   GET _cat/health
   
   GET _cat/nodes

   COPY AS CURLVIEW IN CONSOLE

   Use these APIs to check that all nodes have successfully joined the cluster.

6. Wait for yellow

   As soon as each node has joined the cluster, it will start to recover any primary shards that are stored locally. Initially, the _cat/health request will report a status of red, meaning that not all primary shards have been allocated.

   Once each node has recovered its local shards, the status will become yellow, meaning all primary shards have been recovered, but not all replica shards are allocated. This is to be expected because allocation is still disabled.

7. Reenable allocation

   Delaying the allocation of replicas until all nodes have joined the cluster allows the master to allocate replicas to nodes which already have local shard copies. At this point, with all the nodes in the cluster, it is safe to reenable shard allocation:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": "all"
     }
   }

   COPY AS CURLVIEW IN CONSOLE

   The cluster will now start allocating replica shards to all data nodes（难道升级集群发生shard allocation是因为要分配replica节点？？？）. At this point it is safe to resume indexing and searching, but your cluster will recover more quickly if you can delay indexing and searching until all shards have recovered.

   You can monitor progress with the _cat/health and _cat/recovery APIs:

   GET _cat/health
   
   GET _cat/recovery

   COPY AS CURLVIEW IN CONSOLE

   Once the status column in the _cat/health output has reached green, all primary and replica shards have been successfully allocated.