Navigation

Modify a Cluster

Atlas Configuration Options

Cloud Service Provider & Region

You can modify the cloud service provider backing the Atlas cluster. Transitioning to a different provider requires your cluster connection string to change.

You can also change the cluster’s region.

Deploy or Configure a multi-region cluster You can deploy or modify a multi-region cluster.
Instance Size You can modify the instance size of the cluster.
Instance Storage Options You can modify the storage options for the selected instance size.
MongoDB Version

You can upgrade the major MongoDB version of the cluster.

Only available for cluster with an Instance Size of M10 or larger.

You cannot downgrade the MongoDB version of a cluster.

Deploy a Sharded Cluster

If your cluster is a replica set, you can upgrade the deployment to a sharded cluster.

Only available for clusters with an Instance Size of M30 or larger.

Modify the Number of Shards

You can configure the number of shards in the sharded cluster.

Only available for sharded cluster deployments.

Enable or Disable Backup You can enable or disable backups for the cluster. Only available for clusters with an Instance Size of M10 or larger.
Enable or Disable the Business Intelligence Connector

You can enable or disable the BI Connector for Atlas for this cluster.

The BI Connector for Atlas is only available for M10+ clusters.

Confirm and Deploy Confirm and deploy your cluster with the selected changes.

Considerations

Migration, Downtime, and Performance Impact

The time required for an initial sync and resynchronizing data across storage volumes increases linearly with the amount of data in the cluster. Making changes to a cluster often requires migrating to new servers and storage volumes, which can take a long time. However, cluster changes can be made more quickly in some cases. For example, changing the instance size of a cluster on AWS does not require an initial sync.

Note

All changes on Azure and GCP require an initial sync. In addition, all changes to M0, M2, and M5 clusters require 7-10 minutes of downtime.

To maximize availability:

  • For a replica set, Atlas migrates one node at a time, starting with the secondary nodes first and then the primary.
  • For a sharded cluster, Atlas performs the migration of the shards independently of each other. For each shard (i.e. replica set), Atlas migrates one node at a time, starting with the secondary nodes first and then the primary.

Downtime occurs during the migration of the primary when the current primary becomes unavailable and lasts until the election of a new primary, generally under a minute.

Migration can affect performance if your primary is already reaching operational capacity: each newly migrated replica set node must perform an initial sync from the primary, adding to the operational load. Migrations can also affect performance if read preferences are set to read from secondaries: the replica set is down one secondary during the migration.

If the workload on the Atlas cluster is such that it impedes operations, including the ability to scale, MongoDB Atlas may, in some situations, create indexes in your cluster as a safeguard.

Billing

As you modify your cluster, you can compare the costs of different options before applying them. The Cluster Overview box displays the cost of the selected configuration, excluding data transfer.

Free Tier

Upgrading an M0 Free Tier cluster to an M2 or greater paid tier cluster starts billing for the cluster. See Billing for complete documentation on Atlas billing.

The following sections provide complete documentation for each of the Atlas cluster scaling configuration options.

A. Open the Editing Cluster Dialog

For the cluster you want to modify, click the ellipses icon, then select Edit Configuration.

Alternatively, if you are already viewing the specific cluster, click the Configuration button.

For M0 Free Tier clusters, you can also click the Upgrade button for the cluster.

B. Modify the Cloud Provider & Region of the Cluster

Important

Changing the Cloud Provider for the cluster changes the connection string for that cluster. You must update your applications with the new connection string to resume connectivity to the cluster. Consider scheduling a maintenance window for migrating your cluster to a new cloud provider.

Select Cloud Provider & Region to view the currently configured cloud provider and region for the cluster.

You can change the Cloud Provider backing your cluster by selecting from the available Cloud Service Providers.

Review the available regions for the selected cloud provider.

Regions marked as Free Tier Available support deploying M0 Free Tier clusters.

Regions marked as ★ are Recommended regions that provide higher availability compared to other regions. For more information, see:

The number of availability zones, zones, or fault domains in a region has no affect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes.

The choice of cloud provider and region affects the configuration options for the available instance sizes, network latency for clients accessing your cluster, and the cost of running the cluster.

Deploy or Modify a Multi-Region Cluster

To deploy a cross-region cluster, toggle Configure clusters across multiple regions (M10 and up) to Yes.

AWS Only

If this is the first M10+ dedicated paid cluster for the selected region or regions and you plan on creating one or more VPC peering connections, please review the documentation on VPC Peering Connections before continuing.

