Guidance for Atlas High Availability

Single Region, 3 Node Replica Set / Shard (Primary Secondary Secondary)

This topology is appropriate if low latency is required but high availability requirements are limited to a single region. This topology can tolerate any 1 node failure and easily satisfy majority write concern within region secondaries. This will maintain a primary in the preferred region upon any node failure, limits cost, and is the least complicated from an application architecture perspective. The reads and writes from secondaries in this topology encounter low latency in your preferred region.

This topology, however, can't tolerate a regional outage.

Choose a Deployment Type and Cluster Tier that Fits your Deployment Goals

When creating a new cluster, you can choose between between a range of cluster tiers available under the Dedicated, Flex, or Free deployment types.

To determine the recommended cluster tier for your application size, see the Atlas Cluster Size Guide .

Use an Odd Number of Replica Set Members and Test Failover

To elect a primary, you need a majority of voting replica set members available. We recommend that you create replica sets with an odd number of voting replica set members. There is no benefit in having an even number of voting replica set members. Atlas satisfies this requirement by default, as Atlas requires having 3, 5, or 7 nodes.

Fault tolerance is the number of replica set members that can become unavailable with enough members still available for a primary election. Fault tolerance of a four-member replica set is the same as for a three-member replica set because both can withstand a single-node outage.

To test if your application can handle a failure of the replica set primary, submit a request to test primary failover. When Atlas simulates a failover event, Atlas shuts down the current primary and holds an election to elect a new primary.

To learn more about replica set members, see Replica Set Members. To learn more about replica set elections and voting, see Replica Set Elections.

Distribute Data Across At Least Three Data Centers in Different Availability Zones

MongoDB provides high availability by storing multiple copies of data across replica sets. To ensure that members of the same replica set don't share the same resources, and that a replica set can elect a primary if a data center becomes unavailable, you must distribute nodes across at least three data centers. We recommend that you use at least five data centers.

You can distribute data across multiple data centers by deploying your cluster to a region that supports multiple availability zones. Each availability zone typically contains one or more discrete data centers, each with redundant power, networking and connectivity, often housed in separate facilities. When you deploy a dedicated cluster to a region that supports availability zones, Atlas automatically splits your cluster's nodes across the availability zones. For example, for a three-node replica set cluster deployed to a region with three availability zones, Atlas deploys one node in each zone. This ensures that members of the same replica set are not sharing resources, so that your database remains available even if one zone experiences an outage.

To understand the risks associated with using fewer than three data centers, consider the following diagram, which shows data distributed across two data centers:

In the previous diagram, if Data Center 2 becomes unavailable, a majority of replica set members remain available and Atlas can elect a primary. However, if you lose Data Center 1, you have only one out of three replica set members available, no majority, and the system degrades into read-only mode.

Consider the following diagram, which shows a five-node replica set cluster deployed to a region with three availability zones:

click to enlarge

The 2-2-1 topology in the previous diagram is our recommended topology to balance high availability, performance, and cost across multiple regions. In this topology, if any one data center fails, a majority of replica set members remain available and Atlas can perform automatic faiilover. While a three-node, three-region topology can also tolerate any one-region failure, any failover event in a 1-1-1 topology forces a new primary to be elected in a different region. The 2-2-1 topology can tolerate a primary node failure while keeping the new primary in the preferred region.

We recommend that you deploy replica sets to the following regions because they support at least three availability zones:

Use mongos Redundancy for Sharded Clusters

When a client connects to a sharded cluster, we recommend that you include multiple mongos processes, separated by commas, in the connection URI. To learn more, see MongoDB Connection String Examples. This setup allows operations to route to different mongos instances for load balancing, but it is also important for disaster recovery.

Consider the following diagram, which shows a sharded cluster spread across three data centers. The application connects to the cluster from a remote location. If Data Center 3 becomes unavailable, the application can still connect to the mongos processes in the other data centers.

click to enlarge

You can use retryable reads and retryable writes to simplify the required error handling for the mongos configuration.

Use majority Write Concern

MongoDB allows you to specify the level of acknowledgment requested for write operations by using write concern. For example, if you have a three-node replica set with a write concern of majority, every write operation needs to be persisted on two nodes before an acknowledgment of completion is sent to the driver that issued said write operation. For the best protection from a regional node outage, we recommend that you set the write concern to majority.

Even though using majority write concern increases write latency compared with write concern 1, we recommend that you use majority write concern because it allows your data centers to continue performing write operations even if a replica set loses the primary.

To understand the advantage of using majority write concern over a numeric write concern, consider a three-region, five-node replica set with a 2-2-1 topology, with a numeric write concern of 4. If one of the two-node regions becomes unavailable, write operations cannot complete because they are unable to persist data on four nodes. Using majority will allow write operations to continue when they persist data across at least two nodes, maintaining data redundancy as well as write continuity.

Consider Backup Configuration

Frequent data backups is critical for business continuity and disaster recovery. Frequent backups ensure that data loss and downtime is minimal if a disaster or cyber attack disrupts normal operations.

We recommend that you:

• Set your backup frequency to meet your desired business continuity objectives. Continuous backups may be needed for some systems, while less frequent snapshots may be desirable for others.

• Store backups in a different physical location than the source data.

• Test your backup recovery process to ensure that you can restore backups in a repeatable and timely manner.

• Confirm that your clusters run the same MongoDB versions for compatibility during restore.

• Configure a backup compliance policy to prevent deleting backup snapshots, prevent decreasing the snapshot retention time, and more.

For more backup recommendations, see Guidance for Atlas Backups.

Plan Your Resource Utilization

To avoid resource capacity issues, we recommend that you monitor resource utilization and hold regular capacity planning sessions. MongoDB Professional Services offers these sessions.

Over-utilized clusters could fail causing a disaster. Scale up clusters to higher tiers if your utilization is regularly alerting at a steady state, such as above 60%+ utilization for system CPU and system memory.

To view your resource utilization, see Monitor Real-Time Performance. To view metrics with the Atlas Administration API, see Monitoring and Logs.

To learn best practices for alerts and monitoring for resource utilization, see Guidance for Atlas Monitoring and Alerts.

If you encounter resource capacity issues, see Resource Capacity Issues.

Plan Your MongoDB Version Changes and Maintenance

We recommend that you run the latest MongoDB version as it allows you to take advantage of new features and provides improved security guarantees compared with previous versions.

Ensure that you perform MongoDB major version upgrades far before your current version reaches end of life.

You can't downgrade your MongoDB version using the Atlas UI. Because of this, when planning and executing a major version upgrade, we recommend that you work directly with MongoDB Professional or Technical Services to help you avoid any issues that might occur during the upgrade process.

Configure Maintenance Windows

MongoDB allows you to configure a maintenance window for your cluster, which sets the hour of the day when Atlas starts weekly maintenance on your cluster. Setting a custom maintenance window allows you to schedule maintenance, which requires at least one replica set election per replica set, outside of business-critical hours.

You can also set protected hours for your project, which defines a daily window of time in which standard updates cannot begin. Standard updates do not involve cluster restarts or resyncs.