Elasticsearch CCR 运作原理，以及如何在kibana上操作它

最新推荐文章于 2024-07-26 08:44:14 发布

水的精神

最新推荐文章于 2024-07-26 08:44:14 发布

阅读量1.1k

点赞数

分类专栏： Elasticsearch

本文链接：https://blog.csdn.net/star1210644725/article/details/116465977

版权

Elasticsearch 专栏收录该内容

158 篇文章 50 订阅

订阅专栏

CCR 一个主从模式。熟悉数据读写分离的，可以理解为读写分离，主库写数据，从库关联主库然后实时同步数据。从库只可以读操作，主库可以读可以写操作。CCR是elasticsearch的不同集群间的一个主从模式。

在我的文章里用主从来描述在这个关系，我是觉得更好理解。在官方描述里，叫做领导者和跟随者。

CCR 能带来什么

集群高可用 灾难恢复（DR）/高可用性（HA）：如果主群集发生故障，则进行灾难恢复。辅助群集可以用作热备份
地理位置优越：在 Elasticsearch 中复制数据以更接近用户或应用程序服务器，从而减少延迟。可以在本地提供阅读服务
集中报告：将数据从大量较小的集群复制回一个中央集群进行报告

CCR 是怎么一个运作模式

CCR 只针对索引

复制源索引称为 leader 索引，或者叫做主索引。
复制目标索引称为 follower 索引，或者叫做从索引。
一个集群可以同时包含 leader 索引和 follower 索引

复制是主动-被动关系

你可以使用 leader 索引来进行读或写，这个索引存在于远程集群里，但是你只能针对 follower 索引进行读操作。follower 索引存在于本地的集群里。

Follower 角色通过 Pull 的方式从 Leader 获取更新的变更，主要有如下两个过程：

历史数据全量同步：Follower通过远程构造snapshot方式，从Leader同步全量数据
增量数据：Follower不断检查Leader是否有更新，并以Translog Snapshot的形式同步过来，实现同步更新

如何在kibana上开启CCR

前提条件

在进行 CCR 之前，我们必须满足一下的一些条件：

跨集群复制需要远程集群。
本地集群的 Elasticsearch 版本必须与远程集群相同或比远程集群新。如果较新，则这些版本还必须兼容以下矩阵中概述的版本。
就像上面所讲的那样，因为 CCR 是一个 platinum 功能，你必须购买版权，或者你可以先尝试一个免费的测试。或者，看看网上大佬的绿色方案！
如果启用了弹性安全功能，那么你需要具有适当的用户权限。当我们使用 elastic 用户名时，需要特别注意，因为它具有超级用户的角色，你可能会无意中做了一个重大的更改。

在远程群集上，您将需要具有 read_ccr 权限的群集用户，以及 follower 索引必须具有 monitor 及和 read 权限
在本地群集上，同一用户将需要 manage_ccr 群集权限。follower 索引必须具有 monitor，read, write 及 manage_follow_index的权限

在kibana上操作

在这个实验里，我们首先按照我之前的文章 “Elasticsearch：跨集群搜索 Cross-cluster search (CCS)” 来安装我们的两个集群。不过，这里有两个小的区别：

我们为每个集群打开安全。我们可以按照我之前的文章 “Elasticsearch：设置Elastic账户安全” 来对我们的两个集群设置安全。为了方便，我们将使用 elastic 用户来进行操作，尽管我们需要特别的小心
由于这个功能是 platinum 功能，在没有购买的情况下，我们可以进行尝试来测试这个功能。为此，我们必须安装如下的方式打开这个功能：

在上面，我们选择 “Start trial” 这个按钮，并接受相应的条件。接下来，我们就可以开始我们的测试了。

我们也可以按照如下的命令来启动 trial:

curl -X POST "http://localhost:9200/_license/start_trial?acknowledge=true"

cluster_1

我们在 cluster_1 上创建如下的一个叫做 twitter 的索引：

