> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

<!--
Tab options on this page. Append to the .md URL to filter:
  ?tabs=<id,...>   select specific tabs (e.g. ?tabs=nodejs,shell)
  ?allTabs=true    include every tab
  (no param)       default: one tab per tabset

Available tabs:
  other tabs: devtest, stagingprod, cli, Terraform
-->

# Guidance for Atlas High Availability

The Atlas Architecture Center is in early release. MongoDB plans to add recommendations for compliance with external standards and a plug-and-play Terraform code repository in future releases.

High availability is the ability of your application to ensure continuous operation and minimize downtime during infrastructure outages, system maintenance, and other disruptions. MongoDB's default deployment architecture is designed for high availability, with built-in features for data redundancy and automatic failover.

High availability differs from disaster recovery. High availability protects against infrastructure failures like node, zone, region, or cloud provider outages through automatic failover that recovers to the exact moment of failure with no data loss (RPO (Recovery Point Objective) = 0) and RTO (Recovery Time Objective) in seconds. Disaster recovery protects against data integrity issues like corruption or accidental deletion, which require restoration from backups. To learn more about disaster recovery, see [Guidance for Atlas Disaster Recovery.](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-dr)

This page describes additional configuration options and deployment architecture enhancements you can choose from to prevent disruptions and support robust failover mechanisms for zone, region, and cloud provider outages.

## Atlas Features for High Availability

### Database Replication

