CDCR的主要组成部分

CDCR的主要组成部分

CDCR架构中有许多关键特性和组件：

CDCR配置

为了配置CDCR，源数据中心需要与目标数据中心关联的ZooKeeper集群的主机地址。ZooKeeper主机地址是CDCR实例化与Target Solr集群通信所需的唯一信息。因此，源群集上solrconfig.xml文件的CDCR配置部分将包含一个ZooKeeper主机列表。solrconfig.xml的CDCR的配置部分还可能包含辅助/可选配置，例如CDC Replicator线程的数量，批量更新相关设置等。

CDCR初始化

CDCR支持对新的或现有的集合进行增量更新。CDCR可能无法跟上极高的volume更新，特别是在数据中心之间由于“pipe”缓慢而导致通信延迟严重的情况下。某些情况下：

• 有一个语料库的初始批量加载，然后是较低的volume增量更新。在这种情况下，可以执行初始批量加载，然后启用CDCR。有关更多信息，请参阅初始启动部分。
• 该索引从头开始建立，没有明显的初始批量负荷。CDCR可以设置在空集合上，并从头开始保持同步。
• 索引总是被更新的数量太高，CDCR无法不上。在源数据中心和目标数据中心之间的连接较差的情况下，这尤其有可能。这种情况不适用于目前的CDCR格式。

数据中心间通信

CDCR REST API是管理命令的最终用户通信的主要形式。SolrJ客户端在内部用于CDCR操作。SolrJ客户端从solrconfig.xml文件中获取配置信息。CDCR的用户不会直接与内部的SolrJ实现进行交互，只会通过REST API与CDCR进行交互。

更新Tracking和Pushing

CDCR通过利用更新日志将数据更新从源复制到目标数据中心。

后台线程定期检查更新日志中的新条目，然后将其转发到目标数据中心。因此，线程需要保持一个检查点的形式，指向在更新日志中成功处理的最后一个更新。目标数据中心确认更新已成功处理后，更新日志指针将更新以反映当前检查点。

此指针必须在所有副本之间同步。在leader失败并选出新leader的情况下，新leader将能够通过使用该同步指针从最后更新恢复复制。下面将解释在副本之间同步这样一个指针的策略。

如果由于某种原因，目标数据中心处于离线状态或未能处理更新，则线程将定期尝试联系目标数据中心，并在缓存源群集上的更新时推送更新。其中一个含义是应该定期监视源更新日志目录，因为更新将继续积累，直到与目标数据中心的连接恢复，amd才会被清除。

更新检查点的同步

碎片引导程序和碎片副本之间更新检查点的可靠同步对于避免引入源数据中心和目标数据中心之间的不一致至关重要。另一个重要的要求是必须以最小的网络流量来执行同步，以最大限度地提高可伸缩性。

为了实现这一目标，战略是：

• 唯一标识每个更新操作。这个唯一的标识符将作为指针。
• 依赖于两个存储器：Source shard leader上的临时存储和目标集群上的持久存储。

源集群中的分片头将负责为每个更新操作生成唯一的标识符，并将最后一次处理的更新的标识符的副本保留在内存中。标识符将作为更新请求的一部分发送到目标群集。在目标数据中心方面，分片头将接收更新请求，并将其与更新日志中的唯一标识符一起存储，并将其复制到其他碎片。

SolrCloud已经为每个更新操作提供了一个唯一的标识符，即“版本号”。该版本号是使用基于时间的导入时钟生成的，该时钟对于每次发送的更新操作都是递增的。这提供了更新操作的“发生之前”排序，这将在（1）源集群上的更新检查点的初始化以及（2）更新日志的维护策略中利用。

目标群集上的持久性存储仅在选择源群集上的新分片头时使用。如果一个碎片leader在源群集上向下移动并选出一个新的leader，新leader将联系目标集群来检索最后的更新检查点并实例化其短暂指针。在这样的请求中，目标集群将检索在所有分片中收到的最新标识符，并将其发送回源集群。为了检索最新的标识符，每个分片leader将在其更新日志中查找第一个条目的标识符并将其发送回协调器。协调器将不得不选择其中最高的。

这种策略不需要任何额外的网络流量，并确保了可靠的指针同步。一致性主要通过利用SolrCloud来实现。SolrCloud的更新工作流确保每一个更新都被应用到leader以及任何副本。如果leader不可用，就选一个新的leader。在leader选择期间，将在新leader与其他副本之间执行同步。这确保了新的leader与前leader有一致的更新日志。拥有一致的更新日志意味着：

• 在源集群上，更新检查点可以被新的leader重用。
• 在目标群集上，更新检查点将在先前和新的leader之间保持一致。这确保了由新选出的leader从目标集群发送的更新检查点的正确性。

维护更新日志

CDCR复制逻辑需要修改源数据中心上更新日志的维护逻辑。最初，“更新日志”用作固定大小的队列，默认限制为100个更新条目。在CDCR方案中，更新日志必须充当可变大小的队列，因为它们需要跟踪目标数据中心的最后一次处理更新来跟踪所有更新。更新日志中的条目只有在所有指针（每个目标数据中心一个指针）位于其后面时才会被删除。

如果与其中一个目标数据中心的通信速度较慢，则源数据中心上的更新日志可能会增长到相当大的规模。在这种情况下，更新日志必须能够根据其标识符有效地找到给定的更新操作。鉴于其标识符是一个增量编号，有可能实现一个有效的搜索策略。每个事务日志文件都包含第一个元素的版本号作为其文件名的一部分。这用于快速遍历所有事务日志文件，并查找包含一个特定版本号的事务日志文件。

监控

CDCR通过复制操作提供以下监视功能：

• 通过源节点和目标节点及其状态等信息监视传出和传入的复制
• 有关复制的统计信息，例如每秒的操作（添加/删除）、队列中的文档数量等信息。

有关生命周期和统计数据的信息将由CDC Replicator线程以分片的形式提供。然后，CDCR API可以将这些信息汇总为一个集合级别。

CDC Replicator

CDC Replicator是一个后台线程，负责将源数据中心的更新复制到一个或多个目标数据中心。它负责在每个碎片基础上提供监测信息。由于集群中可能有大量集合和分片，因此我们将使用固定大小的CDC Replicator线程池，这些线程将在分片之间共享。

CDCR限制

目前的CDCR设计有一定的局限性。CDCR将会随着时间的推移而不断发展，这些限制中的许多将被解决。其中包括：

• 对于更新速率较高的批量负载情况，CDCR不太可能令人满意，尤其是在源群集和目标群集之间的带宽受到限制的情况下。在这种情况下，应执行初始批量加载，同步源数据中心和目标数据中心，并使用CDCR进行增量更新。
• CDCR目前只是单向的；数据被从源集群推送到目标集群。在这方面正在开展积极的工作来消除这一限制。
• CDCR 的工作原理与源和目标集合中的碎片数量相同。两个集合中的碎片可能有不同数量的副本。
• 目前不支持使用HDFS上的索引运行CDCR，请参阅Solr CDCR over HDFS JIRA问题。
• 源和目标群集之间的配置文件(solrconfig.xml, schema 等)不会自动同步。这意味着当源模式或solrconfig.xml文件发生更改时，必须手动将这些更改复制到目标群集。这包括通过Schema API或托管资源添加字段，以及手动编辑这些文件。