Cluster decommission

The cluster decommission operation adds support decommissioning based on awareness. It greatly benefits multi-zone deployments, where awareness attributes, such as zones, can aid in applying new upgrades to a cluster in a controlled fashion. This is especially useful during outages, in which case, you can decommission the unhealthy zone to prevent replication requests from stalling and prevent your request backlog from becoming too large.

For more information about allocation awareness, see Shard allocation awareness.

HTTP and Path methods

  1. PUT  /_cluster/decommission/awareness/{awareness_attribute_name}/{awareness_attribute_value}
  2. GET  /_cluster/decommission/awareness/{awareness_attribute_name}/_status
  3. DELETE /_cluster/decommission/awareness

URL parameters

ParameterTypeDescription
awareness_attribute_nameStringThe name of awareness attribute, usually zone.
awareness_attribute_valueStringThe value of the awareness attribute. For example, if you have shards allocated in two different zones, you can give each zone a value of zone-a or zoneb. The cluster decommission operation decommissions the zone listed in the method.

Example: Decommissioning and recommissioning a zone

You can use the following example requests to decommission and recommission a zone:

Request

The following example request decommissions zone-a:

  1. PUT /_cluster/decommission/awareness/<zone>/<zone-a>

copy

If you want to recommission a decommissioned zone, you can use the DELETE method:

  1. DELETE /_cluster/decommission/awareness

copy

Response

  1. {
  2.       "acknowledged": true
  3. }

Example: Getting zone decommission status

The following example requests returns the decommission status of all zones.

Request

  1. GET /_cluster/decommission/awareness/zone/_status

copy

Response

  1. {
  2.      "zone-1": "INIT | DRAINING | IN_PROGRESS | SUCCESSFUL | FAILED"
  3. }

Next steps