anchor.diff:  ++++
   <titleabbrev>Split index</titleabbrev>
   ++++
  +
  +Splits an existing index into a new index with more primary shards.
  +
  +[source,console]
  +----
  +POST /twitter/_split/split-twitter-index
  +{
  +  "settings": {
  +    "index.number_of_shards": 2
  +  }
  +}
  +----
  +// TEST[s/^/PUT twitter\n{"settings":{"blocks.write":true}}\n/]
  +
  +
  +[[split-index-api-request]]
  +==== {api-request-title}
  +
  +`POST /<index>/_shrink/<target-index>`
  +
  +`PUT /<index>/_shrink/<target-index>`
  +
  +
  +[[split-index-api-prereqs]]
  +==== {api-prereq-title}
  +
  +
  +Before you can split an index:
  +
  +* The index must be read-only.
  +* The <<cluster-health, cluster health>> status must be green.
  +
  +You can do make an index read-only
  +with the following request:
  +
  +[source,console]
  +--------------------------------------------------
  +PUT /my_source_index/_settings
  +{
  +  "settings": {
  +    "index.blocks.write": true <1>
  +  }
  +}
  +--------------------------------------------------
  +// TEST[s/^/PUT my_source_index\n/]
  +
  +<1> Prevents write operations to this index while still allowing metadata
  +    changes like deleting the index.
  +
  +
  +[[split-index-api-desc]]
  +==== {api-description-title}
   
   The split index API allows you to split an existing index into a new index,
   where each original primary shard is split into two or more primary shards in
  
positive.code: properties of the default number of routing shards will then apply to the
  newly split index.
  
  [float]
  ==== How does splitting work?
  
  Splitting works as follows:
  
  * First, it creates a new target index with the same definition as the source
    index, but with a larger number of primary shards.
  
  * Then it hard-links segments from the source index into the target index. (If
    the file system doesn't support hard-linking, then all segments are copied
    into the new index, which is a much more time consuming process.)
  
  * Once the low level files are created all documents will be `hashed` again to delete
    documents that belong to a different shard.
  
  * Finally, it recovers the target index as though it were a closed index which
    had just been re-opened.
  
  [float]
  [[incremental-resharding]]
  ==== Why doesn't Elasticsearch support incremental resharding?
  
  Going from `N` shards to `N+1` shards, aka. incremental resharding, is indeed a
  feature that is supported by many key-value stores. Adding a new shard and
  
negative.code: 
  NOTE: Mappings may not be specified in the `_split` request.
  
  
  [[monitor-split]]
  ==== Monitor the split process
  
  The split process can be monitored with the <<cat-recovery,`_cat recovery`
  API>>, or the <<cluster-health, `cluster health` API>> can be used to wait
  