Cloud-based disaster recovery and active-active architecture
ApsaraDB for MongoDB offers a cloud-based disaster recovery and active-active product to synchronize MongoDB instances. This product helps businesses quickly replicate Alibaba's active geo-redundancy architecture.
The cloud-based disaster recovery feature will be discontinued. In the future, Data Transmission Service (DTS) will support disaster recovery, active-active, and multi-active solutions for businesses that require disaster recovery capabilities across multiple data centers.
Architecture
Oplog (operations log): A log in MongoDB where all database modifications are recorded.
ReplicaA and ReplicaB: Independent three-node MongoDB replica set instances.
To ensure an active-active setup, both ReplicaA and ReplicaB must be writable. The client application must ensure that the same data is not written to both ReplicaA and ReplicaB at the same time.
Oplog synchronization: Oplog data is synchronized between instances using BLS and then replayed on the destination instance.
The cloud-based disaster recovery and active-active product for MongoDB has three main components:
BLS Manager: The central control module. It is responsible for tasks such as scheduling and monitoring the Collector and Receiver.
BLS Collector: The data collection module. It pulls Oplog data from the source MongoDB database and sends it to the Kafka channel.
BLS Receiver: The data replay module. It retrieves data from the Kafka channel and writes it to the destination MongoDB database.
The following figure shows the overall internal system architecture of the cloud-based disaster recovery and active-active product for MongoDB. The tunnel is implemented using Kafka.
Full and incremental synchronization
The synchronization model performs a full data synchronization when the task is created. Subsequent changes are synchronized using incremental data.
Active-active and multi-active models
Because data replication is asynchronous in active-active and multi-active models, the client application must ensure that the same unique key is not modified simultaneously.
Modifying the same unique key simultaneously can cause data inconsistency. The current conflict resolution strategy is to overwrite (later modifications overwrite earlier ones) or ignore the change.
Efficiency guarantee
The following three strategies ensure efficient data synchronization between instances:
Pull data from the source database in parallel and resolve conflict dependencies.
Send data from the source database to the Kafka channel in parallel.
Write data to the destination database in parallel and resolve dependencies.
Data synchronization latency between instances varies based on the region and network type. The cloud-based disaster recovery and active-active product for MongoDB can theoretically achieve a Transaction Per Second (TPS) of nearly 200,000. This means the product can transmit 200,000 Oplog entries per second. To ensure efficient batch data transmission, a caching mechanism is used. As a result, the synchronization latency for small amounts of data may exceed 5 seconds.
Circular replication
To prevent circular replication, where data is copied from the source to the destination and then back to the source, a `gid` is added to the Oplog entries.
Reliable transmission
The system supports resumable transmission from breakpoints. Data synchronization is not affected if an instance restarts.
High availability
The synchronization service is highly available. If a synchronization process fails, a standby process starts and takes over the service.
Limitations
Currently, only replica set instances support the cloud-based disaster recovery feature. Standalone instances or sharded cluster instances are not supported.
The source instance must run MongoDB 3.2 or 3.4. MongoDB 4.0 is not supported.
The source instance must use the WiredTiger storage engine.
Creating a synchronization channel directly between two existing MongoDB instances is not supported.
During the synchronization setup, the source instance restarts once to add the `gid` to the Oplog. If the source instance is very large, the restart can take several minutes.
Synchronization of Data Definition Language (DDL) operations is not supported. If you perform a DDL operation on the source instance, the destination instance does not synchronize this operation.
Currently, only the active-active feature is supported, which synchronizes data between two MongoDB instances.
Regions that support the cloud-based disaster recovery product
Data synchronization is supported between instances in the following regions. Synchronization can span across cities or countries, such as between Shanghai and Singapore.
The Chinese mainland
Region Name
City
Region ID
China (North) 1
Qingdao
cn-qingdao
China (North) 2
Beijing
cn-beijing
China (East) 1
Hangzhou
cn-hangzhou
China (East) 2
Shanghai
cn-shanghai
China (South) 1
Shenzhen
cn-shenzhen
Other countries and regions
Region Name
City
Region ID
China (Hong Kong)
Hong Kong (China)
cn-hongkong
US West
Silicon Valley
us-west-1
US East
Virginia
us-east-1