Modify a Cluster
On this page
You can modify your cluster after initial configuration.
- For a summary of available options, see Atlas Configuration Options.
- For in-depth configuration steps, see Open the Editing Cluster Dialog 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. | |
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 GCP or Azure before October 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. Atlas migrates data to the new cluster. | Adding or moving a node to a region without the primary
requires each newly migrated replica set member to perform an
initial sync | |
Deploy or modify a multi-cloud, multi-region cluster. | None | |
Change the cluster tier. | If your cluster uses NVMe storage,
Atlas must perform an
initial sync. | |
Change the storage options for the cluster tier. When you increase the storage capacity of a cluster, Atlas increases the cluster's oplog size. Atlas scales the oplog to 5% of the cluster capacity, not to exceed 50 GB. NVMe storage requires an oplog which is 10% of the storage capacity. Atlas doesn't change the oplog size if it exceeds 5% of the new storage capacity (10% in the case of NVMe storage). As cluster storage capacity decreases, Atlas doesn't change the oplog size unless it exceeds a certain maximum determined according to MongoDB best practices. | Clusters using NVMe storage have a fixed size for each cluster
tier. | |
Change the cluster's autoscaling options. | None | |
Upgrade the major MongoDB version of the cluster. | You can't downgrade the MongoDB version. | |
Upgrade a replica set to a sharded cluster. | You can't reverse this upgrade. Atlas allows Sharded Clusters for Note You can't convert a replica set to a sharded cluster when either of the following MongoDB Realm features is enabled for the cluster:
| |
Set the number of shards for a sharded cluster. | Removing a shard takes some time. Any subsequent MongoDB configuration changes start after Atlas removes the shard. 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 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. 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.
The following migrations require an initial sync:
- Upgrades from a free clusters or shared clusters (
M0,M2, andM5clusters) to a higher cluster tier. - Changes to NVMe storage volumes. NVMe clusters auto-scale to the next higher tier when 90% of the available storage space is consumed, and the migration requires an initial sync.
- Changes from general to NVMe storage volumes.
- Changes from NVMe to general storage.
- For clusters deployed to Azure, changes to the Cluster Class require an initial sync.
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.
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 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.
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
As of MongoDB version 4.2, Legacy Backups are deprecated in favor of Cloud Backups. When you upgrade to version 4.2 or later, your backup system upgrades to cloud backup if it is currently set to legacy backup. After this upgrade:
- All your existing legacy backup snapshots remain available. They expire over time in accordance with your retention policy.
- Your backup policy resets to the default schedule. If you had a custom backup policy in place with legacy backups, you must re-create it with the procedure outlined in the Cloud Backup documentation.
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 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.
This allows you to upgrade your M0, M2, or M5 cluster
to an M10+ cluster.
At the top of your configuration settings, click the Dedicated tab to begin changing your cluster to a dedicated cluster. Then, select your preferred cluster tier. Dedicated clusters have more configuration options than shared clusters.
- You can't change a dedicated cluster to a shared cluster.
- You can't change clusters to serverless instances or migrate serverless instances to clusters during the serverless instance preview release.
For a full list of serverless instance limitations, see Serverless Instance Limitations
Modify the Global Cluster Configuration
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
M0,M2, orM5Tier Clusters- You can modify the cloud provider when you upgrade to an
M10or larger cluster. M10or larger Tier Clusters- You can select a different provider to change the cloud provider for your dedicated clusters.
Changing to a different provider could change the connection string to your new cluster if your old cluster was deployed on GCP 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.
- 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 upgrade from an Atlas free- or shared cluster, select from the available cloud providers.
Modify the Cluster Tier
You can change the cluster tier, as well as the memory, storage, and IOPS (speed) specifications for the selected cluster.
- You can't downgrade an
M10or larger cluster to anM0free cluster orM2/M5shared cluster. Changing the cluster tier requires downtime in the following scenarios:
- You change from an
M0free cluster orM2/M5shared cluster to anM10or larger cluster tier. - You change from an
M0free cluster to anM2/M5shared cluster. - You change from an
M2shared cluster to anM5shared cluster.
To prevent data corruption, halt write operations to your cluster for the duration of your upgrade.
- You change from an
Select your preferred cluster tier. The selected instance size dictates the memory, storage, and IOPS specification for each data-bearing server [1] in the cluster.
Upgrading from a tenant (free or shared) tier to a dedicated cluster tier:
- deletes the current cluster
- deletes any backup snapshots for that cluster
To keep your existing snapshots, download those snapshots.
From the Cluster Tier section, you can also:
Modify Additional Settings
You can set the following options:
- Upgrade the MongoDB Version of the Cluster
- Enable or Disable Backup for the Cluster
- Scale your Replica Set to a Sharded Cluster
- Modify the Number of Shards
- Enable or Disable BI Connector for Atlas for the Cluster
- Enable Encryption at Rest
- Configure Additional Configuration Options
Upgrade the MongoDB Version of the Cluster
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 cannot downgrade the cluster to an earlier MongoDB version.
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 3.6 -> MongoDB 4.0
- MongoDB 4.0 -> MongoDB 4.2
- MongoDB 4.2 -> MongoDB 4.4
- MongoDB 4.4 -> MongoDB 5.0
- MongoDB 5.0 -> Latest Release
NoteIf you enabled backup for your cluster and want to upgrade to MongoDB 4.2 or later, you must enable Back Up Your Database Deployment if Legacy Backups are currently enabled.
Scale your Replica Set to a Sharded Cluster
You can't convert a replica set to a sharded cluster when either of the following MongoDB Realm features is enabled for the cluster:
- A database trigger with the Document Preimage configuration option enabled, or
- Realm Sync.
To deploy your cluster as a sharded cluster,
toggle Shard your cluster (M30 and up) to Yes.
Once the upgrade completes, you must restart all application clients and reconnect to your sharded cluster. If you don't restart the application clients, your data might be inconsistent once Atlas begins distributing data across shards.
- If you are using a
DNS Seed List
connection string, your application automatically connects to the
mongosfor 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.
You can set the number of shards to deploy with the sharded cluster. Your cluster can have between 1 and 50 shards, inclusive.
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.
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 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.
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.
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.
Prerequisites
To convert your replica set to a sharded cluster:
- Your cluster must be an
M10+cluster. - You must have the
Project Cluster Manageror higher role.
Procedure
Navigate to the Database Deployments page for your project.
- If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
- If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
- If the Database Deployments page is not already displayed, click Databases in the sidebar.
Click the cluster name to view cluster details.
Click Configuration in the Overview tab to view the page where you can edit your cluster settings.
Expand Additional Settings to modify your cluster configuration.
Enable sharding in the Shard your cluster section by setting the toggle to On.
After you convert a replica set to a sharded cluster, you can't convert it again to a replica set.
Select the number of shards from the dropdown.
Sharding supports high throughput and large datasets, and you can increase the number of shards as data requirements grow. By default, Atlas creates two shards.
Click Review Changes to review the changes to billing and when satisfied, 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
mongosfor your sharded cluster. - 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,
perform a rolling restart of your applications to connect to the
mongosfor your sharded cluster without any downtime.
To learn more, see Connect to a Database Deployment.
Distribute data across the shards in your cluster.
To shard the collection whose data you want to distribute, see
sh.shardCollection() for more
information.
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.