Elasticsearch跨集群复制（CCR）介绍

跨集群复制（CCR，cross-cluster replication）属于xpack增强包中的功能，需要白金级、企业级证书才可使用。CCR可以将远程集群（leader）中的索引复制到本地集群（follower）中，常用于以下场景中：

• 灾难恢复及高可用性

  对于分布在不同地域的Elasticsearch集群，您可以通过CCR进行数据备份。当其中一个集群发生故障时，您可以通过访问其他集群来获取故障集群的数据，保证数据不丢失。

• 就近访问数据

  例如A集团下有多个子公司，各子公司所分布的地域不同。为了提高业务处理速度，可按照地理位置划分子公司要承担的业务，并通过CCR将业务数据分发给各地域中的Elasticsearch集群。子公司在处理业务时，可直接访问当前所在地域的集群。

• 集中报告

  通过CCR，将多个数据量较小的集群中的数据复制到一个中央集群中，进行可视化分析与报告。

CCR为被动复制模式，leader索引接收写入后，follower索引拉取变更并在本地回放。follower索引可以手动创建或使用auto-follow模式自动创建。

follower索引是只读的。

CCR集群可以配置为单向复制或双向复制：

• 单向复制，一个集群只包含leader索引，另一个集群只包含follower索引。follower集群的ES版本必须等于或高于leader集群。版本兼容性见：https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-ccr.html#ccr-remote-recovery
• 双向复制，每个集群既包含leader索引也包含follower索引。

多集群架构

基于使用场景的不通，可将多集群架构分为：

灾难恢复及高可用架构

灾难恢复架构是最常见的多集群架构，可为关键应用程序提供区域/数据中心故障时的容灾能力，可分为：

单容灾节点架构

多容灾节点架构

链式复制架构

双向复制架构

有关双向复制的详细用法可以参看： https://www.elastic.co/cn/blog/bi-directional-replication-with-elasticsearch-cross-cluster-replication-ccr

数据本地化架构

将数据中心就近部署于用户或应用服务器可以减少访问延迟及响应时间，如下图使用CCR将数据复制到另外三个区域中心：

集中报告架构

该架构将多个小集群的数据复制到中央集群。例如一个大型跨国公司在全球各地区分公司拥有100个Elasticsearch集群，使用CCR可以将这些集群的数据复制到中央集群以进行集中分析。

复制机制

尽管我们配置CCR是从index层面进行的，但Elasticsearch确实从shard(分片)层面进行复制的。 当一个follower索引被创建时，它的所有shard都会从leader索引的相关shard中拉取数据，这意味着follower索引的shard数量与leader索引相等。对leader索引的所有操作请求，如CREATE、UPDATE、DELETE文档均会被follower复制，这些请求可以由leader索引的任何副本（primary或replica）分片提供。

当follower分片发送read请求后，leader分片会返回未同步过的操作。如果没有未同步过的操作，leader分片会等待一段时间（取决于follower配置的超时时间），如果在等待的这段时间里依然没有新的同步（写）操作，则返回空信息给follower分片。follower分片会update本地的分片统计信息并立即发送另一个新的read请求给leader分片。这种通信模型可以确保远程集群与本地集群间的网络连接持续保持，从而避免被外部源（如防火墙）强制终止。

如果read请求失败，则会见检查失败原因，如果故障被判断为可恢复的，如网络故障，则follower分片会进入重试循环。反之，follower分片会暂停复制直到手工恢复。

更新处理

follower索引的映射或别名无法手动修改，必须更新leader索引才能修改follower索引，因为follower索引是只读，会拒绝任何配置写入。

尽管对leader索引的变更会被复制到follower索引，但是follow索引不能直接接受write，因此即使leader别名的IS_WRITE_INDEX属性被设置为TRUE，follower索引中也会将其强制修改为FALSE。

同样，客户端更新document也必须通过leader索引来进行。

当follower分片从leader分片获取到更新操作后，会将这些操作放进写缓冲区，然后使用缓冲区中的操作提交批量写请求。如果写缓冲区满（到达配置上线），则follower分片不会再向leader分片发送read请求。这为CCR提供了一种背压机制（back-pressure），让follower分片在缓冲区不满时恢复发送read请求，保障同步的稳定进行。

对leader索引映射的更改将尽可能快地复制到follower索引，对leader索引设置得更改同样如此（本地属性的设置除外），例如对leader索引副本数的更改不会被复制到follower索引，因此该设置可能无法被检索。

如果你的leader索引应用了一个非动态更新设置，且该设置需要被follower索引复制，那么follower索引会被关闭，更新设置，然后重新打开。follower索引在此期间将不可读写。

使用"远程恢复"过程初始化follower索引

follower索引创建后，需要初始化完成才可接受查询和数据同步操作。“远程恢复”过程通过拷贝leader集群主分片的数据在follower集群上建立新分片，可以理解为一次"全量恢复"。

远程恢复是一个网络密集型过程，会将leader集群的所有Lucene段文件传输至follower集群。follow集群首先请求leader集群启动一个恢复会话，然后并行地从leader集群请求多个文件块。默认一次同时拉取5个1MB的文件块，这一默认设置是为了支持具有高网络延迟的主从集群。

如下参数用于控制远程恢复过程：

参数	默认值	含义
ccr.indices.recovery.max_bytes_per_sec	40mb	限制每个节点的出入流速
ccr.index.recovery.max_concurrent_file_chunks	5	控制每次恢复可以并行发送的文件块数，最大允许值为10
ccr.indices.recovery.chunk_size	1mb	传输的每个文件块的大小
ccr.indices.recovery.recovery_activity_timeout	60s	控制恢复活动的超时时间。此参数主要作用于leader集群。leader群集必须打开内存资源，以便在恢复过程中向follower提供数据。如果leader集群在这段时间内未收到来自follower的恢复请求，则将关闭资源。
ccr.indices.recovery.internal_action_timeout	60s	控制远程恢复过程中各个网络请求的超时时间。单个操作超时可能会使恢复失败。

可以在follower集群上通过

GET _cat/recovery?v=true

获取正在进行中的远程恢复详情。由于远程恢复使用快照恢复机制，因此上述结果中的远程恢复被标记为snapshot类型。

leader索引开启软删除

跨集群复制的原理是重放leader索引上的单个写入操作历史记录，因此leader分片需要保留历史操作记录以便给leader分片拉取。保留操作记录的基础机制就是"软删除（soft deletes）"。详细介绍可以参看：https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-history-retention.html

index.soft_deletes.retention_lease.period设置定义了分片历史记录保留时长，超过此时间的记录被视为过期，这一设置也是follower集群可以脱机的最长时间，默认为12小时。如果在历史记录过期后，follower索引再次请求恢复，且过期的记录在leader索引上仍然可用，那么Elasticsearch会建立一个新的租约并拷贝这些记录。但是Elasticsearch并不保证保留未恢复的操作，因此可能某些过期的操作已被leader丢弃。如果发生这种情况，follower无法自动恢复，必须重新创建CCR过程。

leader索引必须启用软删除，Elasticsearch 7.0.0及以上版本的索引默认开启软删除。较早版本的Elasticsearch，则需要在创建索引时手动开启soft_delete属性，或者在索引模版中进行开启。另外soft_delete属性为static setting，不支持通过index/_settings进行动态修改，如果需要对存量的索引开启soft_delete，则必须通过reindex操作将数据复制到开启软删除的新索引上。