2015-06-22 17:49:45 -04:00
|
|
|
[[recovery]]
|
|
|
|
=== Indices Recovery
|
|
|
|
|
2019-01-09 03:18:25 -05:00
|
|
|
<<cat-recovery,Peer recovery>> is the process used to build a new copy of a
|
|
|
|
shard on a node by copying data from the primary. {es} uses this peer recovery
|
|
|
|
process to rebuild shard copies that were lost if a node has failed, and uses
|
|
|
|
the same process when migrating a shard copy between nodes to rebalance the
|
|
|
|
cluster or to honor any changes to the <<modules-cluster,shard allocation
|
|
|
|
settings>>.
|
|
|
|
|
|
|
|
The following _expert_ setting can be set to manage the resources consumed by
|
|
|
|
peer recoveries:
|
2015-06-22 17:49:45 -04:00
|
|
|
|
|
|
|
`indices.recovery.max_bytes_per_sec`::
|
2019-01-09 03:18:25 -05:00
|
|
|
Limits the total inbound and outbound peer recovery traffic on each node.
|
|
|
|
Since this limit applies on each node, but there may be many nodes
|
|
|
|
performing peer recoveries concurrently, the total amount of peer recovery
|
|
|
|
traffic within a cluster may be much higher than this limit. If you set
|
|
|
|
this limit too high then there is a risk that ongoing peer recoveries will
|
|
|
|
consume an excess of bandwidth (or other resources) which could destabilize
|
|
|
|
the cluster. Defaults to `40mb`.
|
2015-06-22 17:49:45 -04:00
|
|
|
|
2019-01-14 15:14:46 -05:00
|
|
|
`indices.recovery.max_concurrent_file_chunks`::
|
|
|
|
Controls the number of file chunk requests that can be sent in parallel per recovery.
|
|
|
|
As multiple recoveries are already running in parallel (controlled by
|
|
|
|
cluster.routing.allocation.node_concurrent_recoveries), increasing this expert-level
|
|
|
|
setting might only help in situations where peer recovery of a single shard is not
|
|
|
|
reaching the total inbound and outbound peer recovery traffic as configured by
|
|
|
|
indices.recovery.max_bytes_per_sec, but is CPU-bound instead, typically when using
|
|
|
|
transport-level security or compression. Defaults to `2`.
|
|
|
|
|
2017-01-31 07:35:42 -05:00
|
|
|
This setting can be dynamically updated on a live cluster with the
|
2019-01-09 03:18:25 -05:00
|
|
|
<<cluster-update-settings,cluster-update-settings>> API.
|