Index recovery settings

(Dynamic) Limits total inbound and outbound recovery traffic for each node. Applies to both peer recoveries as well as snapshot recoveries (i.e., restores from a snapshot). Defaults to 40mb unless the node is a dedicated cold or frozen node, in which case the default relates to the total memory available to the node:

This limit applies to each node separately. If multiple nodes in a cluster perform recoveries at the same time, the cluster’s total recovery traffic may exceed this limit.

If this limit is too high, ongoing recoveries may consume an excess of bandwidth and other resources, which can have a performance impact on your cluster and in extreme cases may destabilize it.

This is a dynamic setting, which means you can set it in each node’s elasticsearch.yml config file and you can update it dynamically using the cluster update settings API. If you set it dynamically then the same limit applies on every node in the cluster. If you do not set it dynamically then you can set a different limit on each node, which is useful if some of your nodes have better bandwidth than others. For example, if you are using Index Lifecycle Management then you may be able to give your hot nodes a higher recovery bandwidth limit than your warm nodes.

(Dynamic, Expert) Number of file chunks sent in parallel for each recovery. Defaults to 2.

You can increase the value of this setting when the recovery of a single shard is not reaching the traffic limit set by indices.recovery.max_bytes_per_sec, up to a maximum of 8.

(Dynamic, Expert) Number of operations sent in parallel for each recovery. Defaults to 1.

Concurrently replaying operations during recovery can be very resource-intensive and may interfere with indexing, search, and other activities in your cluster. Do not increase this setting without carefully verifying that your cluster has the resources available to handle the extra load that will result.

(Dynamic, Expert) Enables snapshot-based peer recoveries.

Elasticsearch recovers replicas and relocates primary shards using the peer recovery process, which involves constructing a new copy of a shard on the target node. When indices.recovery.use_snapshots is false Elasticsearch will construct this new copy by transferring the index data from the current primary. When this setting is true Elasticsearch will attempt to copy the index data from a recent snapshot first, and will only copy data from the primary if it cannot identify a suitable snapshot. Defaults to true.

Setting this option to true reduces your operating costs if your cluster runs in an environment where the node-to-node data transfer costs are higher than the costs of recovering data from a snapshot. It also reduces the amount of work that the primary must do during a recovery.

Additionally, repositories having the setting use_for_peer_recovery=true will be consulted to find a good snapshot when recovering a shard. If none of the registered repositories have this setting defined, index files will be recovered from the source node.

(Dynamic, Expert) Number of snapshot file downloads requests sent in parallel to the target node for each recovery. Defaults to 5.

Do not increase this setting without carefully verifying that your cluster has the resources available to handle the extra load that will result.

(Dynamic, Expert) Number of snapshot file downloads requests executed in parallel in the target node for all recoveries. Defaults to 25.

Do not increase this setting without carefully verifying that your cluster has the resources available to handle the extra load that will result.