2015-06-22 17:49:45 -04:00
|
|
|
[[recovery]]
|
2020-06-01 09:44:32 -04:00
|
|
|
=== Index recovery settings
|
2015-06-22 17:49:45 -04:00
|
|
|
|
2020-04-02 13:14:34 -04:00
|
|
|
Peer recovery syncs data from a primary shard to a new or existing shard copy.
|
2019-04-26 10:23:30 -04:00
|
|
|
|
|
|
|
|
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>>.
|
|
|
|
|
|
2020-07-23 12:42:33 -04:00
|
|
|
[discrete]
|
2020-07-01 06:19:29 -04:00
|
|
|
==== Recovery settings
|
2019-04-26 10:23:30 -04:00
|
|
|
|
2020-04-02 13:14:34 -04:00
|
|
|
`indices.recovery.max_bytes_per_sec`::
|
|
|
|
|
(<<cluster-update-settings,Dynamic>>) Limits total inbound and outbound
|
2020-07-01 06:19:29 -04:00
|
|
|
recovery traffic for each node. Applies to both peer recoveries as well
|
|
|
|
|
as snapshot recoveries (i.e., restores from a snapshot). Defaults to `40mb`.
|
2019-04-26 10:23:30 -04:00
|
|
|
+
|
2020-04-02 13:14:34 -04:00
|
|
|
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.
|
2019-04-26 10:23:30 -04:00
|
|
|
+
|
2020-04-02 13:14:34 -04:00
|
|
|
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.
|
2019-04-26 10:23:30 -04:00
|
|
|
|
2020-07-23 12:42:33 -04:00
|
|
|
[discrete]
|
2019-04-26 10:23:30 -04:00
|
|
|
==== Expert peer recovery settings
|
|
|
|
|
You can use the following _expert_ setting to manage resources for peer
|
|
|
|
|
recoveries.
|
|
|
|
|
|
2020-04-02 13:14:34 -04:00
|
|
|
`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`.
|
2019-04-26 10:23:30 -04:00
|
|
|
+
|
|
|
|
|
You can increase the value of this setting when the recovery of a single shard
|
2020-04-02 13:14:34 -04:00
|
|
|
is not reaching the traffic limit set by `indices.recovery.max_bytes_per_sec`.
|
2020-07-07 22:03:31 -04:00
|
|
|
|
|
|
|
|
`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.
|
|
|
|
|
|
