61 lines
2.6 KiB
Plaintext
61 lines
2.6 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>>.
|
|
|
|
[float]
|
|
==== 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`.
|
|
+
|
|
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.
|
|
|
|
[float]
|
|
==== 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 chunk requests
|
|
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`.
|
|
|
|
`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.
|
|
|