76 lines
3.1 KiB
Plaintext
76 lines
3.1 KiB
Plaintext
[[recovery]]
|
|
=== Index recovery settings
|
|
|
|
Peer recovery syncs data from a primary shard to a new or existing shard copy.
|
|
|
|
Peer recovery automatically occurs when {es}:
|
|
|
|
* Recreates a shard lost during node failure
|
|
* Relocates a shard to another node due to a cluster rebalance or changes to the
|
|
<<modules-cluster, shard allocation settings>>
|
|
|
|
You can view a list of in-progress and completed recoveries using the
|
|
<<cat-recovery, cat recovery API>>.
|
|
|
|
[discrete]
|
|
[[recovery-settings]]
|
|
==== Recovery settings
|
|
|
|
`indices.recovery.max_bytes_per_sec`::
|
|
(<<cluster-update-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-tier, cold>> or
|
|
<<frozen-tier, frozen>> node, in which case the default relates to the
|
|
total memory available to the node:
|
|
+
|
|
[options="header"]
|
|
|======
|
|
|Total memory | Default recovery rate on cold and frozen nodes
|
|
|≤ 4 GB | 40 MB/s
|
|
|> 4 GB and ≤ 8 GB | 60 MB/s
|
|
|> 8 GB and ≤ 16 GB | 90 MB/s
|
|
|> 16 GB and ≤ 32 GB | 125 MB/s
|
|
|> 32 GB | 250 MB/s
|
|
|======
|
|
+
|
|
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 destabilize the cluster.
|
|
+
|
|
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,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 <<overview-index-lifecycle-management,Index Lifecycle Management>>
|
|
then you may be able to give your hot nodes a higher recovery bandwidth limit
|
|
than your warm nodes.
|
|
|
|
[discrete]
|
|
==== Expert peer recovery settings
|
|
You can use the following _expert_ setting to manage resources for peer
|
|
recoveries.
|
|
|
|
`indices.recovery.max_concurrent_file_chunks`::
|
|
(<<cluster-update-settings,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`.
|
|
|
|
`indices.recovery.max_concurrent_operations`::
|
|
(<<cluster-update-settings,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.
|
|
|