[DOCS] Replaces CCR terms with attributes (#39516)
This commit is contained in:
parent
efd7003ea9
commit
26983d1fdf
|
@ -1,7 +1,7 @@
|
|||
[role="xpack"]
|
||||
[testenv="platinum"]
|
||||
[[ccr-apis]]
|
||||
== Cross-cluster replication APIs
|
||||
== {ccr-cap} APIs
|
||||
|
||||
You can use the following APIs to perform {ccr} operations.
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
[role="xpack"]
|
||||
[testenv="platinum"]
|
||||
[[ccr-get-stats]]
|
||||
=== Get cross-cluster replication stats API
|
||||
=== Get {ccr} stats API
|
||||
++++
|
||||
<titleabbrev>Get CCR stats</titleabbrev>
|
||||
++++
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
[role="xpack"]
|
||||
[testenv="platinum"]
|
||||
[[xpack-ccr]]
|
||||
= Cross-cluster replication
|
||||
= {ccr-cap}
|
||||
|
||||
[partintro]
|
||||
--
|
||||
|
|
|
@ -3,7 +3,8 @@
|
|||
[[ccr-overview]]
|
||||
== Overview
|
||||
|
||||
Cross-cluster replication is done on an index-by-index basis. Replication is
|
||||
|
||||
{ccr-cap} is done on an index-by-index basis. Replication is
|
||||
configured at the index level. For each configured replication there is a
|
||||
replication source index called the _leader index_ and a replication target
|
||||
index called the _follower index_.
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
[[ccr-requirements]]
|
||||
=== Requirements for leader indices
|
||||
|
||||
Cross-cluster replication works by replaying the history of individual write
|
||||
{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
|
||||
history of these operations needs to be retained on the leader shards so that
|
||||
they can be pulled by the follower shard tasks. The underlying mechanism used to
|
||||
|
|
|
@ -27,6 +27,12 @@
|
|||
chosen automatically by the cluster and which can be replaced if the
|
||||
current master node fails.
|
||||
|
||||
[[glossary-ccr]] {ccr} (CCR)::
|
||||
|
||||
The {ccr} feature enables you to replicate indices in remote clusters to your
|
||||
local cluster. For more information, see
|
||||
{stack-ov}/xpack-ccr.html[{ccr-cap}].
|
||||
|
||||
[[glossary-document]] document ::
|
||||
|
||||
A document is a JSON document which is stored in Elasticsearch. It is
|
||||
|
@ -42,12 +48,6 @@
|
|||
<<glossary-source_field,`_source` field>>, which is returned by default when
|
||||
getting or searching for a document.
|
||||
|
||||
[[glossary-id]] id ::
|
||||
|
||||
The ID of a <<glossary-document,document>> identifies a document. The
|
||||
`index/id` of a document must be unique. If no ID is provided,
|
||||
then it will be auto-generated. (also see <<glossary-routing,routing>>)
|
||||
|
||||
[[glossary-field]] field ::
|
||||
|
||||
A <<glossary-document,document>> contains a list of fields, or key-value
|
||||
|
@ -70,6 +70,17 @@
|
|||
hence it is called a filter. Filters are simple checks for set inclusion or exclusion.
|
||||
In most cases, the goal of filtering is to reduce the number of documents that have to be examined.
|
||||
|
||||
[[glossary-follower-index]] follower index ::
|
||||
|
||||
Follower indices are the target indices for <<glossary-ccr,{ccr}>>. They exist
|
||||
in your local cluster and replicate <<glossary-leader-index,leader indices>>.
|
||||
|
||||
[[glossary-id]] id ::
|
||||
|
||||
The ID of a <<glossary-document,document>> identifies a document. The
|
||||
`index/id` of a document must be unique. If no ID is provided,
|
||||
then it will be auto-generated. (also see <<glossary-routing,routing>>)
|
||||
|
||||
[[glossary-index]] index ::
|
||||
|
||||
An index is like a _table_ in a relational database. It has a
|
||||
|
@ -80,6 +91,12 @@
|
|||
<<glossary-primary-shard,primary shards>> and can have zero or more
|
||||
<<glossary-replica-shard,replica shards>>.
|
||||
|
||||
[[glossary-leader-index]] leader index ::
|
||||
|
||||
Leader indices are the source indices for <<glossary-ccr,{ccr}>>. They exist
|
||||
on remote clusters and are replicated to
|
||||
<<glossary-follower-index,follower indices>>.
|
||||
|
||||
[[glossary-mapping]] mapping ::
|
||||
|
||||
A mapping is like a _schema definition_ in a relational database. Each
|
||||
|
|
|
@ -9,7 +9,7 @@ endif::[]
|
|||
ifdef::include-xpack[]
|
||||
The _remote clusters_ module enables you to establish uni-directional
|
||||
connections to a remote cluster. This functionality is used in
|
||||
{stack-ov}/xpack-ccr.html[cross-cluster replication] and
|
||||
{stack-ov}/xpack-ccr.html[{ccr}] and
|
||||
<<modules-cross-cluster-search,cross-cluster search>>.
|
||||
endif::[]
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
directly to configure and access {xpack} features.
|
||||
|
||||
* <<info-api,Info API>>
|
||||
* <<ccr-apis,Cross-cluster replication APIs>>
|
||||
* <<ccr-apis,{ccr-cap} APIs>>
|
||||
* <<graph-explore-api,Graph Explore API>>
|
||||
* <<freeze-index-api>>, <<unfreeze-index-api>>
|
||||
* <<index-lifecycle-management-api,Index lifecycle management APIs>>
|
||||
|
|
Loading…
Reference in New Issue