Multi-region Atlas deployments are clusters set up across more than one region. A multi-region deployment might have multiple regions within the same geography (a large area like a continent or country), a single region in each of several geographies, or multiple regions in multiple geographies. Multi-region deployments:
Enhance protection in the case of a regional outage by automatically rerouting traffic to another region for continuous availability and a smooth user experience.
Provide high performance and availability.
Ensure you meet compliance requirements for data sovereignty, such as the EU's General Data Protection Regulation (GDPR) law. You can set up one or more clusters in the regions where you need to ensure data sovereignty, and configure your architecture to write that specific data to the correct clusters. Any public data can be distributed to all of the clusters.
For example, you have an application that requires the storage of EU customers' data. You can create a multi-region deployment with clusters in
eu-west-1andeu-east-1,ap-south-1andap-northeast-1, andus-east-1. You store EU customer data only ineu-west-1andeu-east-1to ensure compliance with GDPR, APAC customer data toap-south-1andap-northeast-1, and distribute non-sensitive data to all 5 clusters. This ensures data sovereignty while offering high availability if there's a regional outage that affects one of the nodes.
Note
Multi-region deployments are available only for M10 dedicated
clusters and larger.
Multi-Region Deployment Strategies
The following diagram above shows 2 examples of a 2+2+1 topology, which is discussed in detail below.
The first example shows a single cluster with 5 nodes in 3 different regions:
2 clusters in US1, 2 in US2, and 1 in US3.
The second example shows this same 2+2+1 topology, but is distributed globally. It has 3 clusters, one in each of 3 geographies. Each cluster has the same 5-node regional distribution.
5-Node, 3-Region Architecture (2+2+1)
If you have a mission-critical application that requires both high availability and low latency, you need to deploy your MongoDB nodes and your application in multiple regions. Depending on your users' locations, you might need to deploy to regions in several different geographies.
To achieve this level of availability and latency, we recommend an architecture that consists of a minimum of 5 nodes spread over at least 3 regions. This architecture provides high availability in at least 2 regions. If a node goes down, the traffic can be served from the same region to ensure the same latency on the primary region.
This paradigm is the recommended architecture for large enterprises, because:
It provides high availability and low latency for users in multiple geographies.
It is a good strategy for complying with local regulations like GDPR. Individual customer data that needs to comply with regulations can be isolated to the cluster(s) in that region.
It provides high availability in at least 2 regions. If a cluster is unavailable, traffic can be served from the same region to ensure the same latency.
The following diagram shows details of this architecture:
Notes and Considerations
Deploy your application servers in each region that MongoDB nodes are deployed. This gives you the ability to route read requests to the in-region node, which reduces the response time to your users, and offloads requests from the primary node. Write requests are always directed to the primary.
Use private endpoints to connect to the cluster, and VPC peering between your application server VPCs. VPC peering ensures that if a network connection is broken or Atlas in that region goes down, the application tier can still route to the primary node, first over the VPC peering, and then over the private endpoint.
This architecture has the highest cost due to network traffic between regions and having 5 or more data-bearing nodes.
This architecture provides the highest resiliency. There are no interruptions during Atlas operations (like an automated upgrade), and your application can sustain a full regional failure with no interruption and manual intervention required.
5-Node, 2-Region Architecture (2+3)
If your company is limited to only 2 regions, you can use a variation on the 5-Node, 3-Region architecture, in which you have 5 nodes distributed between two regions. The primary region has 2 electable nodes, and the secondary region has 1 electable node and and 2 read-only (non-voting) nodes.
This is not generally recommended if you can use 3 regions. However, it is a good option for customers with only 2 approved regions.
Notes and Considerations
This architecture provides protection against data loss, even in full outage of the majority region, because the system remains available in read-only mode in the minority region.
While this architecture is less expensive than the 5-Node, 3-Region solution provided above, the reduced cost comes with some caveats:
If the majority region is lost, the minority region is not a fully-functional cluster; it does not have a primary and can only accept reads but not writes.
To turn it into a functional cluster again, an administrator needs to reconfigure the 2 read-only nodes to electable nodes. However, there is a possibility of data loss when the unavailable members are online again. If, for example, the original primary in the majority region didn't replicate the write operations to the new primary node, then the recovered replica set rolls back these writes. Any new writes are placed in a special collection for manual recovery. To learn more, refer to Reconfigure a Replica Set During a Regional Outage.
Note
If the minority region is lost, no action is required, since the majority region remains a fully functional cluster.
In sharded clusters, if your MongoDB process didn't replicate chunk migrations, the data inconsistency might cause orphaned documents.
Lower-Cost Variation
For further cost savings, you can design this architecture without the 2 read-only nodes. In addition to the caveats listed above, data size has a significant impact on your decision since the data needs to be synchronized to secondaries whenever adding new nodes to the cluster. For example, 1 TB of data averages 1 hour of recovery and synchronization time.
3-Node, 3-Region Architecture (1+1+1)
If you have an application that can experience temporary interruptions, and the cost of deployment is more of a factor than availability or latency, you can create an architecture that is less expensive by using 1 node in each of 3 regions. You have a electable node in each of the regions, which means if the primary node is unavailable, your cluster will fail over to a new region to ensure continued availability. However, if your app tier in the original primary region is still servicing user requests, there will be increased latency as requests are routed across multiple regions.
Note
We do not generally recommend this configuration because regular, planned maintenance of Atlas nodes will cause temporary interruptions.
Global Clusters
Global Atlas clusters are used in the most complex deployments, and therefore require very careful planning. In almost all cases, a Multi-Region Deployment Paradigm can fulfill your needs.
You might consider a global deployment strategy if:
You need a single global connection string.
You need to perform global aggregations across all users.
You need the ability to read/write for all users from everywhere in one logical cluster, while also having regional reads/writes.
Important
The complexity of global clusters results in many opinions on best practices. The Atlas Architecture Center does not currently cover recommendations specific to global clusters. Contact MongoDB's Professional Services team to discuss your specific requirements.
Recommendations for Multi-Region Deployments
To learn how to configure multi-region deployments and learn about the different types of nodes you can add, see Configure High Availability and Workload Isolation in the Atlas documentation.
To find recommendations for your Atlas cloud deployments, refer to the following resources:
Operational Efficiency
Security
Reliability
Performance
Cost Optimization