Modify a Cluster
On this page
- Atlas Configuration Options
- Considerations
- Required Access
- Edit a Cluster
- Modify the Cluster Type
- Modify the Global Cluster Configuration
- Modify the Cloud Provider & Region
- Modify the Cluster Tier
- Modify Additional Settings
- Modify Cluster Details
- Save Your Changes for Later
- Review and Apply Your Changes
- Convert a Replica Set to a Sharded Cluster
You can modify your cluster after initial configuration.
For a summary of available options, see Atlas Configuration Options.
For in-depth configuration steps, see Required Access and the options that follow.
For more information about the impact, cost, and backup policy of your cluster changes, see Considerations.
Atlas Configuration Options
You can change the following options of your Atlas cluster:
Setting | Action | Limitations |
Change the cluster type. | You can only move from a shared cluster to a dedicated cluster or a Serverless instance. | |
Enable Global Writes for your cluster or change existing global cluster configurations. | After you enable Global Writes for a cluster, you can't disable them. | |
Select a different provider to change the cloud provider for your dedicated clusters. If you created an Atlas cluster on AWS or created an Atlas cluster after November 2, 2020, your connection string doesn't change. You don't experience cluster downtime. | If you created an Atlas cluster on Google Cloud or Azure before November 2, 2020, when Atlas added support for multi-cloud clusters, changing to a different provider changes the connection string to your new cluster. Consider scheduling a time to update your applications with the new connection string to connect to the cluster again. To learn more, see Do I have to update my connection string when migrating to a different cloud provider from a dedicated cluster to another?. If you add or move a node to a region without a primary node or without an existing secondary node requires each newly migrated replica set member to perform an initial sync. For clusters on Azure, if you change a region, some storage capabilities might be unavailable in that region. The Atlas UI notifies you that your IOPS will be reduced, which might impact your application performance. To learn more, see regions that support extended storage, and Extend Storage Capacity and IOPS on Azure. | |
Deploy or modify a multi-cloud, multi-region cluster. | For clusters on Azure, if you change to a multi-region cluster, some storage volume capabilities might be unavailable in one of the regions. The Atlas UI notifies you that your IOPS will be reduced, which might impact your application performance. To learn more, see regions that support extended storage, and Extend Storage Capacity and IOPS on Azure. | |
Change the cluster tier. | If your cluster uses NVMe storage, Atlas must perform an initial sync. 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. | |
Change the storage options for the cluster tier. | Clusters using NVMe storage have a fixed size for each cluster tier. | |
Change the cluster's auto-scaling options, including storage auto-scaling. Depending on whether you choose to use storage auto-scaling, Atlas manages the oplog entries based on either the minimum oplog retention window, or the oplog size. To learn more, see Oplog Size Behavior. Atlas enables storage auto-scaling by default. | None | |
Upgrade the major MongoDB version of the cluster. | You can't downgrade the MongoDB version unless you pinned the cluster's FCV before upgrading. | |
Scale up a replica set to a sharded cluster. | You can't reverse this scale up. Atlas allows Sharded Clusters for You can't convert a replica set to a sharded cluster when either of the following Atlas App Services features is enabled for the cluster:
| |
Set the number of shards for a sharded cluster. | Reducing the number of shards takes some time. Atlas
removes shards in descending order based on the number in
in their IMPORTANT: When you remove a shard, Atlas uses the movePrimary command to move any unsharded databases in that shard to a remaining shard:
Atlas allows Sharded Clusters for | |
Enable or disable backups for the cluster. | Atlas enables backups for M2 and M5 clusters automatically. You can't disable backup for clusters on those tiers. | |
Enable or disable the BI Connector for Atlas for this cluster. The MongoDB Connector for Business Intelligence for Atlas (BI Connector) is only available for The BI Connector is a powerful tool which provides users
SQL-based access to their MongoDB databases. As a result, the
BI Connector performs operations which may be CPU and memory
intensive. Given the limited hardware resources on | None | |
Enable or disable using your own encryption keys with this cluster. | None |
Click Apply Changes when complete.
Considerations
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
, andM5
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.
Important
Free Clusters
Upgrading an M0
Free cluster to an M2
or greater paid
tier cluster starts billing for the cluster. See Manage Billing for
complete documentation on Atlas billing.
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.
Required Access
To modify a cluster, you must have Project Cluster Manager
access or higher to the project.
Edit a Cluster
You can modify any of the cluster settings on this page using the Atlas CLI.
To update an Atlas cluster using the Atlas CLI, run the following command:
atlas clusters update [clusterName] [options]
To upgrade the cluster tier, disk size, and/or MongoDB version for an M0
, M2
, or M5
Atlas cluster using the Atlas CLI, run the following command:
atlas clusters upgrade [clusterName] [options]
To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for atlas clusters update and atlas clusters upgrade.
Edit Advanced Settings
To update the advanced configuration settings for one cluster using the Atlas CLI, run the following command:
atlas clusters advancedSettings update <clusterName> [options]
To learn more about the command syntax and parameters, see the Atlas CLI documentation for atlas clusters advancedSettings update.
In Atlas, go to the Clusters page for your project.
If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it's not already displayed, select your desired project from the Projects menu in the navigation bar.
If it's not already displayed, click Clusters in the sidebar.
The Clusters page displays.
Alternatively, if you are already viewing the specific
cluster, click the Configuration button. For
M0
Free clusters, you can also click the
Upgrade button for the cluster.
Modify the Cluster Type
If you have a shared cluster, you can change it to a dedicated cluster or a Serverless instance.
To convert your shared cluster to a Serverless instance, see Convert a Shared Cluster to a Serverless Instance.
To scale up your M0
, M2
, or M5
cluster
to an M10+
cluster, complete the following steps:
In Atlas, go to the Clusters page for your project.
If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it's not already displayed, select your desired project from the Projects menu in the navigation bar.
If it's not already displayed, click Clusters in the sidebar.
The Clusters page displays.
Select your preferred cluster tier.
To learn more, see Modify the Cluster Tier.
Dedicated clusters have more configuration options than shared clusters.
Note
Considerations
You can't change a dedicated cluster to a shared cluster.
You can't change dedicated clusters to Serverless instances
You can't change Serverless instances to clusters.
For a full list of serverless instance limitations, see Serverless Instance Limits
Modify the Global Cluster Configuration
Important
You can't disable Global Writes for a cluster once deployed.
You can enable global writes for your cluster or modify existing global cluster configurations.
Modify the Cloud Provider & Region
Note
Considerations
M0
Tier Clusters- You can modify the cloud provider and region only when
you scale up your
M0
cluster to a larger cluster. M2
or larger Tier Clusters- You can modify the cloud provider and region when you modify your cluster or scale up to a larger cluster.
Changing to a different provider could change the connection string to your new cluster if your old cluster was deployed on Google Cloud or Azure before October 2020. Consider scheduling a time to update your applications with the new connection string to resume connectivity to the cluster. Atlas migrates data to the new cluster.
You can't modify the cloud provider or cloud provider region if you deployed Search Nodes on your Atlas cluster.
To view the current cloud providers and regions for this cluster, select Cloud Provider & Region.
To modify the cloud providers and regions applied to this cluster, follow the procedures on Electable Nodes for High Availability.
To add electable nodes to your cluster during a regional outage, follow the procedure on Reconfigure a Replica Set During a Regional Outage.
To scale up from an Atlas free- or Shared cluster, select from the available cloud providers.
To remove or deploy additional Search Nodes, adjust the Number of Search Nodes setting under Search nodes for workload isolation. You can deploy between 2 and 32 search nodes on your cluster.
If you delete all existing Search Nodes on your cluster, there will be an interruption in processing your search query results while Atlas migrates from
mongot
processes running separately on dedicated Search Nodes tomongot
processes running alongsidemongod
. You can't run queries while indexes are building on the node that hosts both themongot
andmongod
processes, and you will experience query downtime.When you add Search Nodes to a cluster that doesn't have any search nodes, the existing
mongot
processes running alongsidemongod
tail writes to the database that happen after Atlas Search completed the initial sync and themongot
processes on the new dedicated search nodes perform an initial sync on the required collections. This results in dual reads during the migration process.
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.
Modify the Cluster Tier
You can change the cluster tier, as well as the memory, storage,
and IOPS (speed) specifications for the selected cluster. If you
deployed Search Nodes separately for an M10
or higher cluster,
you can also change your search tier.
Note
If you have a Backup Compliance Policy enabled, you can't modify the cluster tier to a tier that doesn't support cloud backup.
Free Cluster and Shared Cluster Considerations
You can't scale down an
M10+
dedicated cluster to anM0
Free cluster orM2/M5
Shared cluster.Changing the cluster tier requires downtime in the following scenarios:
You change from an
M0
Free cluster orM2/M5
Shared cluster to anM10
or larger cluster tier.You change from an
M0
Free cluster to anM2/M5
Shared cluster.You change from an
M2
Shared cluster to anM5
Shared cluster.To prevent data corruption, halt write operations to your cluster for the duration of your scale.
Cluster Tier
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.
Warning
Upgrading from a tenant (free or shared) tier to a dedicated cluster tier deletes the current cluster. To keep your existing snapshots, download those snapshots before upgrading your cluster.
Note
Atlas reboots all nodes in your cluster when you modify the cluster tier.
From the Cluster Tier section, you can also:
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.
Search Tier
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.
Note
Atlas reboots all nodes in your cluster when you modify the search tier.
Modify Additional Settings
You can set the following options:
Upgrade the MongoDB Version of the Cluster
Important
Before you upgrade your cluster, refer to the current recommended best practices for major version upgrades.
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 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.
From the Select a version dropdown, select the new MongoDB version.
Atlas supports the following upgrade paths:
MongoDB 5.0 -> MongoDB 6.0
MongoDB 6.0 -> MongoDB 7.0
MongoDB 7.0 -> Latest Release
Enable or Disable Backup for the Cluster
Backups are automatically enabled for M2
and M5
Shared 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 either of the following Atlas App Services features is enabled for the cluster:
A database trigger with the Document Preimage configuration option enabled, or
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 100 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, Atlas uses the movePrimary command to move any unsharded databases in that shard to a remaining shard.
All sharded collections remain online and available during the shard removal
process. However, read or write operations to unsharded collections during
the movePrimary
operation can result in unexpected behavior, including
migration failure or data loss.
We recommend moving the primary shard for any databases containing unsharded collections before removing the shard.
For more information, see Remove Shards from an Existing 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.
Note
All changes to customer KMS require an initial sync.
Configure Additional Configuration Options
Configure additional options for your cluster from this section.
For details on these options, see Configure Additional Options.
Modify Cluster Details
Add tags, view existing tags, and manage tags. To learn more, see Manage cluster Tags When You Modify an Existing Cluster.
Important
Don't include sensitive information such as Personally Identifiable Information (PII) or Protected Health Information (PHI) in your resource tags. Other MongoDB services, such as Billing, can access resource tags. Resource tags are not intended for private and sensitive data. To learn more, see Sensitive Information.
Save Your Changes for Later
Click Save Draft at the end of your cluster configuration form to save your changes.
Clicking Save Draft the first time prompts Atlas to send an email to the email address associated with your Atlas account with a button to return to your modified cluster configuration form.
You can return to the form to:
Continue making changes by clicking Continue on the pop-up that appears.
Reset your changes made by clicking Reset on the pop-up that appears.
Review and apply your cluster changes by clicking Continue on the pop-up that appears, then Review Changes.
Review and Apply Your Changes
Click Review Changes to review the changes you have made.
The Review Changes page displays a complete side-by-side summary of the modified attributes with any warnings or notes pertaining to the changes. The original attribute settings are listed on the left and the corresponding new settings with changes in pricing are listed on the right.
Atlas displays all warnings and notes related to the change at the top. These include changes that:
Can't be rolled back.
Require an initial sync.
Result in expected delays in execution, increase in workload, or downtime.
Once you have reviewed the changes, click Apply Changes to apply them to your cluster.
If you are upgrading from an M0
Free cluster, Atlas
prompts you to enter payment information before applying 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 cluster costs. |
Convert a Replica Set to a Sharded Cluster
You can convert a replica set to a sharded cluster.
Note
Atlas reboots all nodes in your replica set when you convert it to a sharded cluster.
Prerequisites
To convert your replica set to a sharded cluster:
Your cluster must be an
M10+
cluster.You must have the
Project Cluster Manager
or higher role.
Procedure
In Atlas, go to the Clusters page for your project.
If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it's not already displayed, select your desired project from the Projects menu in the navigation bar.
If it's not already displayed, click Clusters in the sidebar.
The Clusters page displays.
Enable sharding for the cluster.
For the cluster you want to modify, click , then select Edit Configuration.
Expand Additional Settings to modify your cluster configuration.
Enable sharding in the Shard your cluster section by setting the toggle to On.
Note
After you convert a replica set to a sharded cluster, you can't convert it again to a replica set.
Atlas automatically selects 1 Shard from the drop-down menu. You can increase the number of shards in a later step after you restart your application clients.
Click Review Changes to review the changes to billing and click Apply Changes.
It may take some time for Atlas to deploy the changes. Please wait until Atlas has converted your cluster before proceeding to the next step.
Restart all application clients and reconnect to the sharded cluster.
If you don't restart the application clients, your data might be inconsistent after Atlas begins distributing data across shards.
If you are using a DNS Seed List connection string, your application automatically connects to the
mongos
for your sharded cluster after you restart your application.If you are using a standard connection string, you must update your connection string to reflect your new cluster topology.
If you are using private endpoints to connect to your Atlas cluster, your cluster experiences downtime during the conversion.
To learn more, see Connect to a Cluster.
Increase the number of shards.
For the cluster you want to modify, click , then select Edit Configuration.
Expand Additional Settings to modify your cluster configuration.
Select the number of shards from the drop-down menu.
Click Review Changes to review the changes to billing and click Apply Changes.
Sharding supports high throughput and large datasets, and you can increase the number of shards as data requirements grow.
Distribute data across the shards in your cluster.
To shard the collection whose data you want to distribute, see
sh.shardCollection()
for more
information.
Warning
If you shard a collection that already has an Atlas Search index, you might experience a brief period of query downtime when the collection begins to appear on a shard. Also, if you add a shard for an already sharded collection that contains an Atlas Search index, your search queries against that collection will fail until the initial sync process completes on the added shards. To learn more, see initial sync process.
Change any cluster-wide settings.
If you want to make further changes to the sharded cluster, see Modify a Cluster for more information on the cluster-wide settings that you can modify.