POST _bulk
{"index":{"_index":"twitter","_id":1}}
{"user":"张三","message":"今儿天气不错啊，出去转转去","uid":2,"age":20,"city":"北京","province":"北京","country":"中国","address":"中国北京市海淀区","location":{"lat":"39.970718","lon":"116.325747"}, "DOB": "1999-04-01"}
{"index":{"_index":"twitter","_id":2}}
{"user":"老刘","message":"出发，下一站云南！","uid":3,"age":22,"city":"北京","province":"北京","country":"中国","address":"中国北京市东城区台基厂三条3号","location":{"lat":"39.904313","lon":"116.412754"}, "DOB": "1997-04-01"}
{"index":{"_index":"twitter","_id":3}}
{"user":"李四","message":"happy birthday!","uid":4,"age":25,"city":"北京","province":"北京","country":"中国","address":"中国北京市东城区","location":{"lat":"39.893801","lon":"116.408986"}, "DOB": "1994-04-01"}
{"index":{"_index":"twitter","_id":4}}
{"user":"老贾","message":"123,gogogo","uid":5,"age":30,"city":"北京","province":"北京","country":"中国","address":"中国北京市朝阳区建国门","location":{"lat":"39.718256","lon":"116.367910"}, "DOB": "1989-04-01"}
{"index":{"_index":"twitter","_id":5}}
{"user":"老王","message":"Happy BirthDay My Friend!","uid":6,"age":26,"city":"北京","province":"北京","country":"中国","address":"中国北京市朝阳区国贸","location":{"lat":"39.918256","lon":"116.467910"}, "DOB": "1993-04-01"}
{"index":{"_index":"twitter","_id":6}}
{"user":"老吴","message":"好友来了都今天我生日，好友来了,什么 birthday happy 就成!","uid":7,"age":28,"city":"上海","province":"上海","country":"中国","address":"中国上海市闵行区","location":{"lat":"31.175927","lon":"121.383328"}, "DOB": "1991-04-01"}

cluster_2

我们在 cluster_2 上进行如下的操作：

我们点击 “Add a remote cluster”：

我们填入相应的名称及seed的相关信息，并点击“Save”：

当我们点击完 “Save” 后，就会出现上的画面，表明我们的 remote_twitter 已经连接成功。在上面我们点击 “Close”。我们接下来点击 “Cross-Cluster Replication”:

我们点击上面的 “Create a follower index”:

我们填入相应的信息。注意上面我们定义一个叫做 twitter_copy 的 follower index。当我们填入上面的信息过后，我们点击 “Create” 按钮：

我们可以看到刚才创建的 twitter_copy 的状态经过很短的时间由 paused 变为 active，表明我们的 index 创建是成功的。

我们点击 Dev Tools，并打入如下的命令：

我们可以看到最新创建的 twitter_copy 这个索引。我们可以针对这个索引进行搜索：

我们在 cluster_1 中为 twitter 索引新增加了一个文档。这个文档的 id 为8。接下来我们在 cluster_2 中马上来查一下：

我们可以看到我们最新添加的一个 id 为8的文档已经被成功在 cluster_2 中可见。这说明我们的自动复制功能已经在起作用。

除了上面的界面来生产一个 twitter_copy 的索引（我们不需要预先生产任何的 twitter_copy 索引，下面的命令将生成 twitter_copy），我们也可以直接使用 API 来完成。在 cluster_2 的 Kibana 中打入如下的命令：

我们可以看到我们最新添加的一个 id 为8的文档已经被成功在 cluster_2 中可见。这说明我们的自动复制功能已经在起作用。

除了上面的界面来生产一个 twitter_copy 的索引（我们不需要预先生产任何的 twitter_copy 索引，下面的命令将生成 twitter_copy），我们也可以直接使用 API 来完成。在 cluster_2 的 Kibana 中打入如下的命令：

当我们执行上面的命令后，它会自动帮我拷贝索引 twitter。

发起 index pattern 复制

如果你有时间序列数据，请启用 auto-follow 功能以自动创建关注者索引。我们安装如下的方法来进行：

经过上面的配置后，我们可以在 Kibana 中打入如下的命令来进行查看：

GET /_ccr/auto_follow/remote_logs

上面的命令显示的结果为：

{
"patterns" : [
{
"name" : "remote_logs",
"pattern" : {
"active" : true,
"remote_cluster" : "remote_ccr",
"leader_index_patterns" : [
"logs*"
],
"follow_index_pattern" : "{{leader_index}}-copy"
}
}
]

也就是说，我们也可以直接通过如的方法来进行配置：

PUT /_ccr/auto_follow/remote_logs
{
"remote_cluster": "remote_ccr",
"leader_index_patterns": "logs*",
"follow_index_pattern": "{{leader_index}}-copy"
}

在我们的 cluster_1 的 Kibana 中，我们打入如下的命令来生产相应的 log 索引：

PUT logs_1/_doc/1
{
"message": "This is log 1"
}

PUT logs_2/_doc/1
{
"message": "This is log 2"
}

上面的两个命令在 cluster_1 的集群中生成两个索引: logs_1 及 logs_2。

那么我到 cluster_2 的集群的 Kibana 中来进行查看：

GET _cat/indices

上面的命令显示：

我们可以看到两个新生成的索: logs_1-copy 以及 logs_2-copy。显然两个索引被自动复制。我们可以更进一步来进行查看：

GET logs*/_search

上面的命令显示：

{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 2,
"successful" : 2,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "logs_1-copy",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"message" : "This is log 1"
}
},
{
"_index" : "logs_2-copy",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"message" : "This is log 2"
}
}
]
}
}