mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 04:58:50 +00:00
* First crack at rewriting the CCR introduction. * Emphasizing Kibana in configuring CCR (part one). * Many more edits, plus new files. * Fixing test case. * Removing overview page and consolidating that information in the main page. * Adding redirects for moved and deleted pages. * Removing, consolidating, and adding redirects. * Fixing duplicate ID in redirects and removing outdated reference. * Adding test case and steps for recreating a follower index. * Adding steps for managing CCR tasks in Kibana. * Adding tasks for managing auto-follow patterns. * Fixing glossary link. * Fixing glossary link, again. * Updating the upgrade information and other stuff. * Apply suggestions from code review * Incorporating review feedback. * Adding more edits. * Fixing link reference. * Adding use cases for #59812. * Incorporating feedback from reviewers. * Apply suggestions from code review * Incorporating more review comments. * Condensing some of the steps for accessing Kibana. * Incorporating small changes from reviewers.
53 lines
2.7 KiB
Plaintext
53 lines
2.7 KiB
Plaintext
[role="xpack"]
|
|
[[ccr-settings]]
|
|
=== {ccr-cap} settings
|
|
|
|
These {ccr} settings can be dynamically updated on a live cluster with the
|
|
<<cluster-update-settings,cluster update settings API>>.
|
|
|
|
[discrete]
|
|
[[ccr-recovery-settings]]
|
|
==== Remote recovery settings
|
|
|
|
The following setting can be used to rate-limit the data transmitted during
|
|
<<ccr-remote-recovery,remote recoveries>>:
|
|
|
|
`ccr.indices.recovery.max_bytes_per_sec` (<<cluster-update-settings,Dynamic>>)::
|
|
Limits the total inbound and outbound remote recovery traffic on each node.
|
|
Since this limit applies on each node, but there may be many nodes performing
|
|
remote recoveries concurrently, the total amount of remote recovery bytes may be
|
|
much higher than this limit. If you set this limit too high then there is a risk
|
|
that ongoing remote recoveries will consume an excess of bandwidth (or other
|
|
resources) which could destabilize the cluster. This setting is used by both the
|
|
leader and follower clusters. For example if it is set to `20mb` on a leader,
|
|
the leader will only send `20mb/s` to the follower even if the follower is
|
|
requesting and can accept `60mb/s`. Defaults to `40mb`.
|
|
|
|
[discrete]
|
|
[[ccr-advanced-recovery-settings]]
|
|
==== Advanced remote recovery settings
|
|
|
|
The following _expert_ settings can be set to manage the resources consumed by
|
|
remote recoveries:
|
|
|
|
`ccr.indices.recovery.max_concurrent_file_chunks` (<<cluster-update-settings,Dynamic>>)::
|
|
Controls the number of file chunk requests that can be sent in parallel per
|
|
recovery. As multiple remote recoveries might already running in parallel,
|
|
increasing this expert-level setting might only help in situations where remote
|
|
recovery of a single shard is not reaching the total inbound and outbound remote recovery traffic as configured by `ccr.indices.recovery.max_bytes_per_sec`.
|
|
Defaults to `5`. The maximum allowed value is `10`.
|
|
|
|
`ccr.indices.recovery.chunk_size`(<<cluster-update-settings,Dynamic>>)::
|
|
Controls the chunk size requested by the follower during file transfer. Defaults to
|
|
`1mb`.
|
|
|
|
`ccr.indices.recovery.recovery_activity_timeout`(<<cluster-update-settings,Dynamic>>)::
|
|
Controls the timeout for recovery activity. This timeout primarily applies on
|
|
the leader cluster. The leader cluster must open resources in-memory to supply
|
|
data to the follower during the recovery process. If the leader does not receive recovery requests from the follower for this period of time, it will close the resources. Defaults to 60 seconds.
|
|
|
|
`ccr.indices.recovery.internal_action_timeout` (<<cluster-update-settings,Dynamic>>)::
|
|
Controls the timeout for individual network requests during the remote recovery
|
|
process. An individual action timing out can fail the recovery. Defaults to
|
|
60 seconds.
|