Modify a Cluster

Migration, Availability, and Performance Impact

Making changes to a cluster often requires migrating to new servers and storage volumes. The time required for an initial sync and resynchronizing data across storage volumes increases linearly with the amount of data in the cluster.

A File Copy Based Initial Sync will always be used to sync all of the nodes of an NVME cluster whenever an initial sync is required.

The following migrations require an initial sync:

• Scaling up from a Free clusters or Shared clusters (M0, M2, and M5 clusters) to a higher cluster tier.

• Changes from general to NVMe storage volumes and from NVMe to general storage.

• Scaling up or scaling down from one NVMe cluster tier to another, initiated either manually or via auto-scaling. NVMe clusters auto-scale to the next higher tier when 90% of the available storage space is consumed.

• Changes that require a replacement of an NVMe-backed Atlas cluster, such as region changes.

• For clusters deployed to Azure, changes to the Cluster Class.

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, such as a replica set, Atlas migrates one node at a time, starting with the secondary nodes first and then the primary.

Retryable writes should prevent any write errors during the election of a new primary. On average, an election can take five seconds.

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 you set read preferences 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 might, in some situations, create indexes in your cluster as a safeguard.

Billing

As you change 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.

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

Backup

See Cloud Backups for more information on backing up your cluster.

See also:

See also:

View Available Regions

To list available regions that Atlas supports for new deployments using the Atlas CLI, run the following command:

atlas clusters availableRegions list [options]

To learn more about the command syntax and parameters, see the Atlas CLI documentation for atlas clusters availableRegions list.

Free Cluster, Flex Cluster, and Shared Cluster Considerations

• You can't scale down an M10+ dedicated cluster to an M0 Free cluster, a Flex cluster, or M2/M5 Shared cluster (deprecated).

• Changing the cluster tier requires downtime in the following scenarios:

• You change from an M0 Free cluster, Flex cluster, or M2/M5 Shared cluster to an M10 or larger cluster tier.

• You change from an M0 Free cluster to a Flex cluster.

• You change from an M0 Free cluster to an M2/M5 Shared cluster (deprecated).

• You change from an M2 Shared cluster (deprecated) to an M5 Shared cluster (deprecated).

  To prevent data corruption, halt write operations to your cluster for the duration of your scale operation.

Tier for Cluster Nodes

Select your preferred cluster tier. If you deployed Search Nodes separately, in the Base Tier tab, select your preferred cluster tier. The selected instance size dictates the memory, storage, vCPUs, and IOPS specification for each data-bearing server [1] in the cluster.

From the Cluster Tier section, you can also:

• Customize Cluster Storage

• Configure Autoscaling Options

You can select a cluster tier appropriately sized for your analytics workload. To learn more, see Analytics Nodes for Workload Isolation.

If you deploy read-only nodes and want your cluster to scale faster, consider adjusting your Replica Set Scaling Mode.

Tier for Search Nodes

In the Search Tier tab, select your preferred search tier. If the search tier that you select is not available in your region, Atlas automatically switches to the next higher search tier in your region. The selected instance size dictates the memory, storage, IOPS specification, and cost of each search node on your cluster.

Upgrade the MongoDB Version of the Cluster

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

   Atlas always upgrades the cluster to the latest patch release of the specified major version. The upgrade uses a rolling update process to maintain cluster availability.

   You can't downgrade the cluster to an earlier MongoDB version unless you pinned the cluster's FCV before upgrading.

   You can switch from using the Latest Release to using a specific release only if the latest MongoDB version is a major release.

2. From the Select a version dropdown, select the new MongoDB version.

   Atlas supports the following upgrade paths:

   • MongoDB 6.0 -> MongoDB 7.0

   • MongoDB 7.0 -> MongoDB 8.0

Enable or Disable Backup for the Cluster

Backups are automatically enabled for Flex clusters and can't be disabled.

To enable backups for an M10+ Atlas cluster, toggle Turn on Cloud 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.

For detailed descriptions of the available backup options, see Configure Backup Options for the Cluster.

Enable or Disable Termination Protection for the Cluster

To enable Termination Protection for a cluster, toggle Termination Protection to Yes.

If enabled, Atlas prevents users from deleting the cluster. To delete a cluster that has termination protection enabled, you must first disable termination protection. By default, Atlas disables termination protection for all clusters.

Scale your Replica Set to a Sharded Cluster

You can't convert a replica set to a sharded cluster when a database trigger is running with the Document Preimage configuration option enabled.

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

To scale up a replica set to a multi-sharded cluster, you must scale up to a single shard cluster first, restart your application and reconnect to the cluster, and then add additional shards.

If you don't restart the application clients, your data might be inconsistent once Atlas begins distributing data across shards.

If you don't reconnect the application clients, your application may suffer from data outages.

• If you are using a DNS Seed List connection string, your application automatically connects to the mongos for your sharded cluster.

• If you are using a standard connection string, you must update your connection string to reflect your new cluster topology.

Modify the Number of Shards

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

Your cluster can have between 1 and 70 shards, inclusive.

To scale up a replica set to a multi-sharded cluster, you must scale up to a single shard cluster first, restart your application and reconnect to the cluster, and then add additional shards.

If you don't reconnect the application clients, your application may suffer from data outages.

After you scale up a replica set cluster to a single-shard cluster, you can set the number of shards to deploy with the sharded cluster.

If you are reducing the number of shards in your sharded cluster, Atlas removes shards in descending order based on the number in the "_id" field (see Sharded Cluster Configuration). For example, consider a sharded cluster with the following three shards:

• "shard0"

• "shard1"

• "shard2"

If you set the number of shards to two, Atlas removes "shard2" from the cluster.

IMPORTANT: When you remove a shard in 8.0, Atlas uses the moveCollection command to move any unsharded collections in that shard to a remaining shard. All unsharded collections remain online during this process.

• All sharded collections remain online and available during the shard removal process. You must turn on the balancer to drain the sharded collections from the removed shard.

• Atlas moves any unsharded collections that can't be drained by moveCollection command by using the movePrimary command. To learn more about the limitations of moveCollection, see Restrictions. movePrimary is an offline operation.

• For more information about shard removal, see Remove Shards from a Sharded Cluster.

Don't create a sharded cluster with a single shard for production environments. Single-shard sharded clusters don't provide the same benefits as multi-shard configurations. After you create a single-shard cluster, restart your application, reconnect to the cluster, and then add more shards to your cluster.

Enable or Disable BI Connector for Atlas for the Cluster

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

Enable Encryption at Rest

To enable Atlas Encryption at Rest for this cluster using your KMS, toggle Manage your own encryption keys (M10 and up) to Yes. To learn more, see Manage Your Own Encryption Keys.

Configure Additional Configuration Options

Configure additional options for your cluster from this section.

For details on these options, see Configure Additional Options.

Prerequisites

To convert your replica set to a sharded cluster:

• Your cluster must be an M30+ cluster.

• You must have the Project Cluster Manager or higher role.

Procedure