anchor.diff:      Allocate an unassigned replica shard to a node. Accepts `index` and `shard`
       for index name and shard number, and `node` to allocate the shard to. Takes
       <<modules-cluster,allocation deciders>> into account.
  -
  -[float]
  -==== Retrying failed allocations
  -
  -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 <<cluster-reroute,`reroute`>> API with the `?retry_failed` URI
  -query parameter, which will attempt a single retry round for these shards.
  -
  -[float]
  -==== Forced allocation on unrecoverable errors
  +--
   
   Two more commands are available that allow the allocation of a primary shard to
   a node. These commands should however be used with extreme care, as primary
  -shard allocation is usually fully automatically handled by Elasticsearch.
  -Reasons why a primary shard cannot be automatically allocated include the
  +shard allocation is usually fully automatically handled by {es}. Reasons why a 
  +primary shard cannot be automatically allocated include the
   following:
   
   - A new index was created but there is no node which satisfies the allocation
  
positive.code:     that these implications are well-understood, this command requires the flag
      `accept_data_loss` to be explicitly set to `true`.
  
  
negative.code: [[cluster-reroute]]
  === Cluster Reroute
  
  Changes the allocation of shards in a cluster.
  
  
  [[cluster-reroute-api-request]]
  ==== {api-request-title}
  
  `POST /_cluster/reroute`
  
  
  [[cluster-reroute-api-desc]]
  ==== {api-description-title}
  
  The reroute command allows for manual changes to 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 cancelled, and an unassigned shard can
  be explicitly allocated to a specific node.
  
  It is important to note that after processing any reroute commands {es} 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.
  
  