Full cluster restart upgrade

Disable shard allocation.

When you shut down a node, the allocation process waits for index.unassigned.node_left.delayed_timeout (by default, one minute) before starting to replicate the shards on that node to other nodes in the cluster, which can involve a lot of I/O. Since the node is shortly going to be restarted, this I/O is unnecessary. You can avoid racing the clock by disabling allocation of replicas before shutting down the node:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

Stop indexing and perform a synced flush.

Performing a synced-flush speeds up shard recovery.

POST _flush/synced

When you perform a synced flush, check the response to make sure there are no failures. Synced flush operations that fail due to pending indexing operations are listed in the response body, although the request itself still returns a 200 OK status. If there are failures, reissue the request.

Stop any machine learning jobs that are running.

If your machine learning indices were created earlier than the previous major version, they must be reindexed. In those circumstances, there must be no machine learning jobs running during the upgrade.

In all other circumstances, there is no requirement to close your machine learning jobs. There are, however, advantages to doing so. If you choose to leave your jobs running during the upgrade, they are affected when you stop the machine learning nodes. The jobs move to another machine learning node and restore the model states. This scenario has the least disruption to the active machine learning jobs but incurs the highest load on the cluster.

To close all machine learning jobs before you upgrade, see Stopping machine learning. This method persists the model state at the moment of closure, which means that when you open your jobs after the upgrade, they use the exact same model. This scenario takes the most time, however, especially if you have many jobs or jobs with large model states.

To temporarily halt the tasks associated with your machine learning jobs and datafeeds and prevent new jobs from opening, use the set upgrade mode API:

POST _ml/set_upgrade_mode?enabled=true

This method does not persist the absolute latest model state, rather it uses the last model state that was automatically saved. By halting the tasks, you avoid incurring the cost of managing active jobs during the upgrade and it’s quicker than stopping datafeeds and closing jobs.

Shutdown all nodes.

Upgrade all nodes.

To upgrade using a Debian or RPM package:

To upgrade using a zip or compressed tarball:

Upgrade any plugins.

Use the elasticsearch-plugin script to install the upgraded version of each installed Elasticsearch plugin. All plugins must be upgraded when you upgrade a node.

Start each upgraded node.

If you have dedicated master nodes, start them first and wait for them to form a cluster and elect a master before proceeding with your data nodes. You can check progress by looking at the logs.

As soon as the minimum number of master-eligible nodes have discovered each other, they form a cluster and elect a master. At that point, you can use _cat/health and _cat/nodes to monitor nodes joining the cluster:

GET _cat/health

GET _cat/nodes

The status column returned by _cat/health shows the health of each node in the cluster: red, yellow, or green.

Wait for all nodes to join the cluster and report a status of yellow.

When a node joins the cluster, it begins to recover any primary shards that are stored locally. The _cat/health API initially reports a status of red, indicating that not all primary shards have been allocated.

Once a node recovers its local shards, the cluster status switches to yellow, indicating that all primary shards have been recovered, but not all replica shards are allocated. This is to be expected because you have not yet reenabled allocation. Delaying the allocation of replicas until all nodes are yellow allows the master to allocate replicas to nodes that already have local shard copies.

Reenable allocation.

When all nodes have joined the cluster and recovered their primary shards, reenable allocation by restoring cluster.routing.allocation.enable to its default:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

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

You can monitor progress with the _cat/health and _cat/recovery APIs:

GET _cat/health

GET _cat/recovery

If you use X-Pack security and are upgrading directly to 6.7.2 from 5.5 or earlier, you must upgrade the .security index after you restart Elasticsearch.

Restart machine learning jobs.

If you closed all machine learning jobs before the upgrade, you must open them. Use Kibana or the open jobs API.

Alternatively, if you temporarily halted the tasks associated with your machine learning jobs, use the set upgrade mode API to return them to active states:

POST _ml/set_upgrade_mode?enabled=false