什么是 Elasticsearch 的跨集群复制
CCR - Cross Cluster Replication - 跨集群复制是 Elasticsearch v6.5 发布的一个新的特性，这个特性可以让你将一个集群的索引数据同步复制到远程的另外一个集群上面去。或者反过来，将一个远程的集群的索引数据同步的复制到本地 Elasticsearch 集群中来。集群复制类似于数据订阅的方式，一个集群的数据可以被多个集群订阅，也就是可以被复制到多个集群上面去。CCR 有两个角色，一个是 Leader，表示数据的源头，另外一个Follower，表示数据的订阅方，得到的是数据副本。CCR 工作在索引层面，使用 Pull 的模式，Follower 索引主动的去 Pull Leader 的数据。这个特性是 Elasticsearch 的商业特性，需要白金订阅。
典型应用场景
如今，多集群的方式越来越普遍，一个公司或者一个团队，往往需要维护多套 Elasticsearch 集群，关于多集群的治理可以用 Elastic Cloud Enterprise ，这里就先不展开了。另外很多公司的业务可能已经是遍布整个国家，甚至全球化。借助 CCR 刚好就可以解决下面的几个场景的问题：
- 集群高可用以及灾难恢复
- 实现数据的就近访问（地理）
- 集中式的报告集群
第一个场景，关于保证 Elasticsearch 集群的高可用和灾难恢复，通过部署多套 Elasticsearch 集群，并且分布在不同地域的数据中心，然后接着 CCR，将数据做一个实时的同步，假如其中一个数据中心失联或者因为不可抗力的因素，如台风、地震，我们照样还能通过访问剩下的集群来获取完整的数据，如下图示意：
当 Production DC 失联之后，我们可以立即切换到 Disaster Recovery DC。
第二个场景，数据的就近访问，假设是一个大集团，有总公司和分公司，通过按地理位置来划分分公司自己的业务集群，不同城市的业务数据可以使用各自的集群，这样能够更快的进行当地业务的处理，不过也有一些数据，可能是总公司下发的数据，各个分公司都只能读，比如一些元数据，我们借助 CCR，可以把这部分数据下发到各个分公司的 Elasticsearch 集群，这样每个分公司都能实时的获取到最新的数据，并且直接访问各自的本地集群就可以了，大大提升访问速度。
上图中，Central DC 借助 CCR 实时的同步下发数据到 Singapore DC、Canada DC 和 Ireland DC。
另外一个场景就是做集中式的报告分析，接上面的案例，我们反过来处理我们的业务数据，我们将每个分公司的业务数据实时的同步到总公司的 Elasticsearch 集群，这样总公司就有了每个分公司的完整数据，这样进行报告分析的时候，就可以直接的在总公司的 Elasticsearch 集群里面进行快速的可视化分析了。
如何使用
说了这么多 CCR 的适用场景，那接下来我们来看一下具体如何使用吧。
假设我有两个机器，北京集群（192.168.1.100:9300）和深圳集群（192.168.3.100:9300），这俩个集群之间的网络是互通的。现在我们希望把北京集群的销售数据同步到深圳集群上去。
第一步，在北京集群上，设置 Leader 索引
这个 Leader Index 需要设置好允许 Soft Deletes，这个参数非常重要，CCR 依赖这个特性来，如果这个索引之前没有开启过这个参数，需要重新创建索引才行。
比如，我创建一个 bj_sales 这个索引：
PUT bj_sales
{
"settings": {
"index.soft_deletes.retention.operations": 2000,
"index.soft_deletes.enabled": true
}
}
现在，这个 bj_sales 就已经具备跨集群复制的能力了。
第二步，北京集群，创建几条销售数据。
POST bj_sales/doc/
{
"name":"Jack Ma",
"age":40
}
POST bj_sales/doc/
{
"name":"Pony Ma",
"age":40
}
第三步，在深圳集群上，把北京集群的信息加到远程集群里面去。
PUT _cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"bj": {
"seeds": [
"192.168.1.100:9300"
]
}
}
}
}
}
bj 是我们能够在深圳集群里面访问北京集群的命名空间。
第四步，我们在深圳集群里面通过 CCR API 创建一个索引，并订阅北京机器的 bj_sales 这个索引。
PUT /bj_sales_replica/_ccr/follow
{
"remote_cluster" : "bj",
"leader_index" : "bj_sales"
}
bj_sales_replica 是我们将要创建在深圳集群上的索引名称，remote 集群是 bj，订阅了对方的 bj_sales 索引。
第五步，验证
如果不出意外，我们在深圳集群上，应该就会创建一个新的 bj_sales_replica 的索引，并且里面会有两条数据，我们可以验证一下，如下：
GET bj_sales_replica/_search
返回结果如下：
{
"took" : 6,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [
{
"_index" : "bj_sales_replica",
"_type" : "doc",
"_id" : "iNZYymcBGbeu9hnEe7-G",
"_score" : 1.0,
"_source" : {
"name" : "Pony Ma",
"age" : 40
}
},
{
"_index" : "bj_sales_replica",
"_type" : "doc",
"_id" : "QdZYymcBGbeu9hnEJb-Z",
"_score" : 1.0,
"_source" : {
"name" : "Jack Ma",
"age" : 40
}
}
]
}
}
果然，自动将远程集群的数据复制过来了。
继续验证，数据同步
我们在北京集群上，继续新增数据和删除数据，看看深圳集群是否都能正常同步。
POST bj_sales/doc/5
{
"name":"Tony",
"age":30
}
DELETE bj_sales/doc/5
这里就留给读者你自己去测试了。应该立马就能同步完成。
小结
经过我们简单的测试，我们已经能够感受到 CCR 的威力了，并且集群间同步的速度非常快。
大家如果有兴趣的话，可以进一步尝试它的 Auto Follow 的功能，对于一些自动创建的时序性索引更加方便，比如Metricbeat 或者 Logstash 产生的索引，也都能自动的进行跨集群的复制。
不过，目前 CCR 还处于 Beta 阶段，欢迎大家测试，如有发现任何 Bug，还请帮忙反馈。
好了，今天的 Advent 文章就写到这里，希望这篇内容对你有用。