Performing a cluster restart upgrade process

To upgrade from Elasticsearch version 0.20.1 to Elasticsearch version 1.7.1, you must perform a full cluster stop and start upgrade.

1. Disable shard reallocation, as follows:

   curl -XPUT <local_host>:9200/_cluster/settings -d '{ "persistent" : { "cluster.routing.allocation.disable_allocation" : "true" } }'

   This enables a faster startup after the cluster shutdown. If you do not perform this step, the nodes will immediately try to replicate shards to eachother on startup and will spend a lot of time on wasted I/O. With shard reallocation disabled, the nodes will join the cluster with their indices intact, without attempting to rebalance. After startup is complete, reallocation will be turned back on.
2. Stop all Elasticsearch services on all nodes in the cluster, as follows:

   curl -XPOST 'http://<local_host>:9200/_shutdown'

3. Upgrade one node, as follows:
   1. Copy <INSTALL_DIR>/elasticsearch-1.7.1 to a new directory. This directory will work as the new Elasticsearch installation directory.
      Note: Do not overwrite the existing installation, because the Elasticsearch 1.7.1 distribution also contains a default elasticsearch.yml file and will overwrite your existing configuration.
   2. Re-apply the configurations in the old Elasticsearch installation’s config directory to the new Elasticsearch installation’s config directory. This includes the changes to elasticsearch.yml and logging.yml. You need to re-generate the index mappings and copy them to the config directory. Note that there is no change to the process for generating index mappings in Sterling™ Order Management System Software Release 9.5. However, it has to be regenerated because the mappings setting underwent some changes between Elasticsearch versions 0.20.1 and 1.7.1.
   3. If the data directory is set differently for the old Elasticsearch installation and the new Elasticsearch installation (that is, the path.data setting in elasticsearch.yml), then move data files from the old version’s data directory to the new version’s data directory. It is better to maintain a data directory outside of the Elasticsearch installation and create a symbolic link within the Elasticsearch installation directory that points to the above data directory. This provides a simple solution for moving from one version of Elasticsearch to a newer version by deleting the symbolic link from the old version’s directory and creating it from a new version.
4. Repeat step 3 for all other nodes.
5. After the upgrade of Elasticsearch on all nodes is complete, restart the cluster by starting each node individually, as follows:
   1. Start master-eligible nodes first, one at a time. Verify that a quorum has been reached and a master has been elected before proceeding.
   2. Start data nodes one at a time, and verify that they successfully join the cluster.
   3. Verify whether the cluster is running and that it reaches a yellow state. Enter the following command to check the cluster health and verify its status in the response:

      Command

      curl -XGET 'http://<local_host>:9200/_cluster/health?pretty=true'
      

      Response

      "cluster_name" : "<cluster.name>",
      "status" : "yellow",
      "timed_out" : false,
      "number_of_nodes" : 1,
      "number_of_data_nodes" : 1,
      "active_primary_shards" : 2,
      "active_shards" : 2,
      "relocating_shards" : 0,
      "initializing_shards" : 0,
      "unassigned_shards" : 2

6. Enable shard reallocation, as follows:

   curl -XPUT <local_host>:9200/_cluster/settings -d '{ "persistent" : { "cluster.routing.allocation.enable" : "all" } }'
   
   curl -XPUT <local_host>:9200/_cluster/settings -d '{ "persistent" : { "cluster.routing.allocation.disable_allocation" : "false" } }'

7. Start the client nodes. In case of order search solution, the client nodes reside within the Application Server and the Agent/Integration server JVMs. Therefore, starting Application/Agent/Integration servers will start the client nodes.