All Products
Search

This Product

    Elasticsearch:Uneven distribution of hot data on nodes

    Document Center

    Elasticsearch:Uneven distribution of hot data on nodes

    Last Updated:Aug 22, 2026

    When some nodes handle significantly more hot data than others, those nodes run under high load while the rest of the cluster sits idle. This topic explains how to diagnose the imbalance and fix it by manually migrating shards.

    Symptoms

    You are likely experiencing this issue if you notice any of the following:

    • A high-load node holds a disproportionate number of shards with the same attribute—for example, only primary shards

    • A high-load node holds more shards for business indexes than other nodes do

    Before you begin

    Manual shard migration is a temporary fix. If nodes leave the cluster briefly and shard reallocation runs, the imbalance may return. Before migrating shards, address the root cause by following the guidance in Imbalanced loads on a cluster.

    If shards are already evenly distributed but the cluster is still under high load, upgrade the cluster configuration instead.

    Migrate shards manually

    Step 1: Disable shard allocation

    Run the following command to temporarily disable shard allocation. This prevents Elasticsearch from moving shards automatically while you perform the manual migration.

    PUT /_cluster/settings
{
  "transient" : {
     "cluster.routing.allocation.enable" : "none"
  }
}
    Important

    Re-enable shard allocation after the migration is complete (step 4). Leaving shard allocation disabled can affect cluster recovery and resilience.

    Step 2: Migrate the shard

    Use the cluster reroute API to move a specific shard from one node to another. The following example moves Shard 3 of the index_parkingorder_v1 index from 192.168.130.77 to 192.168.130.78.

    POST /_cluster/reroute
{
 "commands" : [
  {
   "move" : {
    "index" : "index_parkingorder_v1",
    "shard" : 3,
    "from_node" : "192.168.130.77",
    "to_node" : "192.168.130.78"
   }
  }
 ]
}

    Constraint: The target node must not already hold a shard of the same index with the same sequence number. For example, if Replica Shard 3 of an index is on Node A, Primary Shard 3 of that index cannot be migrated to Node A.

    For the full reroute API reference, see cluster-reroute.

    Step 3: Verify the migration

    Run the following command to check the current shard allocation:

    GET _cat/shards?v

    The output lists each shard with its state and the node it is assigned to. Look for the migrated shard in the output and confirm that:

    • It appears on the target node

    • Its state is STARTED

    The following is a sample output:

    index        shard prirep state       docs    store   ip     node
qosgeoname   4     r      STARTED     2279054 623.8mb 10.6.xxx y3m8a_2
qosgeoname   4     p      STARTED     2279054 628.8mb 10.6.xxx Xwhpjaf
qosgeoname   3     r      RELOCATING  2279002 627.3mb 10.6.xxx 4Mh39az -> 10.6.xxx y3m8a_2tTdi_16TAy7B91w y3m8a_2
qosgeoname   3     p      STARTED     2279002 626.4mb 10.6.xxx Xwhpjaf
qosgeoname   1     r      STARTED     2278983 623.3mb 10.6.xxx I8SRFdj
qosgeoname   1     p      STARTED     2278983 621.6mb 10.6.xxx Qn3qSgY
qosgeoname   2     p      STARTED     2280694  623mb  10.6.xxx Qn3qSgY
qosgeoname   2     r      STARTED     2280694 622.7mb 10.6.xxx 4Mh39az
qosgeoname   0     p      STARTED     2278770         10.6.xxx I8SRFdj
qosgeoname   0     r      STARTED     2278770 624.3mb 10.6.xxx y3m8a_2

    Step 4: Re-enable shard allocation

    After confirming the migration, re-enable shard allocation:

    PUT /_cluster/settings
{
 "transient" : {
  "cluster.routing.allocation.enable" : "all"
 }
}

    What's next