Full cluster restart upgrade

Full cluster restart upgradeedit

A full cluster restart upgrade requires that you shut all nodes in the cluster down, upgrade them, and restart the cluster. A full cluster restart was required when upgrading to major versions prior to 6.x. Elasticsearch 6.x supports rolling upgrades from Elasticsearch 5.6. Upgrading to 6.x from earlier versions requires a full cluster restart. See the Upgrade paths table to verify the type of upgrade you need to perform.

To perform a full cluster restart upgrade:

  1. 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"
  2. 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.

  3. 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.

  4. Shutdown all nodes.

    • If you are running Elasticsearch with systemd:

      sudo systemctl stop elasticsearch.service
    • If you are running Elasticsearch with SysV init:

      sudo -i service elasticsearch stop
    • If you are running Elasticsearch as a daemon:

      kill $(cat pid)
  5. Upgrade all nodes.

    If you are upgrading from a version prior to 6.3 and use X-Pack then you must remove the X-Pack plugin before upgrading with bin/elasticsearch-plugin remove x-pack. As of 6.3, X-Pack is included in the default distribution so make sure to upgrade to that one. If you upgrade without removing the X-Pack plugin first the node will fail to start. If you did not remove the X-Pack plugin and the node fails to start then you must downgrade to your previous version, remove X-Pack, and then upgrade again. In general downgrading is not supported but in this particular case it is.

    To upgrade using a Debian or RPM package:

    • Use rpm or dpkg to install the new package. All files are installed in the appropriate location for the operating system and Elasticsearch config files are not overwritten.

    To upgrade using a zip or compressed tarball:

    1. Extract the zip or tarball to a new directory. This is critical if you are not using external config and data directories.
    2. Set the ES_PATH_CONF environment variable to specify the location of your external config directory and jvm.options file. If you are not using an external config directory, copy your old configuration over to the new installation.
    3. Set path.data in config/elasticsearch.yml to point to your external data directory. If you are not using an external data directory, copy your old data directory over to the new installation.

      If you use X-Pack monitoring, re-use the data directory when you upgrade Elasticsearch. Monitoring identifies unique Elasticsearch nodes by using the persistent UUID, which is stored in the data directory.

    4. Set path.logs in config/elasticsearch.yml to point to the location where you want to store your logs. If you do not specify this setting, logs are stored in the directory you extracted the archive to.

    When you extract the zip or tarball packages, the elasticsearch-n.n.n directory contains the Elasticsearch config, data, logs and plugins directories.

    We recommend moving these directories out of the Elasticsearch directory so that there is no chance of deleting them when you upgrade Elasticsearch. To specify the new locations, use the ES_PATH_CONF environment variable and the path.data and path.logs settings. For more information, see Important Elasticsearch configuration.

    The Debian and RPM packages place these directories in the appropriate place for each operating system. In production, we recommend installing using the deb or rpm package.

  6. 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.

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

  8. 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.

  9. 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
  10. 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.

    Native realm users cannot authenticate until the index is upgraded. For instructions, see Upgrading internal indices. You also need to upgrade the .security index if you restore a pre-5.6 snapshot to a fresh 6.0 install.

  11. 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