The following options are available when configuring cross-region clusters:

Deploy across multiple regions

Click Add a node to add a new row for region selection and select the region from the dropdown. Specify the desired number of Nodes for the region.

The first row lists the Preferred Region. Atlas prioritizes nodes in the preferred region for primary elegibility.

Backup Data Center Location

If this is the first cluster in the project and you intend to enable continuous snapshot backups, Atlas selects the backup data center location for the project based on the geographical location of the cluster’s Preferred Region. See Backup a Cluster for more information.

When selecting a Region, regions marked as Recommended provide higher availability compared to other regions. For more information, see:

Each node in the selected regions can participate in elections, and can become the primary as long as the majority of nodes in the replica set are available. The total number of electable nodes across all regions, excluding read-only regions, must be 3, 5, or 7.

You can also use this option to increase the replication factor of single-region clusters by modifying the number of Nodes for your Preferred Region only. You do not have to add additional regions to modify the replication factor of your Preferred Region.

To remove a region, click the X next to that region. You cannot remove the Preferred Region.

Atlas provides checks for whether your selected cross-regional configuration provides availability during partial or whole regional outages.

Deploy read-only replicas

Click Add a node to deploy read-only nodes to the selected region.

Each node in the region cannot participate in elections, and cannot become the primary. Read-only regions do not provide high availability.

To remove a read-only region, click the X next to that region.

Note

Having a large number of regions or having nodes spread across long distances may lead to long election times or replication lag.

Important

For a given region in an Atlas project with multi-region clusters, the total sum of MongoDB nodes on all other regions in that project cannot exceed 40. This limit applies across all cloud service providers.

For example, if an Atlas project has 20 nodes in Region A and 20 nodes in Region B, you can deploy no more than 20 additional nodes in that project in any given region. This limit applies even if Region A and Region B are backed by different cloud service providers.

For Atlas projects where every cluster is deployed to a single region, you cannot create a multi-region cluster in that project if there are already 40 or more nodes in that single region.

C. Modify the Cluster Tier of the Cluster

Free Tier

You cannot downgrade a cluster to an M0 Free Tier cluster.

You can change the instance size, as well as the memory, storage, and IOPS (speed) specifications for the selected instance size.

Select your preferred cluster instance size. The selected instance size dictates the memory, storage, and IOPS specification for each data-bearing server [1] in the cluster.

Atlas categorizes the instance sizes into tiers as follows:

Shared Clusters

Sandbox replica set clusters for getting started with MongoDB. These instances deploy to a shared environment with access to a subset of Atlas features and functionality. For complete documentation on shared cluster limits and restrictions, see Atlas M0 (Free Tier), M2, and M5 Limitations.

Atlas provides an option to deploy one M0 Free Tier replica set per project. You can upgrade an M0 Free Tier cluster to an M2+ paid cluster at any time.

