2018-10-26 23:23:35 +08:00
[role="xpack"]
[testenv="platinum"]
[[ccr-getting-started]]
2019-09-18 21:44:28 +08:00
=== Getting started with {ccr}
2018-10-26 23:23:35 +08:00
2018-11-13 19:45:00 +08:00
This getting-started guide for {ccr} shows you how to:
* <<ccr-getting-started-remote-cluster,Connect a local cluster to a remote
cluster>>
* <<ccr-getting-started-leader-index,Create a leader index>> in a remote cluster
* <<ccr-getting-started-follower-index,Create a follower index>> that replicates
a leader index
* <<ccr-getting-started-auto-follow,Automatically create follower indices>>
2019-09-18 21:44:28 +08:00
2018-11-13 19:45:00 +08:00
[[ccr-getting-started-before-you-begin]]
2019-09-18 21:44:28 +08:00
==== Before you begin
2018-11-13 19:45:00 +08:00
. {stack-gs}/get-started-elastic-stack.html#install-elasticsearch[Install {es}]
on your local and remote clusters.
. Obtain a license that includes the {ccr} features. See
https://www.elastic.co/subscriptions[subscriptions] and
2020-06-17 07:43:54 +08:00
{kibana-ref}/managing-licenses.html[License management].
2018-11-13 19:45:00 +08:00
2018-11-13 19:48:56 +08:00
. If the Elastic {security-features} are enabled in your local and remote
2018-11-13 19:45:00 +08:00
clusters, you need a user that has appropriate authority to perform the steps
in this tutorial.
+
--
[[ccr-getting-started-security]]
The {ccr} features use cluster privileges and built-in roles to make it easier
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,
2019-10-05 07:10:26 +08:00
see <<security-getting-started>>.
2018-11-13 19:45:00 +08:00
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
2018-11-13 19:48:56 +08:00
make significant changes.
2018-11-13 19:45:00 +08:00
Alternatively, you can assign the appropriate privileges to a user ID of your
choice. On the remote cluster that contains the leader index, a user will need
the `read_ccr` cluster privilege and `monitor` and `read` privileges on the
leader index.
[source,yml]
--------------------------------------------------
ccr_user:
cluster:
- read_ccr
indices:
- names: [ 'leader-index' ]
privileges:
- monitor
- read
--------------------------------------------------
On the local cluster that contains the follower index, the same user will need
the `manage_ccr` cluster privilege and `monitor`, `read`, `write` and
`manage_follow_index` privileges on the follower index.
[source,yml]
--------------------------------------------------
ccr_user:
cluster:
- manage_ccr
indices:
- names: [ 'follower-index' ]
privileges:
- monitor
- read
- write
- manage_follow_index
--------------------------------------------------
If you are managing
<<ccr-getting-started-remote-cluster,connecting to the remote cluster>> via the
cluster update settings API, you will also need a user with the `all` cluster
privilege.
--
2019-09-18 21:44:28 +08:00
2018-11-13 19:45:00 +08:00
[[ccr-getting-started-remote-cluster]]
2019-09-18 21:44:28 +08:00
==== Connecting to a remote cluster
2018-11-13 19:45:00 +08:00
2018-11-13 19:48:56 +08:00
The {ccr} features require that you
2018-11-13 19:45:00 +08:00
{ref}/modules-remote-clusters.html[connect your local cluster to a remote
cluster]. In this tutorial, we will connect our local cluster to a remote
cluster with the cluster alias `leader`.
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
PUT /_cluster/settings
{
"persistent" : {
"cluster" : {
"remote" : {
"leader" : {
"seeds" : [
"127.0.0.1:9300" <1>
]
}
}
}
}
}
--------------------------------------------------
// TEST[setup:host]
// TEST[s/127.0.0.1:9300/\${transport_host}/]
<1> Specifies the hostname and transport port of a seed node in the remote
2018-11-13 19:48:56 +08:00
cluster.
2018-11-13 19:45:00 +08:00
You can verify that the local cluster is successfully connected to the remote
cluster.
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
GET /_remote/info
--------------------------------------------------
// TEST[continued]
The API will respond by showing that the local cluster is connected to the
remote cluster.
2019-09-06 04:47:18 +08:00
[source,console-result]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
{
"leader" : {
"seeds" : [
"127.0.0.1:9300"
],
"connected" : true, <1>
"num_nodes_connected" : 1, <2>
"max_connections_per_cluster" : 3,
"initial_connect_timeout" : "30s",
2019-12-14 00:16:53 +08:00
"skip_unavailable" : false,
"mode" : "sniff"
2018-11-13 19:45:00 +08:00
}
}
--------------------------------------------------
2019-09-06 04:47:18 +08:00
// TESTRESPONSE[s/127.0.0.1:9300/$body.leader.seeds.0/]
2018-11-13 19:45:00 +08:00
// TEST[s/"connected" : true/"connected" : $body.leader.connected/]
// TEST[s/"num_nodes_connected" : 1/"num_nodes_connected" : $body.leader.num_nodes_connected/]
<1> This shows the local cluster is connected to the remote cluster with cluster
alias `leader`
<2> This shows the number of nodes in the remote cluster the local cluster is
connected to.
2019-12-14 00:16:53 +08:00
2020-07-31 03:30:40 +08:00
Alternatively, you can {kibana-ref}/working-remote-clusters.html[manage remote clusters] from {kib}:
2019-01-16 02:53:29 +08:00
2020-07-31 03:30:40 +08:00
. From the {kib} menu, select *Management -> Stack Management*.
. Under *Data*, select *Remote Clusters* to access the Remote Clusters
page.
2019-01-16 02:53:29 +08:00
2020-07-31 03:30:40 +08:00
[role="screenshot"]
image::images/remote-clusters.png["The Remote Clusters page in {kib}"]
2018-11-13 19:45:00 +08:00
2019-09-18 21:44:28 +08:00
2018-11-13 19:45:00 +08:00
[[ccr-getting-started-leader-index]]
2019-09-18 21:44:28 +08:00
==== Creating a leader index
2018-11-13 19:45:00 +08:00
In the following example, we will create a leader index in the remote cluster:
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
2019-01-18 16:34:11 +08:00
PUT /server-metrics
2018-11-13 19:45:00 +08:00
{
"settings" : {
"index" : {
"number_of_shards" : 1,
2019-04-01 10:10:45 +08:00
"number_of_replicas" : 0
2018-11-13 19:45:00 +08:00
}
},
"mappings" : {
2019-01-18 16:34:11 +08:00
"properties" : {
"@timestamp" : {
"type" : "date"
},
"accept" : {
"type" : "long"
},
"deny" : {
"type" : "long"
},
"host" : {
"type" : "keyword"
},
"response" : {
"type" : "float"
},
"service" : {
"type" : "keyword"
},
"total" : {
"type" : "long"
2018-11-13 19:45:00 +08:00
}
}
}
}
--------------------------------------------------
// TEST[continued]
2019-09-18 21:44:28 +08:00
2018-11-13 19:45:00 +08:00
[[ccr-getting-started-follower-index]]
2019-09-18 21:44:28 +08:00
==== Creating a follower index
2018-11-13 19:45:00 +08:00
Follower indices are created with the {ref}/ccr-put-follow.html[create follower
API]. When you create a follower index, you must reference the
<<ccr-getting-started-remote-cluster,remote cluster>> and the
<<ccr-getting-started-leader-index,leader index>> that you created in the remote
cluster.
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
2019-01-30 02:47:29 +08:00
PUT /server-metrics-copy/_ccr/follow?wait_for_active_shards=1
2018-11-13 19:45:00 +08:00
{
"remote_cluster" : "leader",
"leader_index" : "server-metrics"
}
--------------------------------------------------
// TEST[continued]
//////////////////////////
2019-09-06 04:47:18 +08:00
[source,console-result]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
{
"follow_index_created" : true,
"follow_index_shards_acked" : true,
"index_following_started" : true
}
--------------------------------------------------
//////////////////////////
2019-03-06 00:50:58 +08:00
The follower index is initialized using the <<remote-recovery, remote recovery>>
process. The remote recovery process transfers the existing Lucene segment files
from the leader to the follower. When the remote recovery process is complete,
the index following begins.
2018-11-13 19:45:00 +08:00
Now when you index documents into your leader index, you will see these
documents replicated in the follower index. You can
inspect the status of replication using the
2018-11-13 22:14:26 +08:00
{ref}/ccr-get-follow-stats.html[get follower stats API].
2018-11-13 19:45:00 +08:00
2020-07-31 03:30:40 +08:00
Alternatively, you can {kibana-ref}/managing-cross-cluster-replication.html#_create_specific_follower_indices[manage follower indices] using {kib}:
. From the {kib} menu, click *Management -> Stack Management*.
. Under *Data*, select *Cross Cluster Replication*.
. Choose the *Follower indices* tab.
[role="screenshot"]
image::images/ccr-follower-index.png["The Cross-Cluster Replication page in {kib}"]
2018-11-13 19:45:00 +08:00
//////////////////////////
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
POST /server-metrics-copy/_ccr/pause_follow
POST /server-metrics-copy/_close
POST /server-metrics-copy/_ccr/unfollow
--------------------------------------------------
// TEST[continued]
//////////////////////////
2019-09-18 21:44:28 +08:00
2018-11-13 19:45:00 +08:00
[[ccr-getting-started-auto-follow]]
2019-09-18 21:44:28 +08:00
==== Automatically create follower indices
2018-11-13 19:45:00 +08:00
2018-11-20 09:40:58 +08:00
The <<ccr-auto-follow,auto-follow>> feature in {ccr} helps for time series use
cases where you want to follow new indices that are periodically created in the
remote cluster (such as daily Beats indices). Auto-following is configured using
the {ref}/ccr-put-auto-follow-pattern.html[create auto-follow pattern API]. With
an auto-follow pattern, you reference the
2018-11-13 19:45:00 +08:00
<<ccr-getting-started-remote-cluster,remote cluster>> that you connected your
local cluster to. You must also specify a collection of patterns that match the
indices you want to automatically follow.
For example:
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
PUT /_ccr/auto_follow/beats
{
"remote_cluster" : "leader",
"leader_index_patterns" :
[
"metricbeat-*", <1>
"packetbeat-*" <2>
],
"follow_index_pattern" : "{{leader_index}}-copy" <3>
}
--------------------------------------------------
// TEST[continued]
<1> Automatically follow new {metricbeat} indices.
<2> Automatically follow new {packetbeat} indices.
<3> The name of the follower index is derived from the name of the leader index
by adding the suffix `-copy` to the name of the leader index.
//////////////////////////
2019-09-06 04:47:18 +08:00
[source,console-result]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
{
"acknowledged" : true
}
--------------------------------------------------
//////////////////////////
//////////////////////////
2019-09-10 01:13:41 +08:00
[source,console]
2018-11-13 19:45:00 +08:00
--------------------------------------------------
DELETE /_ccr/auto_follow/beats
--------------------------------------------------
// TEST[continued]
//////////////////////////
2019-01-16 02:53:29 +08:00
2020-07-31 03:30:40 +08:00
Alternatively, you can manage auto-follow patterns from {kib}:
. From the {kib} menu, click *Management -> Stack Management*.
. Under *Data*, select *Cross Cluster Replication*.
. Choose the *Auto-follow patterns* tab.
2019-01-16 02:53:29 +08:00
[role="screenshot"]
2020-07-31 03:30:40 +08:00
image::images/auto-follow-patterns.png["The Auto-follow patterns page in {kib}"]
See {kibana-ref}/managing-cross-cluster-replication.html#_create_follower_indices_from_an_auto_follow_pattern[Create follower indices from an auto-follow pattern] for more information.