Migration between Versions - elasticsearch - elasticsearch tutorial - elastic search
What is Migration between Versions:
- In any system or software, when we are upgrading to 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 new system or to maintain the integrity of data (prevent data from getting corrupt).
- The following are the steps to upgrade Elasticsearch −
- Read breaking changes docs from https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes.html
- Test the upgraded version in your non-production environments like in UAT, E2E, SIT or DEV environment.
- Rollback to previous Elasticsearch version is not possible without data backup. 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 (for 2.x and newer). There is no service outage, when you are using rolling upgrade method for migration.
Old Version | New Version | Upgrading Method |
---|---|---|
0.90.x | 2.x | Full cluster restart |
1.x | 2.x | Full cluster restart |
2.x | 2.y | Rolling upgrade (y > x) |
- Take data backup before migration and follow the instructions to carry out the backup process. The snapshot and restore module can be used to take backup. This module can be used to take a snapshot of index or full cluster and can be stored in remote repository.
learn elasticsearch tutorials - version migration Example
Snapshot and Restore Module:
- Before starting the backup process, a snapshot repository needs to be registered in Elasticsearch.
Note : The above text is a HTTP PUT request to http://localhost:9200/_snapshot/backup1 (there can be an IP address of the remote server instead of the localhost). Rest of the text is request body. You can do this easily using fiddler2 and other web tools in Windows.
- We use shared file system (type: fs) for backup; it needs to be registered in every master and data nodes.
- We just need to add the path.repo variable having path of backup repository as a value.
- After we add the repository path, we need to restart the nodes and then registration can be carried out by executing the following command −
Full Cluster Restart:
This upgrade process includes the following steps −
- Step 1 : Disable shard allocation process and turn off the node.
- In case of upgrading 0.90.x to 1.x use the following request −
- Step 2 : Make a synched flush to Elasticsearch −
- Step 3 : On all nodes, kill all the elastic services.
- Step 4 : Do the following on every node −
- In Debian or Red Hat Node: rmp or dpkg can be used to upgrade the node by installing new packages. Do not overwrite config files.
- In Windows (zip file) or UNIX (tar file): Extract the new version without overwriting the config directory. You can copy the files from old installation or can change path.conf or path.data.
- Step 5 : Initiate the nodes again starting with the master node (nodes with node.master set to true and node.data set to false) in the cluster. Wait for some time to establish a cluster. You can check by monitoring the logs or using the following request −
- Step 6 : Monitor the progress of formation of cluster by using GET _cat/health request and wait for the yellow in response, the response will be something like this −
- Step 7 : Enable the shard allocation process, which was disabled in Step 1, by using the following request −
- In case of upgrading 0.90.x to 1.x, use the following request −
Rolling Upgrades
- It is same like Full cluster restart, except Step 3. Here, you stop one node and upgrade. After upgrading, restart the node and repeat these for the all nodes. After enabling the shard allocation process, it can be monitored by the following request −