A modern managed database service such as Azure Cosmos DB for MongoDB has a growing list of requirements in today’s world. Prompt recovery of the database availability when its region becomes unavailable is one of such critical functions.

When a region is experiencing outage, there’re two primary methods for restoring access to data of a managed database located in that region – cross-region replication and backup. By default, vCore-based Azure Cosmos DB for MongoDB stores all cluster data in a selected Azure region. Today you can start using the new cross-region replication capability that allows you to maintain a replica cluster in another region. Having a replica of your data in another region mitigates the risks of prolonged database unavailability in case of a region outage. This blog is about cross-region replication preview in vCore-based Azure Cosmos DB for MongoDB.

Why disaster recovery (DR) matters

While regional outages are becoming less and less frequent, the consequences of such an outage could be serious. Shorter and more localized issues than the whole region outage can be addressed through the high availability part of the application and via enabling the high availability feature in a managed database. A disaster such as one caused by natural causes has a major, long-lasting impact on availability of services in a region.

Cross-region disaster recovery (DR) plan includes application, database, and other critical parts of a solution. Most services that run on Azure platform as a service (PaaS) offerings like Azure Cosmos DB for MongoDB provide features and guidance to support DR.

Cross-region replication as a disaster recovery tool

Cross-region replication in vCore-based Azure Cosmos DB for MongoDB allows you to replicate data from a cluster in the primary region to a replica cluster hosted in another Azure region. Replicas are new clusters that you manage like regular clusters. Data on a replica is updated asynchronously to avoid performance impact due to cross-region latencies.

The main reason to have cross-region replication set up is to have a replica of the primary cluster’s data in another Azure region readily available. When an outage in the primary region happens, a replica cluster is ready to take over and become the new read-write cluster.

The process of a replica cluster taking over the role of the primary cluster is called replica promotion. When you promote a replica cluster to become the new primary cluster the following happens:

• Write operations are disabled on the primary cluster in region A.
• Write operations are enabled on the replica cluster in region B. The replica cluster becomes the new primary (read-write cluster).
• Cluster in region A becomes a replica of the new primary cluster in region B.

The promotion of a replica takes a few minutes. Once completed, the primary read-write cluster is in region B where the replica cluster was located before the replica promotion. The replica cluster is now in region A where the primary cluster was located before the promotion. This region swap allows you to preserve your data presence in the same regions as before replica promotion with the writes now performed in region B.

During replica promotion replication is re-established with another direction. That way data written in region B on the promoted replica cluster is brought to the replica cluster in region A. Data that wasn’t replicated to the replica at the time of its promotion would not be present on either cluster.

If you need to swap the read-write and replica regions again to restore original replication setup, you can promote replica cluster in region A.

Read scaling as a benefit of cross-region replication

When you enable cross-region replication on a vCore-based Azure Cosmos DB for MongoDB cluster, the replica cluster in another Azure region becomes available for reads. The read replica feature helps to improve the performance and scale of read-intensive workloads. In particular, this capability is beneficial in two ways:

• You can offload some intensive read operations off the primary cluster thus balancing the load between two clusters.
• Applications that are located closer to the replica cluster can benefit from lower latency when reads are served from the replica cluster.

When you create a replica, it doesn’t inherit networking settings such as firewall rules of the primary cluster. These settings must be set up independently for the replica cluster to enable read access. The replica cluster also always has the same compute and storage configuration as the primary cluster.

The replica cluster inherits the admin account from the primary cluster. You can connect to the replica cluster by using its host name and a valid user account, as you would on a regular cluster. You can find connection string for the replica cluster on its ‘Connection strings’ page similar to the primary cluster.

Cross-region replication considerations

A replica cluster can be created during the primary cluster provisioning or any time after the cluster is created. If you are going to try cross-region replication later, you might want to add a replica after cluster creation. Another thing to consider is how much data you expect to have on your cluster. For instance, if you ingest a few terabytes of data first and then enable cross-region replication, the initial replication to another region might take a while. If you would like to avoid it, you can enable cross-region replication at the cluster creation time or before ingesting large chunks of data.

Whether a replica is created during cluster provisioning or later, it’s important to enable access to the cross-replication feature preview during cluster provisioning. To do it, set ‘Access to global distribution (preview)’ checkbox on the ‘Basics’ tab when you create your vCore-based Azure Cosmos DB for MongoDB cluster.

Then you can add a replica cluster on the ‘Global distribution’ tab by entering the replica’s name and selecting the region for the cluster replica. Alternatively, you can proceed with cluster creation and then add a cluster replica at any time later on the ‘Global distribution (preview)’ page of your vCore-based Azure Cosmos DB for MongoDB cluster.

Next steps: Cross-region DR and read scalability in vCore-based Azure Cosmos DB for MongoDB

Whether you are interested in cross-region disaster recovery, or setting up a read replica in another region, or both, you can try the cross-region replication feature in preview today.

• Check out details about how cross-region replication works
• Follow these steps to enable cross-region replication on your next vCore-based Azure Cosmos DB for MongoDB cluster
• Use this quickstart guide to create a cluster replica in another region, ingest data, read data from replica, and promote read replica to become the new primary cluster

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless distributed database for modern app development, with SLA-backed speed and availability, automatic and instant scalability, and support for open-source PostgreSQL, MongoDB, and Apache Cassandra. Try Azure Cosmos DB for free here. To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn.