Elasticsearch - Migration between Versions

Elasticsearch Migration between Versions in any system or software, when we are upgrading to a newer version, we need to follow a few steps to maintain the application settings, configurations, data, and other things. These steps are required to make the application stable in a new system or to maintain the integrity of data (prevent data from getting corrupt).

You need to follow the following steps to upgrade Elasticsearch −

Read Upgrade docs from https://www.elastic.co/
Test the upgraded version in your non production environments like in UAT, E2E, SIT or DEV environment.
Note that rollback to previous Elasticsearch version is not possible without data backup. Hence, a data backup is recommended before upgrading to a higher version.
We can upgrade using full cluster restart or rolling upgrade. Rolling upgrade is for new versions. Note that there is no service outage, when you are using rolling upgrade method for migration.

Steps for Upgrade in Elasticsearch Migration between Versions

Test the upgrade in a dev environment before upgrading your production cluster.
Back up your data. You cannot roll back to an earlier version unless you have a snapshot of your data.
Consider closing machine learning jobs before you start the upgrade process. While machine learning jobs can continue to run during a rolling upgrade, it increases the overhead on the cluster during the upgrade process.
Upgrade the components of your Elastic Stack in the following order −
- Elasticsearch
- Kibana
- Logstash
- Beats
- APM Server

Upgrading from 6.6 or Earlier

To upgrade directly to Elasticsearch 7.1.0 from versions 6.0-6.6, you must manually reindex any 5.x indices you need to carry forward and perform a full cluster restart.

Full Cluster Restart

The process of full cluster restart involves shutting down each node in the cluster, upgrading each node to 7x, and then restarting the cluster.

Following are the high-level steps that need to be carried out for full cluster restart −

Disable shard allocation
Stop indexing and perform a synced flush
Shutdown all nodes
Upgrade all nodes
Upgrade any plugins
Start each upgraded node
Wait for all nodes to join the cluster and report a status of yellow
Re-enable allocation

Once the allocation is re-enabled, the cluster starts allocating the 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.

Next Topic – Click Here