云数据库MongoDB版推出MongoDB实例间的双向同步产品:云上灾备和多活,助力企业快速复制阿里巴巴异地多活架构。

架构



  • 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实现。



全量加增量

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

双活以及多活模型

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

同时修改同一个唯一键可能导致数据错乱,目前的冲突解决策略为覆盖(后面修改的数据覆盖前面的数据)或者忽略。后续我们将上线CRDT校验程序功能,当修改相同唯一键时,CRDT提供接口报错。

高效性保证

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

  • 从源数据库并行拉取数据,并解决冲突依赖。
  • 将源数据库数据并行发往Kafka通道。
  • 将数据并行写入目的端数据库,同时解决依赖问题。

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

环形复制

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

可靠性传输

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

高可用

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

限制说明

  • 目前仅副本集实例支持云上灾备功能,单节点实例和分片集群实例暂不支持。
  • 源实例数据库版本须是3.2版本或3.4版本,暂不支持4.0版本。
  • 源实例存储引擎必须是WiredTiger。
  • 暂不支持在两个已有MongoDB实例之间直接搭通道同步数据。
  • 数据同步时,源实例会重启一次,重启过程中将gid加入Oplog中。如果源实例过大,重启时间将会达到分钟级。
  • 实例同步后,不支持DDL同步。如果在源实例上进行了DDL操作,目的实例将无法同步源实例的DDL操作。
  • 当前只支持双活功能(2个MongoDB实例之间同步数据),后续会上线多活功能(多个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