云上灾备和多活架构

架构

• Oplog（operations log）：MongoDB的日志，所有对数据库的修改都会保存在Oplog中。

• ReplicaA、ReplicaB：ReplicaA、ReplicaB分别是独立的MongoDB三节点副本集实例。

  为保证双活，ReplicaA、ReplicaB都需要可写入。由用户端保证同一数据不会在ReplicaA、ReplicaB同时写入。

• Oplog同步：通过BLS互相同步Oplog数据后，再在目的端重放数据。

在MongoDB云上灾备和多活中，主要有以下三大组件：

• BLS Manager：中心控制模块，负责Collector、Receiver的调度和监控等任务。

• BLS Collector：数据采集模块，负责从源MongoDB数据库拉取Oplog数据，然后发送到Kafka通道。

• BLS Receiver：数据回放模块，负责从Kafka通道中获取数据，然后写入目的端MongoDB数据库。

下图是MongoDB云上灾备和多活内部系统的整体架构图，其中Tunnel用kafka实现。

全量加增量

同步模型采用全量+增量的方式，即在创建实例时对源数据库进行全量数据同步，后续的修改通过增量数据来同步。

双活以及多活模型

由于数据复制是异步方式，所以对于双活或者多活模式，由用户端保证不会对同一个唯一键同时进行修改。

同时修改同一个唯一键可能导致数据错乱，目前的冲突解决策略为覆盖（后面修改的数据覆盖前面的数据）或者忽略。

高效性保证

以下三条策略实现实例间数据同步的高效性：

• 从源数据库并行拉取数据，并解决冲突依赖。

• 将源数据库数据并行发往Kafka通道。

• 将数据并行写入目的端数据库，同时解决依赖问题。

因地域和网络类型不同，实例间的数据同步延迟也不同。MongoDB云上灾备和多活产品理论TPS能够接近20万，即每秒传输20万条Oplog。为保证数据批量传输的高效性，数据发送过程中有缓存机制，少量数据的同步延迟可能超过5秒。

环形复制

为防止环形复制（数据从源复制到目的，又从目的复制到源），我们在Oplog日志中加入gid来解决环形复制问题。

可靠性传输

支持断点续传，实例重启时数据同步不受影响。

高可用

链路同步具有高可用性，如果同步进程出错，备用进程启动接管服务。

限制说明

• 目前仅副本集实例支持云上灾备功能，单节点实例和分片集群实例暂不支持。

• 源实例数据库版本须是3.2版本或3.4版本，暂不支持4.0版本。

• 源实例存储引擎必须是WiredTiger。

• 暂不支持在两个已有MongoDB实例之间直接搭通道同步数据。

• 数据同步时，源实例会重启一次，重启过程中将gid加入Oplog中。如果源实例过大，重启时间将会达到分钟级。

• 实例同步后，不支持DDL同步。如果在源实例上进行了DDL操作，目的实例将无法同步源实例的DDL操作。

• 当前只支持双活功能，即两个MongoDB实例之间同步数据。

支持云上灾备产品的区域

以下区域中的实例支持实例间的数据同步，可以跨越城市或者国家，例如上海和新加坡。

• 中国内地

  地域名称	所在城市	Region ID
  华北 1	青岛	cn-qingdao
  华北 2	北京	cn-beijing
  华东 1	杭州	cn-hangzhou
  华东 2	上海	cn-shanghai
  华南 1	深圳	cn-shenzhen

• 其他国家和地区

  地域名称	所在城市	Region ID
  中国（香港）	中国香港	cn-hongkong
  美国西部	硅谷	us-west-1
  美国东部	弗吉尼亚	us-east-1