MongoDB's default deployment architecture is designed for redundancy. Atlas deploys each cluster as a [replica set](https://www.mongodb.com/docs/manual/core/replication/) with a minimum of three database instances (also called nodes or replica set members), distributed across separate availability zones within your selected cloud provider regions. Applications write data to the replica set's [primary node](https://www.mongodb.com/docs/manual/core/replica-set-primary/), and then Atlas replicates and stores that data across all nodes within your cluster. To control the durability of your data storage, you can adjust the [write concern](https://www.mongodb.com/docs/manual/reference/write-concern/) of your application code to complete the write only once a certain number of secondaries have committed the write. The default behavior is for data to be persisted on a majority of electable nodes before confirming the action.

The following diagram represents how replication works for a default three-node replica set:

![An image showing the replication process in a three-node replica set.](/_includes/images/atlas-database-replication.png)

### Automatic Failover

In the event that a primary node in a replica set becomes unavailable due to an infrastructure outage, scheduled maintenance, or any other disruption, Atlas clusters self-heal by promoting an existing secondary node to the role of primary node in a [replica set election](https://www.mongodb.com/docs/manual/core/replica-set-elections/). This failover process is fully automatic and recovers to the exact moment of failure with no data loss (RPO = 0) in seconds. Operations that were in flight at the time of the failure are retried after the failure if [retryable writes](https://www.mongodb.com/docs/manual/core/retryable-writes/) are enabled. After a replica set election, Atlas restores or replaces the failing member to ensure that the cluster is returned to its target configuration as soon as possible. The MongoDB client driver also automatically switches all client connections during and after the failure.

The following diagram represents the replica set election process:

![An image showing the self-healing primary election process in a three-node replica set.](/_includes/images/atlas-self-healing.png)

To improve availability for your most critical applications, you can scale your deployment by adding nodes, regions, or cloud providers to withstand zone, region, or provider outages, respectively. To learn more, see the [Scale Your Deployment Paradigm for Fault Tolerance](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-scale-for-fault-tolerance) recommendation below.

## Recommendations for Atlas High Availability

The following recommendations describe additional configuration options and deployment architecture enhancements you can make to increase availability for your deployment.

### Choose a Cluster Tier that Fits your Deployment Goals

You can choose between a range of cluster tiers available under the Dedicated, Flex, or Free deployment types. The cluster tier in MongoDB Atlas specifies the resources (memory, storage, vCPUs, and IOPS) available for each node in your cluster. Scaling to a higher tier improves your cluster's ability to handle spikes in traffic and increases system reliability through faster response to high workloads. To determine the recommended cluster tier for your application size, see the [Atlas Cluster Size Guide.](https://www.mongodb.com/docs/atlas/architecture/current/hierarchy.md#std-label-arch-center-cluster-size-guide)

Atlas also supports [auto-scaling](https://www.mongodb.com/docs/atlas/cluster-autoscaling.md#std-label-cluster-autoscaling) to allow the cluster to automatically adjust to spikes in demand. Atlas uses both reactive auto-scaling, which triggers based on current resource usage, and [predictive auto-scaling](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-predictive-autoscaling-overview), which proactively scales up eligible clusters before forecasted cyclical demand spikes occur. Automating scaling actions reduces the risk of an outage due to resource constraints. To learn more, see [Guidance for Atlas Automated Infrastructure Provisioning.](https://www.mongodb.com/docs/atlas/architecture/current/automation.md#std-label-arch-center-automation)

### Scale Your Deployment Paradigm for Fault Tolerance

An Atlas deployment's fault tolerance is the number of [replica set](https://www.mongodb.com/docs/manual/core/replication/) members that can become unavailable while your deployment still remains operational. In the event of an availability zone, region, or cloud provider outage, Atlas clusters self-heal by promoting an existing secondary node to the role of primary node in a [replica set election](https://www.mongodb.com/docs/manual/core/replica-set-elections/). A majority of the voting nodes in a replica set must be operational in order to run a replica set election when a primary node experiences an outage.

To ensure that a replica set can elect a primary in the case of a partial-region outage, you should deploy clusters to regions with at least three availability zones. Availability zones are separated groups of datacenters within a single cloud provider region, each with its own power, cooling, and networking infrastructure. Atlas automatically distributes your cluster across availability zones when they are supported by your selected cloud provider region, so that if one zone experiences an outage, the remaining nodes in your cluster still support regional services. Most Atlas-supported cloud provider regions have at least three availability zones. These regions are marked with a star icon in the Atlas UI.

Each cloud provider provides default data redundancy within availability zones:

- AWS (Amazon Web Services) stores data on multiple devices across a minimum of three Availability Zones in an AWS (Amazon Web Services) Region.

- Microsoft Azure uses locally redundant storage (LRS) that replicates data three times within a single data center in the selected region.

- Google Cloud spreads data across multiple zones in the region.

For more information about recommended regions, see [Cloud Providers and Regions.](https://www.mongodb.com/docs/atlas/cloud-providers-regions.md#std-label-create-cluster-cloud-provider-region)

To further improve fault tolerance for your most critical applications, you can scale your deployment by adding nodes, regions, or cloud providers to withstand availability zone, region, or provider outages, respectively. You can increase the node count to any odd number of nodes, with a maximum of 7 electable nodes and 50 total nodes. You can also deploy a cluster to multiple regions to enhance availability across a larger geography and enable automatic failover in the case of a full-region outage that disables all availability zones within your primary region. The same pattern applies to deploying your cluster to multiple cloud providers in order to withstand a full cloud provider outage.

For guidance on how to choose a deployment that balances your needs for high availability, low latency, compliance, and cost, see our [Atlas Deployment Paradigms](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms.md#std-label-arch-center-paradigms) documentation.

#### Deployment Paradigm RTO/RPO Trade-offs

The following table compares the RTO and RPO characteristics of different deployment paradigms. With `majority` write concern, all of these approaches achieve RPO = 0 (no data loss) and RTO in seconds. The trade-offs are in deployment complexity and cluster cost.

| Deployment paradigm | Failure scenarios covered | Typical RTO | RPO (with majority write concern) | Relative complexity | Relative cluster cost |
| --- | --- | --- | --- | --- | --- |
| Single-region deployment (3 nodes in 1 region) | Node or AZ failure within a single region | Seconds (automatic failover) | 0 (no data loss) | Low | $ |
| Multi-region, single cloud | AZ or region outage in one geography | Seconds (automatic failover) | 0 (no data loss) | Medium | $$ |
| Multi-region, multi-geo | Region or geography outage across multiple geographies | Seconds (automatic failover) | 0 (no data loss) | Medium–High | $$–$$$ |
| Multi-cloud (2–3 providers) | Cloud provider or multi-region outage affecting one provider | Seconds (automatic failover) | 0 (no data loss) | High | $$$ |

### Prevent Accidental Cluster Deletion

You can [enable termination protection](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-create-cluster-termination-protection) to ensure that a cluster will not be accidentally terminated and require downtime to restore from a backup. To delete a cluster that has termination protection enabled, you must first disable termination protection. By default, Atlas disables termination protection for all clusters.

Termination protection is especially important when you use IaC (Infrastructure as Code) tools like Terraform to ensure that a redeployment does not provision new infrastructure.

### Test Automatic Failovers

We strongly recommend that you simulate various scenarios that require automatic node failovers to measure your preparedness for such events before you deploy an application to production. With Atlas, you can [test primary node failover](https://www.mongodb.com/docs/atlas/tutorial/test-resilience/test-primary-failover.md#std-label-test-failover) for a replica set and [simulate regional outages](https://www.mongodb.com/docs/atlas/tutorial/test-resilience/simulate-regional-outage.md#std-label-test-outage) for a multi-region deployment.

### Use `majority` Write Concern

MongoDB allows you to specify the level of acknowledgment requested for write operations by using [write concern](https://www.mongodb.com/docs/manual/reference/write-concern/). Atlas has a default write concern of `majority`, meaning that data must be replicated across more than half of the nodes in your cluster before Atlas reports success. Using `majority` instead of a definite number value like `2` allows Atlas to automatically adjust to requiring replication across fewer nodes if you experience a temporary node outage, allowing writes to continue after automatic failover. This also provides a consistent setting across all environments, so your connection string remains the same whether you have three nodes in a test environment or a larger number of nodes in production.

### Configure Retryable Database Reads and Writes

Atlas supports [retryable read](https://www.mongodb.com/docs/manual/core/retryable-reads/) and [retryable write](https://www.mongodb.com/docs/manual/core/retryable-writes/) operations. When enabled, Atlas retries read and write operations once as a safeguard against intermittent network outages and replica set elections in which the application temporarily cannot find a healthy primary node. Retryable writes require an acknowledged [write concern](https://www.mongodb.com/docs/manual/reference/write-concern/), meaning your write concern cannot be `{w:
0}`.

### Monitor and Plan Your Resource Utilization

To avoid resource capacity issues, we recommend that you monitor resource utilization and hold regular capacity planning sessions. MongoDB's [Professional Services](https://www.mongodb.com/services/consulting) offers these sessions. See our [Resource Capacity Disaster Recovery Plan](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-resource-capacity) for our recommendations on how to recover from resource capacity issues.

To learn best practices for alerts and monitoring for resource utilization, see [Guidance for Atlas Monitoring and Alerts.](https://www.mongodb.com/docs/atlas/architecture/current/monitoring-alerts.md#std-label-arch-center-monitoring-alerts)

### Plan Your MongoDB Version Changes

We recommend that you run the latest MongoDB version to take advantage of new features and improved security guarantees. You should always ensure that you upgrade to the latest MongoDB major version before your current version reaches [end of life.](https://www.mongodb.com/legal/support-policy/lifecycles)

You can't downgrade your MongoDB version using the Atlas UI. Because of this, we recommend that you work directly with MongoDB's [Professional Services](https://www.mongodb.com/services/consulting) or Technical Services when planning and executing a major version upgrade to help you avoid any issues that might occur during the upgrade process.

### Configure Maintenance Windows

Atlas maintains uptime during scheduled maintenance by applying updates in a rolling fashion to one node at a time. Whenever the current primary is taken offline for maintenance during this process, Atlas elects a new primary through an automatic [replica set election](https://www.mongodb.com/docs/manual/core/replica-set-elections/). This is the same process that occurs during automatic failover in response to an unplanned primary node outage.

We recommend that you [configure a custom maintenance window](https://www.mongodb.com/docs/atlas/tutorial/cluster-maintenance-window.md#std-label-configure-maintenance-window) for your project to avoid maintenance-related replica set elections during business-critical hours. You can also set protected hours in your maintenance window settings to define a daily window of time in which standard updates cannot begin. Standard updates do not involve cluster restarts or resyncs.

## Automation Examples: Atlas High Availability

The following examples configure the Single Region, 3 Node Replica Set / Shard deployment topology using Atlas [tools for automation.](https://www.mongodb.com/docs/atlas/architecture/current/automation.md#std-label-arch-center-automation)

These examples also apply other recommended configurations, including:

### Dev and Test Environments

- Cluster tier set to `M10` for a dev/test environment. Use the [cluster size guide](https://www.mongodb.com/docs/atlas/architecture/current/hierarchy.md#std-label-arch-center-cluster-size-guide) to learn the recommended cluster tier for your application size.

- Single Region, 3-Node Replica Set / Shard deployment topology.

Our examples use AWS (Amazon Web Services), Azure (Microsoft Azure), and Google Cloud interchangeably. You can use any of these three cloud providers, but you must change the region name to match the cloud provider. To learn about the cloud providers and their regions, see [Cloud Providers.](https://www.mongodb.com/docs/atlas/reference/cloud-providers/)

### CLI

**Note:**

Before you can create resources with the Atlas CLI, you must:

- [Create your paying organization](https://www.mongodb.com/docs/atlas/billing/#configure-a-paying-organization) and [create an API key](https://www.mongodb.com/docs/atlas/configure-api-access/) for the paying organization.

- [Install the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/install-atlas-cli/)

- [Connect from the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/connect-atlas-cli/) using the steps for Programmatic Use.

### Create One Deployment Per Project

### Dev and Test Environments

For your development and testing environments, run the following command for each project. In the following example, change the IDs and names to use your values.

**Note:**

The following example doesn't enable auto-scaling to help control costs in development and testing environments. For staging and production environments, [auto-scaling should be enabled](https://www.mongodb.com/docs/atlas/architecture/current/scalability.md#std-label-arch-center-scalability). See the "Staging and Prod Environments" tab for examples that enable auto-scaling.

```text
atlas clusters create CustomerPortalDev \
  --projectId 56fd11f25f23b33ef4c2a331 \
  --region EASTERN_US \
  --members 3 \
  --tier M10 \
  --provider GCP \
  --mdbVersion 8.0 \
  --diskSizeGB 30 \
  --tag bu=ConsumerProducts \
  --tag teamName=TeamA \
  --tag appName=ProductManagementApp \
  --tag env=dev \
  --tag version=8.0 \
  --tag email=marissa@example.com \
  --watch
```

For more configuration options and info about this example, see the [atlas clusters create](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-create.md#std-label-atlas-clusters-create) command.