# Reroute the cluster

**POST /_cluster/reroute**

Manually change the allocation of individual shards in the cluster.
For example, a shard can be moved from one node to another explicitly, an allocation can be canceled, and an unassigned shard can be explicitly allocated to a specific node.

It is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.
For example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.

The cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.
If allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.

The cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.
This scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.

Once the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.


## Servers
- http://api.example.com: http://api.example.com ()


## Authentication methods
- Api key auth
- Basic auth
- Bearer auth


## Parameters


### Query parameters
- **dry_run** (boolean)
  If true, then the request simulates the operation.
  It will calculate the result of applying the commands to the current cluster state and return the resulting cluster state after the commands (and rebalancing) have been applied; it will not actually perform the requested changes.
- **explain** (boolean)
  If true, then the response contains an explanation of why the commands can or cannot run.
- **metric** (string | array[string])
  Limits the information returned to the specified metrics.
- **retry_failed** (boolean)
  If true, then retries allocation of shards that are blocked due to too many subsequent allocation failures.
- **master_timeout** (string)
  Period to wait for a connection to the master node. If no response is received before the timeout expires, the request fails and returns an error.
- **timeout** (string)
  Period to wait for a response. If no response is received before the timeout expires, the request fails and returns an error.

### Body: application/json (object)

- **commands** (array[object])
  Defines the commands to perform.


## Responses
### 200


#### Body: application/json (object)
- **acknowledged** (boolean)

- **explanations** (array[object])

- **state** (object)
  There aren't any guarantees on the output/structure of the raw cluster state.
  Here you will find the internal representation of the cluster, which can
  differ from the external representation.


[Powered by Bump.sh](https://bump.sh)