[role="xpack"]
[[ilm-shrink]]
=== Shrink

Phases allowed: hot, warm.

Sets a source index to <<index-blocks-read-only,read-only>> and shrinks it into
a new index with fewer primary shards. The name of the resulting index is
`shrink-<random-uuid>-<original-index-name>`. This action corresponds to the
<<indices-shrink-index,shrink API>>.

After the `shrink` action, any aliases that pointed to the source index point to
the new shrunken index. If {ilm-init} performs the `shrink` action on a backing
index for a data stream, the shrunken index replaces the source index in the
stream. You cannot perform the `shrink` action on a write index.

To use the `shrink` action in the `hot` phase, the `rollover` action *must* be
present. If no rollover action is configured, {ilm-init} will reject the policy.

[IMPORTANT]
If the shrink action is used on a <<ccr-put-follow,follower index>>, policy
execution waits until the leader index rolls over (or is <<skipping-rollover,
otherwise marked complete>>), then converts the follower index into a regular
index with the <<ilm-unfollow,unfollow>> action before performing the shrink
operation.

[[ilm-shrink-options]]
==== Shrink options

`number_of_shards`::
(Optional, integer)
Number of shards to shrink to.
Must be a factor of the number of shards in the source index. This parameter conflicts with
`max_primary_shard_size`, only one of them may be set.

`max_primary_shard_size`::
(Optional, <<byte-units, byte units>>)
The max primary shard size for the target index. Used to find the optimum number of shards for the target index.
When this parameter is set, each shard's storage in the target index will not be greater than the parameter.
The shards count of the target index will still be a factor of the source index's shards count, but if the parameter
is less than the single shard size in the source index, the shards count for the target index will be equal to the source index's shards count.
For example, when this parameter is set to 50gb, if the source index has 60 primary shards with totaling 100gb, then the
target index will have 2 primary shards, with each shard size of 50gb; if the source index has 60 primary shards
with totaling 1000gb, then the target index will have 20 primary shards; if the source index has 60 primary shards
with totaling 4000gb, then the target index will still have 60 primary shards. This parameter conflicts
with `number_of_shards` in the `settings`, only one of them may be set.


[[ilm-shrink-ex]]
==== Example

[[ilm-shrink-shards-ex]]
===== Set the number of shards of the new shrunken index explicitly

[source,console]
--------------------------------------------------
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}
--------------------------------------------------

[[ilm-shrink-size-ex]]
===== Calculate the optimal number of primary shards for a shrunken index

The following policy uses the `max_primary_shard_size` parameter to
automatically calculate the new shrunken index's primary shard count based on
the source index's storage size.

[source,console]
--------------------------------------------------
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "max_primary_shard_size": "50gb"
          }
        }
      }
    }
  }
}
--------------------------------------------------

[[ilm-shrink-shard-allocation]]
==== Shard allocation for shrink

During a `shrink` action, {ilm-init} allocates the source index's primary shards
to one node. After shrinking the index, {ilm-init} reallocates the shrunken
index's shards to the appropriate nodes based on your allocation rules.

These allocation steps can fail for several reasons, including:

* A node is removed during the `shrink` action.
* No node has enough disk space to host the source index's shards.
* {es} cannot reallocate the shrunken index due to conflicting allocation rules.

When one of the allocation steps fails, {ilm-init} waits for the period set in
<<index-lifecycle-step-wait-time-threshold,`index.lifecycle.step.wait_time_threshold`>>,
which defaults to 12 hours. This threshold period lets the cluster resolve any
issues causing the allocation failure.

If the threshold period passes and {ilm-init} has not yet shrunk the index,
{ilm-init} attempts to allocate the source index's primary shards to another
node. If {ilm-init} shrunk the index but could not reallocate the shrunken
index's shards during the threshold period, {ilm-init} deletes the shrunken
index and re-attempts the entire `shrink` action.
