Disable an Elasticsearch data tier

From the Deployments page, select your deployment.

Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.

Filter the list of instances by the Data tier you want to disable.

Note the listed instance IDs. In this example, it would be Instance 2 and Instance 3.

Updating data tier based allocation inclusion rules.

Data tier based ILM policies use index.routing.allocation.include to allocate shards to the appropriate tier. The indices that use this method have index routing settings similar to the following example:

{
...
    "routing": {
        "allocation": {
            "include": {
                "_tier_preference": "data_warm,data_hot"
            }
        }
    }
...
}

You must remove the relevant tier from the inclusion rules. For example, to disable the warm tier, the data_warm tier preference should be removed:

PUT /my-index/_settings
{
    "routing": {
      "allocation": {
        "include": {
            "_tier_preference": "data_hot"
        }
      }
    }
}

Updating allocation inclusion rules will trigger a shard re-allocation, moving the shards from the nodes to be removed.

Updating node attribute allocation requirement rules.

Node attribute based ILM policies uses index.routing.allocation.require to allocate shards to the appropriate nodes. The indices that use this method have index routing settings that are similar to the following example:

{
...
    "routing": {
        "allocation": {
            "require": {
                "data": "warm"
            }
        }
    }
...
}

You must either remove or redefine the routing requirements. To remove the attribute requirements, use the following code:

PUT /my-index/_settings
{
    "routing": {
      "allocation": {
        "require": {
            "data": null
        }
      }
    }
}

Removing required attributes does not trigger a shard reallocation. These shards are moved when applying the plan to disable the data tier. Alternatively, you can use the cluster re-route API to manually re-allocate the shards before removing the nodes, or explicitly re-allocate shards to hot nodes by using the following code:

PUT /my-index/_settings
{
    "routing": {
      "allocation": {
        "require": {
            "data": "hot"
        }
      }
    }
}

Removing custom allocation rules.

If indices on nodes to be removed have shard allocation rules of other forms, they must be removed as shown in the following example:

PUT /my-index/_settings
{
    "routing": {
      "allocation": {
        "require": null,
        "include": null,
        "exclude": null
      }
    }
}

The index name of the searchable snapshots may differ based on the data tier. If you intend to disable the cold tier, then perform the following request with the restored-* prefix. If the frozen tier is the one to be disabled, use the partial-* prefix.

GET <searchable-snapshot-index-prefix>/_settings?filter_path=**.index.store.snapshot.snapshot_name&expand_wildcards=all

In the example we have a list of 4 indices, which need to be moved away from the frozen tier.

Optionally, specify the desired number of replica shards.

POST _snapshot/found-snapshots/<searchable_snapshot_name>/_restore
{
  "indices": "*",
  "index_settings": {
    "index.routing.allocation.include._tier_preference": "<data_tiers>",
    "number_of_replicas": X,
    "index.lifecycle.name": "<new-policy-name>",
    "index.lifecycle.rollover_alias": "<alias-for-rollover>"
  }
}

The <searchable_snapshot_name> refers to the above-mentioned step: "Capture a comprehensive list of index and searchable snapshot names".

In the example we are restoring frozen-index-1 from the snapshot in found-snapshots (default snapshot repository) and placing it in the warm tier.

Bulk select the snapshots and delete them

In the example we are deleting the snapshots associated with the policy_with_frozen_phase.