Quick links
- Upgrade Elasticsearch 5.6.16 to Elasticsearch 6.8.23
- Preparing to upgrade Elasticsearch nodes
- How to upgrade nodes in a rolling upgrade
Upgrade Elasticsearch 5.6.16 to Elasticsearch 6.8.23
In this article, we will focus on upgrading Elasticsearch 5.6.16 to Elasticsearch 6.8.23. For more information on version upgrades in general, the different methods available, and everything you need to know prior to initiating the upgrade, you can see our complete guide here: How to Upgrade Elasticsearch Versions.
Rolling upgrades are only supported from Elasticsearch version 5.6.16 to Elasticsearch version 6.8.23. To upgrade from earlier versions of 5.6 to version 6.8.23, you need a full cluster restart or you must upgrade first to version 5.6.16 before upgrading to version 6.
Preparing to upgrade Elasticsearch nodes
Elasticsearch nodes cannot be downgraded after upgrading. Before starting the upgrade process you should review the following:
1. Check the deprecation log
You should read and resolve any issues highlighted in the deprecation log. These logs are usually located in:
/var/log/elasticsearch/Your-Cluster-Name_deprecation.log
2. Review the breaking changes
Breaking changes documentation is published with each new version of Elasticsearch to make you aware of any functionality that may change or disappear. You should always check that documentation to ensure that none of those settings, configurations, or mappings are being used in your setup. The main things that could be affected are:
- Node configuration (elasticsearch.yml)
- Index mappings and templates
- Cluster settings
- Code used in Elasticsearch clients (applications and indexing scripts)
The most important breaking changes for version 6 are:
- Users are no longer allowed multiple index types per index – just one type is permitted per index
- The Groovy and Python scripting languages have been removed and replaced with Painless scripting
3. Check Elasticsearch plugins’ compatibility
If you are using any Elasticsearch plugins, you should check the availability and compatibility of those plugins with the new version.
X-Pack plugins
The changes made to the X-Pack plugins between version 5.6 and version 6.8 mean that a number of configurations and the internal indices used for version 5 are not compatible with version 6.
So, if you are running X-Pack, you should:
- Use the Upgrade Assistant in Kibana to identify and resolve upgrade issues.
- Upgrade the internal X-Pack indices using X-Pack 5.6 Reindex Helper in Kibana.
- Enable TLS because it is required in order to run with security enabled in version 6.
The following APIs can also be used as alternatives to the Kibana Upgrade Assistant:
To see any settings that have been deprecated and that should be fixed before upgrading:
/_xpack/migration/deprecations
To see a list of indices that need to be reindexed before upgrading to 6.8.23:
/_xpack/migration/assistance
To upgrade the X-Pack and security indices to a format that is compatible with version 6:
/_xpack/migration/upgrade
If you are NOT running X-Pack, then you will need to disable the security features in elasticsearch.yml and kibana.yml when upgrading to version 6:
xpack.security.enabled: false
4. Set up a test environment
You should first try the upgrade process in a test or staging environment in order to check and resolve all issues before upgrading your production cluster. This is especially important if you are running X-Pack.
5. Take a backup and snapshots from your data
Remember that it is not possible to downgrade an Elasticsearch node, so the only way to practically reverse a failed upgrade is to create a new cluster with the old version and recover your data from snapshots. Therefore, it is essential to take snapshots of all Elasticsearch indices before starting the upgrade process.
As an extra precaution, it is also advisable to export any Kibana visualizations to file.
Reindex any version 2 indices
Elasticsearch 6 can only support the indices created in version 5 or 6 , so if you have any indices that were created in version 1 or 2.x.x, you must reindex them. The upgraded node will not join the cluster if you have any version 1 or 2 indices.
If you have X-Pack installed, the Upgrade Assistant will show you the indices you need to reindex. However, if you don’t have X-Pack, then you can check the Elasticsearch index version like this:
GET my-new-index-1/_settings
Result:
{ "my-new-index-1" : { "settings" : { "index" : { . . . "version" : { "created" : "6082399" }, } } } }
To interpret the “created” field:
“Created”: “XXYYZZAA” // - XX is major version ⇒ here is major version 6, do not consider the zero // - YY is minor version ⇒ here is minor version 08 // - ZZ is revision ⇒ here is revision 23
So, based on the created field, you can see the index version is 6.8.23.
Upgrading nodes in a rolling upgrade
The process for upgrading your nodes is as follows, with all NON-master-eligible nodes upgraded first.
How to upgrade nodes in a rolling upgrade
- Make sure your cluster is stable, green
You need to make sure that all replicas are available in order to ensure that shutting down the node will not result in a loss of data.
- Disable unnecessary indexing
Wherever it is practically feasible to do so, you should stop all indexing processes because that will increase cluster stability.
- Disable shard allocation
It is important to stop shards reallocating so that when you stop a node for the upgrade the cluster does not reallocate shards to another node (see the command below).
- Stop Elasticsearch
- Remove old plugins (especially X-Pack, if installed)
- Upgrade Elasticsearch
The method used to upgrade will depend upon the installation method used to install.
- Upgrade plugins
Elasticsearch will not start if the plugin is not exactly the same version as Elasticsearch.
- Start Elasticsearch
- Re-enable shard allocation
Using the command given below.
- Check that the upgraded node has rejoined the cluster
Using the command below, you can check how many nodes are in the cluster.
- Wait for cluster status to turn green
The command provided below will also show you the progress of the shard recovery process on the upgraded node until the cluster reaches a green state.
Do not be in a hurry to upgrade your nodes, wait for the cluster to fully recover before moving on. If the cluster does not go green, look in the logs to find any issues that may indicate problems with the upgrade or configuration. - Repeat
Repeat the full process above for each node.
To stop a node:
systemctl stop elasticsearch
To disable shard allocation, run:
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } }
To remove plugins, e.g., X-Pack:
bin/elasticsearch-plugin remove x-pack
To reload the daemon after upgrading:
systemctl daemon-reload systemctl enable elasticsearch
To re-enable shard allocation, run:
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
To get cluster status and see how many nodes are in the cluster, use:
GET _cluster/health