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"
}
}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?vThe 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
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
Imbalanced loads on a cluster — optimize shard allocation to prevent the imbalance from recurring
Upgrade the cluster configuration — scale up if load remains high after rebalancing