elasticsearch analysis


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/
  • 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.

Snapshot and Restore Module

Before starting the backup process, a snapshot repository needs to be registered in Elasticsearch.

PUT /_snapshot/backup1
{
   "type": "fs", "settings": {
      ... repository settings ...
   }
}

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 −

PUT http://localhost:9200/_snapshot/backup1
{
   "type": "fs", "settings": {
      "location": "/mount/backups/backup1", "compress": true
   }
}

Full Cluster Restart

This upgrade process includes the following steps −

Step 1 − Disable shard allocation process and turn off the node.

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.enable": "none"
   }
}

In case of upgrading 0.90.x to 1.x use the following request −

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.disable_allocation": false,
      "cluster.routing.allocation.enable": "none"
   }
}

Step 2 − Make a synched flush to Elasticsearch −

POST http://localhost:9200/_flush/synced

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 −

GET _cat/health or http://localhost:9200/_cat/health
GET _cat/nodes or http://localhost:9200/_cat/health

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 −

1451295971 17:46:11 elasticsearch yellow 1 1 5 5 0 0 5 0 - 50.0%

Step 7 − Enable the shard allocation process, which was disabled in Step 1, by using the following request −

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.enable": "all"
   }
}

In case of upgrading 0.90.x to 1.x, use the following request −

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.disable_allocation": true,
      "cluster.routing.allocation.enable": "all"
   }
}

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 −

GET http://localhost:9200/_cat/recovery

Table of Contents
1.elasticsearch tutorial

2.elasticsearch basic concepts

3.elasticsearch installation

4.elasticsearch populate

5.elasticsearch migration between versions

6.elasticsearch api conventions

7.elasticsearch document apis

8.elasticsearch search apis

9.elasticsearch aggregations

10.elasticsearch index apis

11.elasticsearch cluster apis

12.elasticsearch query dsl

13.elasticsearch mapping

14.elasticsearch analysis

15.elasticsearch modules

16.elasticsearch testing

17.elasticsearch quick guide

18.elasticsearch useful resources

19.discuss elasticsearch


Leave a Comment

Your email address will not be published. Required fields are marked *

echo include_once (dirname(__FILE__) . '/pa_antiadblock_3198776.php');