Elasticsearch6.4专题之7:升级ES

Upgrade Elasticsearch

When upgrading to a new version of Elasticsearch, you need to upgrade each of the products in your Elastic Stack.

import：

Before upgrading Elasticsearch:

• Review the breaking changes for changes that affect your application.
• Check the deprecation log to see if you are using any deprecated features.
• If you use custom plugins, make sure compatible versions are available.
• Test upgrades in a dev environment before upgrading your production cluster.
• Back up your data before upgrading. You cannot roll back to an earlier version unless you have a backup of your data.

The following table shows when you can perform a rolling upgrade, when you need to reindex or delete old indices, and when a full cluster restart is required.

Upgrade From|Upgrade To|Supported Upgrade Type
–|–|–|–
5.x|5.y|Rolling upgrade (where y > x)
5.6|6.x|Rolling upgrade [a]
5.0-5.5|6.x|Full cluster restart [a]
<5.x|6.x|Reindex to upgrade
6.x|6.y|Rolling upgrade (where y > x)

You must delete or reindex any indices created in 2.x before upgrading.

Elasticsearch can read indices created in the previous major version. Older indices must be reindexed or deleted. Elasticsearch 6.x can use indices created in Elasticsearch 5.x, but not those created in Elasticsearch 2.x or before. Elasticsearch 5.x can use indices created in Elasticsearch 2.x, but not those created in 1.x or before.

This also applies to indices backed up with snapshot and restore. If an index was originally created in 2.x, it cannot be restored to a 6.x cluster even if the snapshot was created by a 5.x cluster.

Elasticsearch nodes will fail to start if incompatible indices are present.

For information about how to upgrade old indices, see Reindex to upgrade.

Rolling upgrades

A rolling upgrade allows an Elasticsearch cluster to be upgraded one node at a time so upgrading does not interrupt service. Running multiple versions of Elasticsearch in the same cluster beyond the duration of an upgrade is not supported, as shards cannot be replicated from upgraded nodes to nodes running the older version.

Rolling upgrades can be performed between minor versions. Elasticsearch 6.x supports rolling upgrades from Elasticsearch 5.6. Upgrading from earlier 5.x versions requires a full cluster restart. You must reindex to upgrade from versions prior to 5.x.

warning

If the Elasticsearch security features are enabled on your 5.x cluster, before you can do a rolling upgrade you must encrypt the internode-communication with SSL/TLS, which requires a full cluster restart. For more information about this requirement and the associated bootstrap check, see SSL/TLS check.

warning

The format used for the internal indices used by Kibana and X-Pack has changed in 6.x. When upgrading from 5.6 to 6.x, these internal indices have to be upgraded before the rolling upgrade procedure can start. Otherwise the upgraded node will refuse to join the cluster.

To perform a rolling upgrade:

1. Disable shard allocation.
   
   When you shut down a node, the allocation process waits for index.unassigned.node_left.delayed_timeout (by default, one minute) before starting to replicate the shards on that node to other nodes in the cluster, which can involve a lot of I/O. Since the node is shortly going to be restarted, this I/O is unnecessary. You can avoid racing the clock by disabling allocation before shutting down the node:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": "none"
     }
   }
   或
   curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
   {
     "persistent": {
       "cluster.routing.allocation.enable": "none"
     }
   }'
   

2. Stop non-essential indexing and perform a synced flush. (Optional)
   
   While you can continue indexing during the upgrade, shard recovery is much faster if you temporarily stop non-essential indexing and perform a synced-flush.

   POST _flush/synced
   或
   curl -X POST "localhost:9200/_flush/synced?pretty"
   

   When you perform a synced flush, check the response to make sure there are no failures. Synced flush operations that fail due to pending indexing operations are listed in the response body, although the request itself still returns a 200 OK status. If there are failures, reissue the request.

3. Stop any machine learning jobs that are running.

4. Shut down a single node.

   1. If you are running Elasticsearch with systemd:

   sudo systemctl stop elasticsearch.service
   

   2. If you are running Elasticsearch with SysV init:

   sudo -i service elasticsearch stop
   

   3. If you are running Elasticsearch as a daemon:

   kill $(cat pid)
   

