1. 背景
当前的数据库系统生态中，大部分系统都支持多个节点实例间的数据同步机制 ，如Mysql Master/Slave主从同步，Redis AOF主从同步等，MongoDB更是支持3节点(及以上)ReplicaSet同步，上述机制很好的支撑了一个逻辑单元的数据冗余及HA。
跨逻辑单元(3节点实例、主从实例)，甚至跨单元、跨数据中心的数据同步，在业务层有时候就显得很重要，可以支持同城多机房的负载均衡，多机房的互备，甚至是异地多数据中心容灾(比如 光纤被挖断、地震等小概率事件)和多活。
基于以上背景，云数据库MongoDB版本正式推出MongoDB实例间的双向同步产品“MongoDB云上灾备”（也称BLS），助力企业快速复制阿里巴巴异地灾备、多活架构。
产品地址
2. 产品介绍
“MongoDB云上灾备”通过从源数据库拉取Oplog（Operations Log）数据（其是MongoDB的日志，所有对数据库的修改操作都会保存到oplog中），然后将其传输到目的数据库进行回放实现复制的目的。我们通过构造两条复制链路实现双向同步的功能，基于此，可以实现灾备和多活的功能。
上图给出了整体复制同步的流程。目前，“MongoDB云上灾备”支持的源、目的数据库类型为ReplicaSet副本集，Sharding模式即将上线，不支持单节点模式。为了减缓主节点的压力，系统从备（Secondary）上拉取Oplog。
全量加增量
同步模型采用全量+增量的方式：在创建时会对源数据库进行全量同步，后续的修改通过增量来同步。
双活以及多活模型
由于复制是异步模式，所以对于双活/多活模式，由用户保证不会对同一个唯一键同时修改，因为同时修改将可能导致数据错乱。目前冲突策略可以为覆盖或者忽略。后续将会上线校验程序，在用户操作相同唯一键时提供接口报错。
高效性保证
同步延迟因地域和网络不同而不同，理论TPS能够接近20万（每秒传输20万条oplog）。为了保证批量传输的高效性，数据发送存在缓存缓存机制，所以极限情况下，单条oplog时延可能为1秒。正常情况下，全球范围内数据同步时延小于3秒。
- 源数据库并行拉取，解决冲突依赖
- 并行发往Kafka通道
- 目的端在解决依赖的同时并行写入数据库
环形复制
为了防止环形复制（数据从源复制到目的，又从目的复制到源），在Oplog日志中打入gid解决该问题。
可靠性传输
支持断点续传，实例重启时数据同步不受影响。
高可用
链路同步具有高可用性，如果同步进程挂掉，会有备进程启动接管服务。
限制说明
- DDL语句同步暂未开放，所以如果修改了源、目的数据的索引操作，无法同步。
- 目的数据库需要创建，暂不支持在2个已有MongoDB实例之间直接搭通道。
- 当前只支持双活功能(2个MongoDB实例之间同步数据)，后续会上线多活功能(多个MongoDB实例之间同步数据)。
3. 架构
在“MongoDB云上灾备”产品中，主要有3大组件：
- BLS Manager。中心控制模块，负责Collector、Receiver的调度、监控等任务。
- BLS Collector。数据采集模块，负责从源MongoDB数据库拉取Oplog数据后发送到Kafka通道。
- BLS Receiver。数据回放模块，负责从Kafka通道中获取数据，然后写入目的MongoDB数据库。
下图展示了系统的整体架构图。
4. 用户使用案例
高德地图 App是国内首屈一指的地图及导航应用，阿里云MongoDB数据库服务为该应用提供了部分功能的存储支撑，存储亿级别数据。现在高德使用国内三中心的策略，通过地理位置等信息路由最近中心提升服务质量，业务方(高德地图)通过用户路由到三个城市数据中心，如下图所示，机房数据之间无依赖计算。数据在不同中心的同步通过“MongoDB云上灾备”产品实现。
这三个城市地理上从北到南横跨了整个中国 ，这对多数据中心如何做好复制、容灾提出了挑战，如果某个地域的机房、网络出现问题，可以平滑的将流量切换到另一个地方，做到用户几乎无感知？
目前策略是，拓扑采用机房两两互联方式，每个机房的数据都通过“MongoDB云上灾备”异步地将数据同步到另外两个机房。然后通过高德的路由层，将用户请求路由到不同的数据中心，读写均发送在同一个数据中心，保证一定的事务性。这样保证每个数据中心都有全量的数据(保证最终一致性) 。任意机房出现问题，另两个机房中的一个可以通过切换后提供读写服务。下图展示了城市1和城市2机房的同步情况。
遇到某个单元不能访问的问题，Manager通过“MongoDB云上灾备”产品管理接口，可以获得各个机房的同步偏移量和时间戳，通过判断采集和写入值即可判断异步复制是否在某个时间点已经完成。再配合业务方的DNS切流，切走单元流量并保证原有单元的请求在新单元是可以读写的，如下图所示。