怎么用Kafka 实现数据中心到数据中心的复制？

摘要：使用，可以设置一个名为的系统，将一组可配置的主题从一个数据中心转发到另一个数据中心。此外，在每个数据中心中有一些名为的程序实例。在每个数据中心中，选择一个领导者，与其他数据中心的进行交流，以组织复制。

摘要: 每个公司都需要为所有重要系统制定灾难恢复计划。从单个进程到最大的分布式体系结构的小单元都是这样。特别是对于数据库，这通常涉及容错，冗余，定期备份和应急计划的混合。数据库越大，制定好策略就越困难。 这篇文章概述了ArangoDB向多数据中心支持的第一个进化步骤--数据中心到数据中心的异步复制。

此功能允许您在两个不同的数据中心A和B中运行两个ArangoDB 群集，并设置从A到B的异步复制。这意味着数据中心A中的群集A可以照常用于读取和写入操作以及所有更改数据通过网络复制到数据中心B中的另一个集群B。复制是异步的，也就是说，更改出现在短暂的延迟之后，通常在几秒钟内。(阅读更多关于ArangoDB集群架构）

在数据中心A发生灾难的情况下，如网络连接完全丢失，可以快速停止复制，并开始使用数据中心B中的群集B作为群集A的替代品。之后，当灾难结束时，可以或者使用集群A作为群集B的异步副本，或者切换回A并继续复制到群集A。

单个ArangoDB集群是具有良好的水平可扩展性的分布式系统。数据容量和查询性能（读写）都与使用的服务器数量呈线性关系。自动分片导致数据的实际更改同时发生在所有服务器的整个地方。特别是，这意味着设计 - 没有一个地方确定所有更改的总顺序。也就是说，我们正在处理同时发生大量数据更新的分布式混乱。变化率可能会有很大差异，我们必须处理大量的写入突发。

同时，ArangoDB集群是容错的。例如，如果数据中心中的单个服务器出现故障，则ArangoDB群集可以容易地容忍这种损失，并假定用户将复制因子设置为至少为2 - 既没有丢失任何数据，也没有丢失可用性。系统简单地切换到使用另一台服务器，重新分配数据并移动，而不影响查询性能。因此，任何正确的复制解决方案都必须满足群集A中的这些透明故障切换。

另一方面，安全问题和防火墙维护意味着我们不能轻易地在许多不同的进程与其他数据中心中的许多不同进程进行交谈，但同样，我们也不能轻易地通过两个进程之间的单个网络连接的瓶颈来移动所有更新在不同的数据中心。

显然，整个复制系统是分布式系统的分布式系统，因此必须具有可扩展性和容错性，而无需单点故障。

所有这些挑战决定了我们的解决方案的设计。

在数据中心A中，ArangoDB集群A像往常一样运行，不对其代码库和API进行任何修改，并提供其通常的负载。同样，在数据中心B中，部署了第二个ArangoDB群集B，但最初空闲。

在两个数据中心中，我们部署了一个Kafka 消息代理，它是一种标准的高性能和容错排队系统，能够缓冲其消息队列中的大量数据。个人队列在卡夫卡被称为“主题”。使用Kafka，可以设置一个名为“MirrorMaker”的系统，将一组可配置的Kafka 主题从一个数据中心转发到另一个数据中心。写入其中一个主题的所有内容最终出现在另一个数据中心的Kafka 中的相应主题中。这是我们在数据中心之间移动消息和数据的主要手段。

此外，在每个数据中心中有一些名为“ArangoDB SyncMaster”的程序实例。在每个数据中心中，SyncMasters选择一个领导者，与其他数据中心的SyncMaster进行交流，以组织复制。 “组织”在这里表示，它计划必须在两个数据中心执行的各个任务才能进行复制。实质上，必须复制数据库，集合和用户所在的元信息以及分片集合中的实际数据。

在每个数据中心，领先的SyncMaster指挥执行实际复制任务的一小部分SyncWorkers。例如，对于集合的每个分片，数据中心A中都有“发送分片”任务以及数据中心B中的“接收分页”任务，并且所有这些分片由SyncMaster分配给某些SyncWorker。

这些任务负责初始增量同步阶段（运行ArangoDB中已有的现有分片同步协议）以及后期更新阶段，其中分片的所有更新都会在其他数据中心中复制（使用WAL拖尾数据中心A）。

数据流如下：它从ArangoDB集群的一些DBserver开始，转到Datacenter A中的一个SyncWorkers，然后进入Datacenter A中的Kafka。从那里，MirrorMaker将其移动到Datacenter B，在那里它被一些SyncWorker并最终写入数据中心B的协调器。显然，有一些控制消息在相反的方向流动，但是它们也使用两个Kafkas和MirrorMaker传输。

这对管理员来说，这意味着在初始部署之后，可以通过一个命令设置异步复制，只需告诉Datacenter B中的SyncMaster应该开始跟踪数据中心A中的集群A.所有从此开始的都是全自动的，所有数据库，集合，用户和权限都将自动复制到其他数据中心。显然，有监控和配置设施，但基本上是这样的。

这是迈向多数据中心意识的第一步，因此自然会带来局限性。首先，复制是异步的，所以它总是落后于Datacenter A 中的实际事件。通常，连接性好，写入速度小于跨数据中心链路的容量，这种延迟非常小。然而，应该意识到，在突然停止复制和手动切换到群集B的情况下，最近可能会写入的更新可能会丢失。整个设置是手动配置的，并且在两个数据中心之间工作。在此阶段不允许写入复制集群。然而，复制集群可以同时成为另一个数据中心的源，源集群可以有多个副本。也就是说，您可以形成数据中心的树。最后，关闭复制并开始使用副本仍旧需要管理员手动做出操作。

到目前为止，我们有一般的安装说明，以及RedHat Enterprise 7 和Centos 7 的具体部署说明和脚本（请参阅此处，包括README.me和说明）。请注意，此功能仅包含在ArangoDB Enterprise 版本中，并且我们发布的RPM包包含所有必需的部分。

下载即将到来的ArangoDB 3.3 的里程碑版。