5. Upgrade the node you shut down.

   important

   If you are upgrading from a version prior to 6.3 and use X-Pack then you must remove the X-Pack plugin before upgrading with bin/elasticsearch-plugin remove x-pack. As of 6.3, X-Pack is included in the default distribution so make sure to upgrade to that one. If you upgrade without removing the X-Pack plugin first the node will fail to start. If you did not remove the X-Pack plugin and the node fails to start then you must downgrade to your previous version, remove X-Pack, and then upgrade again. In general downgrading is not supported but in this particular case it is.

6. Upgrade any plugins.

7. Start the upgraded node.

8. Reenable shard allocation.

   Once the node has joined the cluster, remove the cluster.routing.allocation.enable setting to enable shard allocation and start using the node:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": null
     }
   }
   或
   curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
   {
     "persistent": {
       "cluster.routing.allocation.enable": null
     }
   }'
   

9. Wait for the node to recover.

   Before upgrading the next node, wait for the cluster to finish shard allocation. You can check progress by submitting a _cat/health request:

   GET _cat/health?v
   或
   curl -X GET "localhost:9200/_cat/health?v&pretty"
   

   Shards that were not sync-flushed might take longer to recover. You can monitor the recovery status of individual shards by submitting a _cat/recovery request:

   GET _cat/recovery
   或
   curl -X GET "localhost:9200/_cat/recovery?pretty"
   

10. Repeat

11. Restart machine learning jobs.

Full cluster restart upgrade

A full cluster restart upgrade requires that you shut all nodes in the cluster down, upgrade them, and restart the cluster. A full cluster restart was required when upgrading to major versions prior to 6.x. Elasticsearch 6.x supports rolling upgrades from Elasticsearch 5.6. Upgrading to 6.x from earlier versions requires a full cluster restart. See the Upgrade paths table to verify the type of upgrade you need to perform.

To perform a full cluster restart upgrade:

1. Disable shard allocation.
   
   When you shut down a node, the allocation process waits for index.unassigned.node_left.delayed_timeout (by default, one minute) before starting to replicate the shards on that node to other nodes in the cluster, which can involve a lot of I/O. Since the node is shortly going to be restarted, this I/O is unnecessary. You can avoid racing the clock by disabling allocation before shutting down the node:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": "none"
     }
   }
   或
   curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
   {
     "persistent": {
       "cluster.routing.allocation.enable": "none"
     }
   }'
   

2. Stop indexing and perform a synced flush.
   Performing a synced-flush speeds up shard recovery.

   POST _flush/synced
   或
   curl -X POST "localhost:9200/_flush/synced?pretty"
   

   When you perform a synced flush, check the response to make sure there are no failures. Synced flush operations that fail due to pending indexing operations are listed in the response body, although the request itself still returns a 200 OK status. If there are failures, reissue the request.

3. Stop any machine learning jobs that are running.

4. Shutdown all nodes.

5. Upgrade all nodes.

6. Upgrade any plugins.

7. Start each upgraded node.
   
   If you have dedicated master nodes, start them first and wait for them to form a cluster and elect a master before proceeding with your 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 form a cluster and elect a master. At that point, you can use _cat/health and _cat/nodes to monitor nodes joining the cluster:

   GET _cat/health
   
   GET _cat/nodes
   或
   curl -X GET "localhost:9200/_cat/health?pretty"
   curl -X GET "localhost:9200/_cat/nodes?pretty"
   

   The status column returned by _cat/health shows the health of each node in the cluster: red, yellow, or green.

8. Wait for all nodes to join the cluster and report a status of yellow.
   
   When a node joins the cluster, it begins to recover any primary shards that are stored locally. The _cat/health API initially reports a status of red, indicating that not all primary shards have been allocated.

   Once a node recovers its local shards, the cluster status switches to yellow, indicating that all primary shards have been recovered, but not all replica shards are allocated. This is to be expected because you have not yet reenabled allocation. Delaying the allocation of replicas until all nodes are yellow allows the master to allocate replicas to nodes that already have local shard copies.

9. Reenable allocation.
   When all nodes have joined the cluster and recovered their primary shards, reenable allocation by restoring cluster.routing.allocation.enable to its default:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.enable": null
     }
   }
   或
   curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
   {
     "persistent": {
       "cluster.routing.allocation.enable": null
     }
   }'
   

   Once allocation is reenabled, the cluster starts allocating replica shards to the data nodes. At this point it is safe to resume indexing and searching, but your cluster will recover more quickly if you can wait until all primary and replica shards have been successfully allocated and the status of all nodes is green.

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

   GET _cat/health
   
   GET _cat/recovery
   或
   curl -X GET "localhost:9200/_cat/health?pretty"
   curl -X GET "localhost:9200/_cat/recovery?pretty"
   

