DBAtlas · Database operations atlas

Shrink an index with too many shards

ElasticsearchIndex Lifecycle

Command

# 1) Block writes on the source and gather all shard copies on one node:
PUT log-2026.09/_settings
{
  "index.number_of_replicas": 0,
  "index.routing.allocation.require._name": "node-1",
  "index.blocks.write": true
}
GET _cluster/health/log-2026.09?wait_for_no_relocating_shards=true&timeout=30m
# 2) Create a new index with fewer shards (the target must be a factor of the source):
POST log-2026.09/_shrink/log-2026.09-shrunk
{
  "settings": {
    "index.number_of_shards": 1,
    "index.number_of_replicas": 1,
    "index.routing.allocation.require._name": null,
    "index.blocks.write": null,
    "index.codec": "best_compression"
  }
}

What it does

Reduces the primary shard count of an index that is no longer written to by hard-linking its segments into a new index; lowers heap and shard count overhead.

When to use it

When daily indices were created with more shards than needed, the shard count limit is near, or before moving old indices to the warm tier.

Caution

The source index is closed to writes during the shrink; apply it only to indices that are no longer written to. The target shard count must be a factor of the source count (8 -> 4, 2 or 1). The node where all copies are gathered needs as much free disk as the source index. With replicas 0 the source shard has a single copy; do not delete the source until the operation finishes and the new index is green.

Open in DBAtlas →

Related