Elasticsearch|Migrations between Versions

Whenever we upgrade our system or any software to a newer version, there are always some changes in them. Therefore, we require to sustain them by maintaining data, application configurations, settings, and many other things. For which we need to follow a few steps to make the application stable in a new system. These steps also help to maintain the integrity of data from being corrupt.

Similarly, elasticsearch is database software that also provides new updates after a certain time. A newer version always offers some changes in the application. So, while upgrading elasticsearch, we require to follow the below steps -

1. Read the updated documentation of elasticsearch from the here https://elastic.co/
2. Test the upgraded version in non-production environments like E2E, DEV, UAT, or in SIT.
3. Remember that without data backup, software degradation is not possible. Means rollback to the previous version is only possible after taking backup of data. Hence, the data backup is must be taken before upgrading to a higher version.
4. It can be upgraded using rolling upgrade or full cluster restart. A rolling upgrade is useful for new version.

Note that there is no service outage while using a rolling upgrade for migration.

Steps to Upgrade

Follow the below steps while upgrading the elasticsearch -

1. Before upgrading the production cluster, test the upgrade in DEV or in another environment.
2. Take the back up of your data before migration. Remember that you are not allowed to roll back to the previous version if you do not have a backup of your data. The snapshot and restore module help to takes backup that take a snapshot of full cluster and store in a remote repository.
   
3. Upgrade the components of elasticsearch in following order:
   1. Elasticsearch
   2. Elasticsearch plugin (which you installed with elasticsearch database such as - elasticsearch-head plugin, or Kibana, etc.
4. A snapshot repository needs to be registered in elasticsearch database before starting the backup process.

Register Snapshot repository

Execute the below code to register the snapshot repository:

Copy Code

In the above syntax of repository setting, PUT is an HTTP request method used to send a request to http://localhost:9200/_snapshot/backup1 and the remaining text is request body.

• In the request body section, we pass "type": "fs" shard file system for backup. It must be registered in every data and master node.
• In the next statement, we provide a path of backup repository to take backup.
• We need to restart the node to carried out the registration by executing the above query.

Full cluster restart

The process of full cluster restart contains a number of high-level steps to complete it successfully. In this, we shut down all the nodes in the cluster and upgrade them. In the end, we need to restart the cluster for normal processing.

Follow the steps given below:

Step 1: Turn off the node and disable shard allocation using the below command.

Copy Code

Response

Step 2: Now, stop indexing and make a synced flush in elasticsearch using the following code.

Copy Code

Step 3: Shutdown all nodes by killing all the elastic service on each node.

Step 4: Now, upgrade all nodes.

Step 5: Upgrade the plugin of elasticsearch, if any.

Step 6: Start all the upgraded nodes.

Step 7: Wait for all nodes until they join the cluster and the cluster status change to Yellow.

Step 8: Now, re-enable the allocation.

The cluster starts the allocation of replica shards to the data nodes, once the allocation is re-enabled successfully. Now we can resume indexing and searching because there is no need to be concerned at this point. Remember one thing, the cluster can recover more quickly if all primary and replica shards have been allocated successfully and the status of all nodes is green.