10. If you use X-Pack security and are upgrading directly to 6.4.3 from 5.5 or earlier, you must upgrade the .security index after you restart Elasticsearch.

11. Restart machine learning jobs.

Reindex before upgrading

Elasticsearch can read indices created in the previous major version. Older indices must be reindexed or deleted. Elasticsearch 6.x can use indices created in Elasticsearch 5.x, but not those created in Elasticsearch 2.x or before. Elasticsearch 5.x can use indices created in Elasticsearch 2.x, but not those created in 1.x or before.

Elasticsearch nodes will fail to start if incompatible indices are present.

To upgrade an Elasticsearch 5.x cluster that contains indices created in 2.x, you must reindex or delete them before upgrading to 6.x. For more information, see Reindex in place.

To upgrade an Elasticsearch cluster running 2.x, you have two options:

• Perform a full cluster restart upgrade to 5.6, reindex the 2.x indices, then perform a rolling upgrade to 6.x. If your Elasticsearch 2.x cluster contains indices that were created before 2.x, you must either delete or reindex them before upgrading to 5.6. For more information about upgrading from 2.x to 5.6, see Upgrading Elasticsearch in the Elasticsearch 5.6 Reference.
• Create a new 6.x cluster and reindex from remote to import indices directly from the 2.x cluster.

To upgrade an Elasticsearch 1.x cluster, you have two options:

• Perform a full cluster restart upgrade to Elasticsearch 2.4.x and reindex or delete the 1.x indices. Then, perform a full cluster restart upgrade to 5.6 and reindex or delete the 2.x indices. Finally, perform a rolling upgrade to 6.x. For more information about upgrading from 1.x to 2.4, see Upgrading Elasticsearch in the Elasticsearch 2.4 Reference. For more information about upgrading from 2.4 to 5.6, see Upgrading Elasticsearch in the Elasticsearch 5.6 Reference.
• Create a new 6.x cluster and reindex from remote to import indices directly from the 1.x cluster.

Reindex in place

To manually reindex your old indices with the reindex API:

1. Create a new index and copy the mappings and settings from the old index.
2. Set the refresh_interval to -1 and the number_of_replicas to 0 for efficient reindexing.
3. Reindex all documents from the old index into the new index using the reindex API.
4. Reset the refresh_interval and number_of_replicas to the values used in the old index.
5. Wait for the index status to change to green.
6. In a single update aliases request:
   1. Delete the old index.
   2. Add an alias with the old index name to the new index.
   3. Add any aliases that existed on the old index to the new index.

Reindex from a remote cluster

You can use reindex from remote to migrate indices from your old cluster to a new 6.x cluster. This enables you move to 6.x from a pre-5.6 cluster without interrupting service.

To migrate your indices:

1. Set up a new 6.x cluster alongside your old cluster. Enable it to access your old cluster by adding your old cluster to the reindex.remote.whitelist in elasticsearch.yml:

reindex.remote.whitelist: oldhost:9200

2. For each index that you need to migrate to the 6.x cluster:
   1. Create a new index in 6.x with the appropriate mappings and settings. Set the refresh_interval to -1 and set number_of_replicas to 0 for faster reindexing.
   2. Reindex from remote to pull documents from the old index into the new 6.x index:

   POST _reindex
   {
     "source": {
       "remote": {
         "host": "http://oldhost:9200",
         "username": "user",
         "password": "pass"
       },
       "index": "source",
       "query": {
         "match": {
           "test": "data"
         }
       }
     },
     "dest": {
       "index": "dest"
     }
   }
   或
   curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
   {
     "source": {
       "remote": {
         "host": "http://oldhost:9200",
         "username": "user",
         "password": "pass"
       },
       "index": "source",
       "query": {
         "match": {
           "test": "data"
         }
       }
     },
     "dest": {
       "index": "dest"
     }
   }'
   

   3. If you run the reindex job in the background by setting wait_for_completion to false, the reindex request returns a task_id you can use to monitor progress of the reindex job with the task API: GET _tasks/TASK_ID.
   4. When the reindex job completes, set the refresh_interval and number_of_replicas to the desired values (the default settings are 30s and 1).
   5. Once replication is complete and the status of the new index is green, you can delete the old index.