M2 and M5 instances are low-cost shared starter clusters with the same features as and functionality as M0, but with increased storage and the ability to deploy into a subset of regions on Amazon Web Service (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

Beta

Support for M2 and M5 clusters is available as a Beta feature. These clusters do not yet support backups.

Atlas supports shared cluster deployment in a subset of Cloud Providers and Regions. Atlas greys out any shared cluster instance sizes not supported by the selected cloud service provider and region. For a complete list of regions that support shared cluster deployments, see:

Dedicated Development Clusters

Instances that support development environments and low-traffic applications.

These instances support replica set deployments only, but otherwise provide full access to Atlas features and functionality.

Dedicated Production Clusters

Instances that support production environments with high traffic applications and large datasets.

These instances support replica set and sharded cluster deployments with full access to Atlas features and functionality.

Some instances have variants, denoted by the ❯ character. When you select these instances, Atlas lists the variants and tags each instance to distinguish their key characteristics.

The following table highlights key differences between an M0 Free Tier cluster, an M2 or M5 shared starter cluster, and an M10+ dedicated cluster.

  Free Tier Cluster (M0) Shared Starter Cluster (M2 and M5) Dedicated Cluster (M10 and larger)
Storage
512 MB
M2: 2 GB
M5: 5 GB
10 - 4000 GB
MongoDB Version Support 3.6 3.6 3.2, 3.4, 3.6, 4.0
Data Visualization No No Atlas Data Explorer
Metrics and Alerts Limited Limited Full metrics, including the Real Time Performance Tab, and full alert configuration options.
VPC Peering (AWS clusters only) No No VPC Peering Connection wizard
Global Region Selection Atlas supports deploying M0 instances in a subset of regions in AWS only. Atlas supports deploying M2 and M5 clusters in a subset of regions in AWS, GCP, and Azure. Atlas supports deploying clusters globally on Amazon Web Services, Google Cloud Platform, and Microsoft Azure
Cross-Region Deployments No No Yes. Specify additional regions for high availability or local reads when creating or scaling a cluster.
Backups No No Yes, including queryable backups
Sharding No No Yes, for clusters using an M30+ instance
Dedicated Instance No, M0 Free Tier clusters run in a shared environment No, M2 and M5 clusters run in a shared environment Yes, M10+ clusters deploy each mongod process to its own instance.
Performance Advisor No No Yes
BI Connector for Atlas No No Yes

For a complete list of M0 (Free Tier), M2, and M5 limitations, see Atlas M0 (Free Tier), M2, and M5 Limitations.

Customize the Storage Settings of the Selected Instance

Each cluster tier comes with a default set of resources. Select your preferred storage customizations under the Customize Your Storage heading.

Atlas can provide the following storage configuration options depending on the selected cloud provider and instance size.

  • Storage Capacity The size of the server root volume. To change this, either:

    • Move the slide bar until the text box displays your preferred disk size, or
    • Specify the exact disk size in the text box.

    Changes to storage capacity affects cost.

  • Storage Speed The input/output operations per second (IOPS) the system can perform. Changes to storage speed affects cost.

  • Auto-Expand Storage: When disk usage reaches 90%, automatically increase storage by an amount necessary to achieve 70% utilization. Changes to storage capacity affects cost.

    Note

    If the size of the cluster oplog is small, Atlas may be unable to automatically expand disk capacity.

For more information on the default resources and available configuration options for each cloud service provider, see:

D. Modify the Additional Settings of the Cluster

Upgrade the MongoDB Version of the Cluster

Select Additional Settings to view the currently configured MongoDB version for the cluster.

Atlas always upgrades the cluster to the latest stable release of the specified version via a rolling process to maintain cluster availability.

You cannot downgrade the cluster to an earlier MongoDB version.

Select the new MongoDB version from the Select a version dropdown. Atlas supports the following upgrade paths:

  • MongoDB 3.2 -> MongoDB 3.4
  • MongoDB 3.4 -> MongoDB 3.6
  • MongoDB 3.6 -> MongoDB 4.0

MongoDB Server 3.2 is planned for End of Life on September 2018. Atlas deprecated support for deploying clusters with MongoDB 3.2 in March, 2018.

Atlas will automatically upgrade any clusters running MongoDB 3.2 to MongoDB 3.4 in September 2018. Project Owners can upgrade their MongoDB 3.2 clusters at any time before then.

See I have a cluster running MongoDB 3.2. How does the upcoming End of Life affect me? for guidance on how to manage Atlas clusters currently running MongoDB 3.2.

Atlas running with MongoDB 3.2 must upgrade to MongoDB 3.4 before upgrading to MongoDB 3.6.

See Atlas Major Version Change Procedure for the MongoDB-recommended procedure for a major version change. This procedure includes creating a staging cluster for the purpose of testing and validating application and cluster performance and functionality on the new MongoDB version.

Scale your Replica Set to a Sharded Cluster

To deploy your cluster as a sharded cluster, toggle Shard your cluster (M30 and up) to Yes.

Sharded clusters support horizontal scaling and consist of shards, config servers and mongos routers:

  • Atlas deploys each shard as a three-node replica set, where each node deploys using the configured Cloud Provider & Region, Cluster Tier, and Additional Settings. Atlas deploys one mongod per shard node.

    For cross-region clusters, the number of nodes per shard is equal to the total number of electable and read-only nodes across all configured regions. Atlas distributes the shard nodes across the selected regions.

  • Atlas deploys the config servers as a three-node replica set. The config servers run on M30 instances.

    For cross-region clusters, Atlas distributes the config server replia set nodes to ensure optimal availability. For example, Atlas might deploy the config servers across three distinct availability zones and three distinct regions if supported by the selected cloud service provider and region configuration.

  • Atlas deploys one mongos router for each node in each shard. For cross-region clusters, this allows clients using a MongoDB driver to connect to the geographically “nearest” mongos.

    To calculate the number of mongos routers in a cluster, multiply the number of shards by the number of replica set nodes per shard.

For details on how the number of server instances affect cost, see Number of Servers.

For more information on sharded clusters, see Sharding in the MongoDB manual.

Modify the Number of Shards in your sharded cluster

This field is visible only if the deployment is a sharded cluster.

You can set the number of shards to deploy with the sharded cluster. You cannot have fewer than two shards.

Enable or Disable Backup for the Cluster

Important

Atlas only allows one backup method per project. Once you select a backup method for a cluster in a project, Atlas locks the backup service to the chosen method for all subsequent clusters in that project.

For example, in a project where one or more clusters use continuous backups, you cannot enable cloud provider snapshots for any cluster in that project.

To change the backup method for the project, disable backups for all clusters in the project, then re-enable backups using your preferred backup methodology. Atlas deletes any stored snapshots when you disable backup for a cluster.

Consider creating a separate project for clusters where a different backup method is required.

To enable backups for the Atlas cluster, toggle Turn on Backup (M10 and up) to Yes. If enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your project’s retention policy.

The backup option chosen for the first cluster in a project dictates the backup option for all other subsequent clusters in the project. See Fully Managed Backup Service for more information.

Atlas provides the following backup options:

Backup Option Description
Continuous Backups

Atlas takes incremental snapshots of data in your cluster and allows you to restore from stored snapshots or from a selected point in time within the last 24 hours. You can also query a continuous backup snapshot.

Each project has one backup data center location dictated by the first backup-enabled cluster created in that project. See Snapshot Storage Location for more information.

Cloud Provider Snapshots

Azure and AWS Replica Set Clusters Only

Atlas takes full copy snapshots of data in your cluster and allows you to restore from those snapshots. Atlas stores snapshots in the same cloud provider region as the replica set member targeted for snapshots.

You can disable backups for the cluster by toggling this option to No. Once you disable backup, Atlas immediately deletes any backup snapshots for the cluster. See Fully Managed Backup Service for more information.

Enable or Disable BI Connector for Atlas for the Cluster

To enable the BI Connector for Atlas for this cluster, toggle Enable Business Intelligence Connector (M10 and up) to Yes.

If enabled, select the node type from which the BI Connector for Atlas should read. For high traffic production environments, the secondary node may be preferable to the primary node.

The BI Connector for Atlas is only available for M10+ clusters.

Enable Encryption at Rest

Configure Encryption at Rest for your Atlas Project

You must configure Encryption at Rest for your Atlas project before enabling the feature for your Atlas clusters. Atlas supports using AWS Key Management Service (KMS) for Atlas Encryption at Rest.

When configuring Atlas Encryption at Rest, you must provide:

  • an AWS Identity and Access Management (IAM) access key ID,
  • the secret access key associated with the provided IAM user,
  • the ID of an AWS Customer Master Key (CMK) to which the provided IAM user has access, and
  • the AWS region in which the CMK was created.

For complete documentation on configuring Atlas Encryption at Rest with AWS KMS, see Encryption at Rest.

Atlas Encryption at Rest adds enterprise data encryption to the existing Atlas cluster storage volume encryption. When you enable Encryption at Rest for a cluster, MongoDB uses the CMK to encrypt the MongoDB master keys, which in turn encrypt the database keys. Atlas never stores the CMK or its ID to disk. For more complete documentation on MongoDB Encryption at Rest, see Encryption at Rest.

To enable Atlas Encryption at Rest for this cluster, toggle Encryption At Rest with WiredTiger Encrypted Storage Engine (M10 and up) to Yes.

Atlas Encryption at Rest supports M10 or greater replica set clusters backed by AWS or Azure only. Atlas Encryption at Rest supports encrypting Cloud Provider Snapshots only. You cannot enable Encryption at Rest on a cluster using Continuous Backups.

Atlas clusters using Encryption at Rest incur an increase to their hourly run cost. For more information on Atlas billing for advanced security features, see Advanced Security.

Important

Exercise extreme caution before deleting or disabling a CMK used by Atlas. If Atlas cannot access the CMK used to encrypt a cluster, then that cluster becomes inaccessible. Exercise similar caution when modifying the permissions of the Atlas project’s IAM user.

E. Confirm and Deploy Your Changes

Click Confirm & Deploy deploy your changes.

If you are upgrading from an M0 Free Tier cluster, Atlas prompts you to enter payment information before deploying your changes.

[1]For replica sets, the data-bearing servers are the servers hosting the replica set nodes. For sharded clusters, the data-bearing servers are the servers hosting the shards. For sharded clusters, Atlas also deploys servers for the config servers; these are charged at a rate separate from the instance costs.