mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-25 09:28:27 +00:00
[DOCS] Add CCR docs to the Elasticsearch Reference Guide (#45704)
Previously, cross-cluster replication (CCR) documentation was located in the Stack Overview: https://www.elastic.co/guide/en/elastic-stack-overview/master/xpack-ccr.html This adds CCR documentation to the Elasticsearch Reference Guide with a level offset for headings. The level offset and CCR Stack Overview docs will be removed in later commits.
This commit is contained in:
parent
371c355bca
commit
9dcf8a53a2
@ -1,12 +0,0 @@
|
||||
[[administer-elasticsearch]]
|
||||
= Administering {es}
|
||||
|
||||
[partintro]
|
||||
--
|
||||
Elasticsearch is a complex piece of software, with many moving parts. There are
|
||||
many APIs and features that are designed to help you manage your Elasticsearch
|
||||
cluster.
|
||||
|
||||
--
|
||||
|
||||
include::administering/backup-cluster.asciidoc[]
|
@ -1,7 +1,7 @@
|
||||
[role="xpack"]
|
||||
[testenv="platinum"]
|
||||
[[ccr-auto-follow]]
|
||||
=== Automatically following indices
|
||||
== Automatically following indices
|
||||
|
||||
In time series use cases where you want to follow new indices that are
|
||||
periodically created (such as daily Beats indices), manually configuring follower
|
||||
@ -10,7 +10,7 @@ functionality in {ccr} is aimed at easing this burden. With the auto-follow
|
||||
functionality, you can specify that new indices in a remote cluster that have a
|
||||
name that matches a pattern are automatically followed.
|
||||
|
||||
==== Managing auto-follow patterns
|
||||
=== Managing auto-follow patterns
|
||||
|
||||
You can add a new auto-follow pattern configuration with the
|
||||
{ref}/ccr-put-auto-follow-pattern.html[create auto-follow pattern API]. When you create
|
||||
|
@ -20,7 +20,7 @@ This getting-started guide for {ccr} shows you how to:
|
||||
|
||||
. Obtain a license that includes the {ccr} features. See
|
||||
https://www.elastic.co/subscriptions[subscriptions] and
|
||||
<<license-management>>.
|
||||
{stack-ov}/license-management.html[License-management].
|
||||
|
||||
. If the Elastic {security-features} are enabled in your local and remote
|
||||
clusters, you need a user that has appropriate authority to perform the steps
|
||||
@ -34,7 +34,7 @@ to control which users have authority to manage {ccr}.
|
||||
By default, you can perform all of the steps in this tutorial by
|
||||
using the built-in `elastic` user. However, a password must be set for this user
|
||||
before the user can do anything. For information about how to set that password,
|
||||
see <<security-getting-started>>.
|
||||
see {stack-ov}/security-getting-started.html[Tutorial: Getting started with security].
|
||||
|
||||
If you are performing these steps in a production environment, take extra care
|
||||
because the `elastic` user has the `superuser` role and you could inadvertently
|
||||
|
@ -3,9 +3,6 @@
|
||||
[[xpack-ccr]]
|
||||
= {ccr-cap}
|
||||
|
||||
[partintro]
|
||||
--
|
||||
|
||||
The {ccr} (CCR) feature enables replication of indices in remote clusters to a
|
||||
local cluster. This functionality can be used in some common production use
|
||||
cases:
|
||||
@ -22,7 +19,6 @@ This guide provides an overview of {ccr}:
|
||||
* <<ccr-getting-started>>
|
||||
* <<ccr-upgrading>>
|
||||
|
||||
--
|
||||
|
||||
include::overview.asciidoc[]
|
||||
include::requirements.asciidoc[]
|
||||
|
@ -1,7 +1,7 @@
|
||||
[role="xpack"]
|
||||
[testenv="platinum"]
|
||||
[[ccr-requirements]]
|
||||
=== Requirements for leader indices
|
||||
== Requirements for leader indices
|
||||
|
||||
{ccr-cap} works by replaying the history of individual write
|
||||
operations that were performed on the shards of the leader index. This means that the
|
||||
@ -24,7 +24,7 @@ enabled.
|
||||
|
||||
[float]
|
||||
[[ccr-overview-soft-deletes]]
|
||||
==== Soft delete settings
|
||||
=== Soft delete settings
|
||||
|
||||
`index.soft_deletes.enabled`::
|
||||
|
||||
@ -44,7 +44,7 @@ For more information about index settings, see {ref}/index-modules.html[Index mo
|
||||
|
||||
[float]
|
||||
[[ccr-overview-beats]]
|
||||
==== Setting soft deletes on indices created by APM Server or Beats
|
||||
=== Setting soft deletes on indices created by APM Server or Beats
|
||||
|
||||
If you want to replicate indices created by APM Server or Beats, and are
|
||||
allowing APM Server or Beats to manage index templates, you need to configure
|
||||
@ -65,7 +65,7 @@ index template.
|
||||
|
||||
[float]
|
||||
[[ccr-overview-logstash]]
|
||||
==== Setting soft deletes on indices created by Logstash
|
||||
=== Setting soft deletes on indices created by Logstash
|
||||
|
||||
If you want to replicate indices created by Logstash, and are using Logstash to
|
||||
manage index templates, you need to configure soft deletes on a custom Logstash
|
||||
|
35
docs/reference/high-availability.asciidoc
Normal file
35
docs/reference/high-availability.asciidoc
Normal file
@ -0,0 +1,35 @@
|
||||
[[high-availability]]
|
||||
= Set up a cluster for high availability
|
||||
|
||||
[partintro]
|
||||
--
|
||||
As with any software that stores data,
|
||||
it is important to routinely back up your data.
|
||||
{es}'s <<glossary-replica-shard,replica shards>> provide high availability
|
||||
during runtime;
|
||||
they enable you to tolerate sporadic node loss
|
||||
without an interruption of service.
|
||||
|
||||
However, replica shards do not protect an {es} cluster
|
||||
from catastrophic failure.
|
||||
You need a backup of your cluster—
|
||||
a copy in case something goes wrong.
|
||||
|
||||
|
||||
{es} offers two features to support high availability for a cluster:
|
||||
|
||||
* <<backup-cluster,Snapshot and restore>>,
|
||||
which you can use to back up individual indices or entire clusters.
|
||||
You can automatically store these backups in a repository on a shared filesystem.
|
||||
|
||||
* <<xpack-ccr,Cross-cluster replication (CCR)>>,
|
||||
which you can use to copy indices in remote clusters to a local cluster.
|
||||
You can use {ccr} to recover from the failure of a primary cluster
|
||||
or serve data locally based on geo-proximity.
|
||||
--
|
||||
|
||||
include::high-availability/backup-cluster.asciidoc[]
|
||||
|
||||
:leveloffset: +1
|
||||
include::ccr/index.asciidoc[]
|
||||
:leveloffset: -1
|
@ -4,14 +4,6 @@
|
||||
<titleabbrev>Back up the data</titleabbrev>
|
||||
++++
|
||||
|
||||
As with any software that stores data, it is important to routinely back up your
|
||||
data. {es} replicas provide high availability during runtime; they enable you to
|
||||
tolerate sporadic node loss without an interruption of service.
|
||||
|
||||
Replicas do not provide protection from catastrophic failure, however. For that,
|
||||
you need a real backup of your cluster—a complete copy in case something goes
|
||||
wrong.
|
||||
|
||||
To back up your cluster's data, you can use the <<modules-snapshots,snapshot API>>.
|
||||
|
||||
include::{es-repo-dir}/modules/snapshots.asciidoc[tag=snapshot-intro]
|
@ -56,7 +56,7 @@ include::rollup/index.asciidoc[]
|
||||
|
||||
include::frozen-indices.asciidoc[]
|
||||
|
||||
include::administering.asciidoc[]
|
||||
include::high-availability.asciidoc[]
|
||||
|
||||
include::commands/index.asciidoc[]
|
||||
|
||||
|
@ -815,4 +815,8 @@ See <<getting-started-next-steps>>.
|
||||
|
||||
[role="exclude",id="ccs-reduction"]
|
||||
=== {ccs-cap} reduction
|
||||
See <<ccs-works>>.
|
||||
See <<ccs-works>>.
|
||||
|
||||
[role="exclude",id="administer-elasticsearch"]
|
||||
=== Administering {es}
|
||||
See <<high-availability>>.
|
Loading…
x
Reference in New Issue
Block a user