> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Configure Additional Settings You can configure the following additional settings for your Atlas cluster. **Note:** This page applies to both Atlas Infinite and Atlas Core. If a setting applies to only one edition, its section says so. ## Select the MongoDB Version of the Cluster To learn about available MongoDB versions, release cadence options, and how to select a version for your cluster, see [MongoDB Versions in Atlas.](https://www.mongodb.com/docs/atlas/atlas-versions.md#std-label-atlas-versions) ## Configure Backup Options for the Cluster This section describes the backup configuration options for your Atlas cluster. To learn about Atlas backups in more detail, see [Back Up Your Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/overview.md#std-label-backup-cloud-provider) ### Backup Options for Flex clusters Atlas automatically enables backups for Flex clusters and you can't disable them. To learn more, see [Flex Cluster Backups.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/flex-cluster-backup.md#std-label-flex-snapshots) ### M10+ Tier Backup Options To enable Cloud Backup for an `M10+` Atlas cluster, set the Turn on Cloud Backup toggle to On. When enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your project's [backup policy.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cloud-provider-retention-policy) To disable Cloud Backup for an `M10+` Atlas cluster, set the Turn on Cloud Backup toggle to Off. This also disables Continuous Cloud Backup for the cluster. To retain any existing snapshots after Cloud Backup is disabled, set the Keep existing snapshots after backups disabled? toggle to On before you apply your changes to the cluster. This option instructs Atlas to retain the existing snapshots and [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) for the cluster according to your cluster's [backup policy.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/configure-backup-policy.md#std-label-configure-backup-policy) **Note:** If you have a [Backup Compliance Policy](https://www.mongodb.com/docs/atlas/backup/cloud-backup/backup-compliance-policy.md#std-label-backup-compliance-policy) enabled, you can't disable Cloud Backup. If the Backup Compliance Policy has the Require Point in Time Restore to all clusters option set to On, then you also can't disable Continuous Cloud Backup without assistance from MongoDB Support. To disable Continuous Cloud Backup, the security or legal representative specified for the Backup Compliance Policy must [request support](https://www.mongodb.com/docs/atlas/support.md#std-label-request-support) and complete a verification process. Atlas provides the following backup options for `M10+` clusters: | Backup Option | Description | | --- | --- | | [Cloud Backup](https://www.mongodb.com/docs/atlas/backup-restore-cluster.md#std-label-cloud-backup-overview) | Atlas takes incremental snapshots of the data in your cluster and lets you restore the data from those snapshots. Atlas stores snapshots in the same cloud provider region as the replica set member targeted for snapshots. | | [Continuous Cloud Backup](https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup.md#std-label-pit-restore) | After Atlas restores a snapshot, Atlas replays the [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) to restore a cluster from a particular point in time within a window specified in the [backup policy.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/configure-backup-policy.md#std-label-configure-backup-policy) | ### Backup Options for Atlas Infinite clusters Atlas Infinite clusters include a 24 hour continuous Cloud Backup window. To preserve snapshots beyond that window, use the Additional Backup Retention setting, which Atlas enables by default. Additional backup retention incurs additional cost based on your backup policy and workload. In the Atlas Administration API, the `backupEnabled` field controls Additional Backup Retention on an Atlas Infinite cluster. It doesn't control whether Atlas backs up the cluster, because the continuous backup window always applies. After you create the cluster, you can configure your snapshot retention policies. To learn more, see [Manage Backup Policies.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/configure-backup-policy.md#std-label-configure-backup-policy) ## Termination Protection 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. To learn more about terminating your cluster, see [Terminate One Deployment.](https://www.mongodb.com/docs/atlas/pause-terminate-cluster.md#std-label-terminate-cluster) ## Deploy a Sharded Cluster **Tip:** On Atlas Core clusters, you can configure [Online Archive](https://www.mongodb.com/docs/atlas/online-archive/overview.md#std-label-online-archive-overview) to move infrequently accessed data from your Atlas cluster to a MongoDB-managed read-only federated database instance instead of sharding your collection or upgrading your cluster tier. On Atlas Infinite clusters, Online Archive is not supported in public preview. To learn more about Online Archive, see [Manage Online Archives in Atlas.](https://www.mongodb.com/docs/atlas/online-archive/manage-online-archive.md#std-label-manage-online-archive) To deploy your cluster as a [sharded cluster](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster), toggle Shard your cluster (M30 and up) to `Yes`. **Important:** The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see [Public Preview Availability.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing/#public-preview-availability) [Sharded clusters](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) support horizontal scaling and consist of [shards](https://www.mongodb.com/docs/manual/core/sharded-cluster-shards/), [config servers](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server) and [mongos](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-mongos) routers. To learn more, see [About Config Servers Deployment](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-nodes-for-config-server). Config servers must remain readable for sharded read operations to continue to function. If you enable Atlas-managed config servers, Atlas may colocate config server data with application data instead of using a dedicated config server. To learn more, see [Atlas-Managed Config Servers for Sharded Clusters.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-management) ### About Shard Deployment Atlas deploys each [shard](https://www.mongodb.com/docs/manual/core/sharded-cluster-shards/) 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`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.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. ### About Config Servers Deployment For dedicated config servers, Atlas deploys the [config servers](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server) as a three-node replica set. The config servers run on M30 cluster tiers. In multi-region clusters, config servers are distributed across regions. For cross-region clusters, Atlas distributes the config server replica 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. Config servers must remain readable for sharded read operations to continue to function. To learn more, see [Config Server Availability.](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers/#config-server-availability) If you enable Atlas-managed config servers, Atlas may colocate config server data with application data instead of using a dedicated config server. To learn more, see [Atlas-Managed Config Servers for Sharded Clusters.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-management) ### About `mongos` Deployment Atlas deploys one [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.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`.](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) To calculate the number of [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) routers in a cluster, multiply the number of shards by the number of replica set nodes per shard. You cannot convert a sharded cluster deployment to a replica set deployment. To learn more about how the number of server instances affect cost, see [Number of Nodes.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-server-number-costs) To learn more about sharded clusters, see [Sharding](https://www.mongodb.com/docs/manual/sharding/) in the MongoDB manual. ### Configure 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](https://www.mongodb.com/docs/manual/tutorial/view-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`](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md#mongodb-dbcommand-dbcmd.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](https://www.mongodb.com/docs/manual/reference/command/movePrimary/) command. To learn more about the limitations of `moveCollection`, see [Restrictions](https://www.mongodb.com/docs/manual/reference/command/moveCollection/#restrictions). `movePrimary` is an offline operation. - For more information about shard removal, see [Remove Shards from a Sharded Cluster.](https://www.mongodb.com/docs/manual/tutorial/remove-shards-from-cluster/) ### Consideration for Converting a Replica Set to a Sharded Cluster If your cluster tier is `M30` or higher, you can convert your replica set to a sharded cluster. To convert a singular replica set cluster to a multi-shard, sharded cluster, you must first convert to a **single** shard sharded cluster, 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](https://www.mongodb.com/docs/manual/reference/connection-string-formats.md#std-label-connections-dns-seedlist) connection string, your application automatically connects to the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) for your sharded cluster. - If you are using a [standard connection string](https://www.mongodb.com/docs/manual/reference/connection-string-formats.md#std-label-connections-standard-connection-string-format), you must update your connection string to reflect your new cluster topology. Starting in MongoDB 8.3, [DDL operations](https://www.mongodb.com/docs/manual/reference/ddl-operations.md#std-label-ddl-operations) and [`applyOps`](https://www.mongodb.com/docs/manual/reference/command/applyOps.md#mongodb-dbcommand-dbcmd.applyOps) can only be run on a `mongos` for all sharded clusters. These operations may be temporarily unavailable while transitioning from a replica set to a sharded cluster. After converting, you must shard collections and choose an appropriate shard key to distribute data across shards. To learn more, see [Convert a Replica Set to a Sharded Cluster.](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-convert-replset-to-sharded) **Note:** When you [convert a replica set to a sharded cluster](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-convert-replset-to-sharded), the resulting cluster always uses dedicated config servers, even if Atlas-managed config server is enabled. If you need embedded config servers after converting, contact [MongoDB Support.](https://www.mongodb.com/docs/atlas/support.md#std-label-request-support) ## Configure Intelligent Workload Management [Intelligent Workload Management](https://www.mongodb.com/docs/atlas/intelligent-workload-management.md#std-label-intelligent-workload-management) (IWM) is a MongoDB Atlas-managed availability system that keeps Atlas clusters responsive and predictable, even under overload. Overload occurs when your cluster receives more incoming operations than its resources can process. The Intelligent Workload Management section appears on `M10` and larger clusters. It contains two settings, whose availability differs by cluster tier and MongoDB version: - Load Shedding: controls the [Intelligent Workload Management (IWM)](https://www.mongodb.com/docs/atlas/intelligent-workload-management.md#std-label-intelligent-workload-management) protection that rejects incoming database operations at the receiving [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) process when that process is under sustained overload. It takes effect only on `M30+` replica set clusters running MongoDB 9.0 or later. For best results, use [backpressure-aware drivers](https://www.mongodb.com/docs/atlas/overload-errors.md#std-label-backpress-aware-drivers). To learn more, see [Load Shedding.](https://www.mongodb.com/docs/atlas/intelligent-workload-management.md#std-label-iwm-load-shedding) - Search Load Shedding: controls the IWM protection that rejects incoming MongoDB Search and MongoDB Vector Search queries at the receiving `mongot` process when that process is under sustained overload. It is available on clusters running MongoDB 8.0, 8.3, 9.0, or later. By default, Atlas manages the setting and resolves it to Off on MongoDB 8.0 and 8.3 and On on MongoDB 9.0 or later. On Free clusters and Flex clusters, the setting doesn't appear and Atlas always manages it, so you can't override it. To learn more, see [Search](https://www.mongodb.com/docs/search/performance/load-shedding.md#std-label-search-load-shedding) and [Vector Search](https://www.mongodb.com/docs/vector-search/query/load-shedding.md#std-label-avs-load-shedding) Query Load Shedding and Query Rejection. Other IWM protections that do not reject operations remain active on all eligible clusters, regardless of your IWM settings. To learn more about always-on IWM protections, see [Always-On Protections.](https://www.mongodb.com/docs/atlas/intelligent-workload-management.md#std-label-iwm-always-on-protections) The Load Shedding setting accepts the following values: - **Atlas Managed (default):** Atlas controls the effective state of Load Shedding for your cluster. The Effective state: label below the setting shows whether the protection is currently active on your cluster. - **Enabled:** Atlas can reject incoming operations on your cluster during prolonged overload. - **Disabled:** Atlas can't reject incoming operations on your cluster. **Note:** On `M10` and `M20` clusters, the Load Shedding setting appears but has no effect. If you set Load Shedding to Enabled, the Effective state: remains Disabled. ## Enable the MongoDB SQL Interface The MongoDB SQL Interface lets you query the cluster from BI (Business Intelligence) tools such as Tableau and Power BI over the ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity) drivers, with no federated database instance required. You can enable the SQL Interface on a dedicated cluster, `M10` and above, running MongoDB 6.0 or later. 1. Expand the cluster configuration options. In the cluster form for a new or existing cluster, expand Additional Settings. 2. Turn on the SQL Interface. Under Advanced Settings, set Enable Atlas SQL Interface (M10 and up) to on. 3. Review your changes. The Review Changes page lists Atlas SQL Interface with its original and new state, Disabled and Enabled. The toggle appears in the cluster configuration form only for eligible clusters. For the full list of requirements, and to compare the direct connection with a federated database instance, see the [MongoDB SQL Interface overview.](https://www.mongodb.com/docs/sql-interface/) You can also enable and disable the SQL Interface with the Atlas Administration API. To learn more, see the [Server Setup](https://www.mongodb.com/docs/sql-interface/connect-with-sql-composable/) page in the SQL Interface documentation. ### BI Connector for Atlas Availability **Important:** The MongoDB Connector for Business Intelligence for Atlas and on-premises reached end of life (EOL) in September 2026 and is no longer supported. Use the MongoDB SQL Interface to connect to Atlas or Enterprise Advanced deployments. The SQL Interface provides a simpler, direct connection to your clusters without requiring a separate BI Connector instance, and it offers improved performance, a simplified setup, and enhanced features. To learn more, see [MongoDB SQL Interface Overview.](https://www.mongodb.com/docs/sql-interface.md#std-label-connect-with-sql-overview) The cluster configuration form restricts BI Connector for Atlas because it has reached EOL: - If BI Connector for Atlas was not already enabled for the cluster, the Enable Business Intelligence Connector section does not appear, and you cannot enable it. - If BI Connector for Atlas was already enabled, the section appears with a deprecation notice and you can only turn BI Connector for Atlas off. You cannot turn it back on after you disable it. The Review Changes page shows the same notice. We recommend using the MongoDB SQL Interface (Atlas Dedicated) instead. To move an existing BI Connector for Atlas workload across, see the [migration guide.](https://www.mongodb.com/docs/sql-interface/transition-bic-to-atlas-sql/) ## Manage Your Own Encryption Keys **Note:** This feature is available for `M10` clusters or higher. To learn more about which features are available for Free clusters, see [Atlas Free Cluster Limits](https://www.mongodb.com/docs/atlas/reference/free-shared-limitations.md#std-label-atlas-free-tier), and for Flex clusters, see [Atlas Flex Limitations.](https://www.mongodb.com/docs/atlas/reference/flex-limitations.md#std-label-flex-cluster-limitations) Atlas encrypts all cluster storage and snapshot volumes, ensuring the security of all cluster data at rest (Encryption at Rest). Atlas [`Project Owners`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) can configure an added layer of encryption on their data at rest using the MongoDB [Encrypted Storage Engine](https://www.mongodb.com/docs/manual/core/security-encryption-at-rest/) and their Atlas-compatible Encryption at Rest provider. Atlas supports the following Encryption at Rest providers: - [AWS Key Management Services](https://www.mongodb.com/docs/atlas/security-aws-kms.md#std-label-security-aws-kms) - [Azure Key Vault](https://www.mongodb.com/docs/atlas/security-azure-kms.md#std-label-security-azure-kms) - [Google Cloud KMS](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-security-gcp-kms) ### Prerequisites - You must configure the Atlas project for Encryption at Rest using your Key Management before you enable the feature for your Atlas clusters. To learn more, see [Encryption at Rest using Customer Key Management.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption) - To switch from one Encryption at Rest provider on your cluster to another, you must first disable Encryption at Rest for your cluster, then re-enable it with your desired Encryption at Rest provider. To learn more, see [Encryption at Rest using Customer Key Management.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption) ### Procedure To start managing your own encryption keys for this cluster, toggle Encryption using your Key Management (M10 and up) to Yes. Atlas Encryption at Rest using your Key Management is available for `M10+` replica set clusters. Atlas Encryption at Rest supports encrypting [Back Up Your Cluster](https://www.mongodb.com/docs/atlas/backup/cloud-backup/overview.md#std-label-backup-cloud-provider) **only**. Managing your own encryption keys incurs an increase to the hourly run costs of your clusters. To learn more about Atlas billing for advanced security features, see [Advanced Security.](https://www.mongodb.com/docs/atlas/billing/additional-services.md#std-label-advanced-security) **Important:** If Atlas can't access the Atlas project key management provider or the encryption key used to encrypt a cluster, that cluster becomes inaccessible and unrecoverable. Exercise extreme caution before you modify, delete, or disable an encryption key or the key management provider credentials that Atlas uses. ## Configure Additional Options You can configure the following [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) runtime options on `M10+` paid tier clusters. ### Considerations Atlas dynamically modifies the Oplog Size for replica sets and sharded clusters when you change the cluster's storage size. To learn more about how Atlas manages the oplog size, see [Oplog Size Behavior](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-oplog-size-behavior). However, for the Minimum TLS Protocol Version and Allow Server-Side JavaScript settings, it performs a rolling restart of the shard members and the config server replica set. To learn more about how Atlas supports high availability during maintenance operations, see [How does MongoDB Atlas deliver high availability?.](https://www.mongodb.com/docs/atlas/reference/faq/deployment.md#std-label-high-availability) ### View and Edit Additional Settings To view and edit these settings: ### Atlas CLI To update the advanced configuration settings for one cluster using the Atlas CLI, run the following command: ```sh atlas clusters advancedSettings update [options] ``` To learn more about the command syntax and parameters, see the Atlas CLI documentation for [atlas clusters advancedSettings update.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-advancedSettings-update/) On an Atlas Infinite cluster, use `atlas api clusters updateClusterAdvancedConfiguration` instead. The `atlas clusters` commands accept a fixed set of options that doesn't include Atlas Infinite fields. ### Enable Faster Cross-Region Initial Sync for Atlas Core AWS Clusters **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) When you add a new node to an AWS (Amazon Web Services) region, Atlas performs a [Cloud-based initial sync](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-cloud-based-initial-sync) to create a snapshot of a source node and restore it to the new node using AWS (Amazon Web Services)'s native snapshot capabilities. When you enable this setting, Atlas uses [AWS time-based snapshot copies](https://docs.aws.amazon.com/ebs/latest/userguide/time-based-copies.html) to perform Cloud-based initial syncs for destination AWS (Amazon Web Services) nodes that are in a different AWS (Amazon Web Services) region than the source node. Atlas prioritizes restoring from a primary node over secondary nodes to maximize data freshness. Time-based snapshot copy operations can achieve a maximum copy operation throughput of 500 MiB/s. Atlas always maximizes throughput by adjusting the copy operation completion time based on the size of the snapshot. Atlas supports cross-region Cloud-based initial sync for AWS (Amazon Web Services) and Google Cloud clusters only. For Azure (Microsoft Azure) clusters, Atlas performs a [logical initial sync](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync-logical) to add a node to a new region. You can add or replace nodes in your cluster when you [edit the cluster configuration.](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-edit-cluster-atlas) This setting can be enabled only for clusters that contain at least one AWS (Amazon Web Services) node. All clusters are opted out by default. If you remain opted out for an AWS (Amazon Web Services) cluster, Atlas uses AWS (Amazon Web Services)'s native [non-time-based snapshot copy method](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html) to perform cross-region Cloud-based initial syncs. Non-time-based snapshot copies are likely to be much slower than time-based snapshot copies. Enabling faster time-based cross-region initial syncs incurs additional costs from AWS (Amazon Web Services). To learn more about AWS (Amazon Web Services) snapshot pricing, see the [Amazon EBS pricing page.](https://docs.aws.amazon.com/ebs/latest/userguide/time-based-copies.html#time-based-copies-pricing) ### Adaptive Capacity for Azure Clusters **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) Atlas enables Adaptive Capacity by default for clusters on Microsoft Azure that have at least one node. Adaptive capacity takes effect on `M30` and larger clusters. To learn more, see [Adaptive Capacity.](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-adaptive-capacity) Atlas is rolling out adaptive capacity for Microsoft Azure clusters in a phased approach. This feature might not be available to your organization yet. To opt out of adaptive capacity for an individual cluster, or to re-enable it, use the Atlas UI or the Atlas Administration API: ### Atlas UI 1. Expand the cluster configuration options. In the cluster form for a new or existing cluster, expand More Configuration Options under Additional Settings. 2. Toggle Adaptive Capacity. Turn Adaptive Capacity on or off. When you opt out, Atlas keeps the cluster on its original instance type, and a capacity shortage might prevent you from creating or scaling the cluster. ### Set Minimum Oplog Window Modify the retention duration for oplog entries in the [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) of the cluster. By default, Atlas retains entries for 24 hours in Atlas Infinite and Atlas Core before the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) removes them from the oplog. This option corresponds to modifying the [`storage.oplogMinRetentionHours`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-storage.oplogMinRetentionHours) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. To set the minimum oplog window: 1. Verify that storage auto-scaling is enabled and that you didn't opt out of it. Atlas enables auto-scaling by default. 2. Set the minimum oplog window to the desired value. If you don't set this value, Atlas retains oplog entries for 24 hours in Atlas Infinite and Atlas Core before the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) removes them from the oplog. ### Set Oplog Size **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) You can set a fixed oplog size, which helps during live migration or during an intensive data load. You can set the Set Oplog Size configuration setting only if you opt out of the cluster's storage auto-scaling. You can't use the MongoDB command [replSetResizeOplog](https://www.mongodb.com/docs/atlas/unsupported-commands.md#std-label-paid-tier-command-limitations) to resize the oplog on a cluster in Atlas. For clusters that have storage auto-scaling enabled, you can set the Minimum Oplog Window instead. See [Set Minimum Oplog Window](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-min-window). Atlas enables storage auto-scaling by default. The minimum oplog size you can set is 990 megabytes. Atlas returns an error if the oplog size you choose leaves your cluster's disk with less than 25 percent of its capacity free. To check the current oplog size and replication lag time: 1. Connect to your cluster via [`mongosh`.](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh) 2. Authenticate as a user with the [`Atlas admin`](https://www.mongodb.com/docs/manual/reference/built-in-roles.md#mongodb-atlasrole-Atlas-admin) role. 3. Run the [`rs.printReplicationInfo()`](https://www.mongodb.com/docs/manual/reference/method/rs.printReplicationInfo.md#mongodb-method-rs.printReplicationInfo) method. Atlas displays the current oplog size and replication lag time. To set a fixed oplog size: 1. Opt out of [storage auto-scaling.](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-opt-out-autoscaling) 2. Set the [Minimum Oplog Window](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-oplog-min-window) to `0`. 3. Determine the size of the oplog that you need: - Monitor the lag time during the migration process in the Atlas UI. - If the lag time shown in the Atlas UI during migration approaches the replication lag time that you obtained using the [`rs.printReplicationInfo()`](https://www.mongodb.com/docs/manual/reference/method/rs.printReplicationInfo.md#mongodb-method-rs.printReplicationInfo) method, increase the oplog size. 4. Specify your desired Oplog Size in megabytes in the input box. This setting configures the uncompressed size of the oplog, not the size on disk. For sharded cluster deployments, this option modifies the oplog size of each shard in the cluster. This option corresponds to modifying the [`replication.oplogSizeMB`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-replication.oplogSizeMB) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. **Warning:** Reducing the size of the oplog requires removing data from the oplog. Atlas can't access or restore any oplog entries removed as a result of oplog reduction. Consider the ramifications of this data loss before you reduce the oplog. #### Disk Space Considerations *Don't* reduce the size of the oplog to increase the available disk space. Only the oplog collection (`local.oplog.rs`) can reclaim the space that reducing the oplog size saves. Other collections don't benefit from reducing oplog storage. ### Allow Server-Side JavaScript Enable or disable execution of operations that perform server-side execution of JavaScript. - If your cluster runs a MongoDB version less than 5.0, this option corresponds to modifying the [`security.javascriptEnabled`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-security.javascriptEnabled) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. - If your cluster runs MongoDB version 5.0 or greater, this option corresponds to modifying the [`security.javascriptEnabled`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-security.javascriptEnabled) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) in the cluster. - If your cluster runs MongoDB version 8.0, Allow Server-Side JavaScript is disabled by default to improve security and performance. This option corresponds to the [`security.javascriptEnabled`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-security.javascriptEnabled) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) in the cluster. **Note:** In MongoDB version 7.0 and later, [`security.javascriptEnabled`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-security.javascriptEnabled) applies to [mongos](https://www.mongodb.com/docs/manual/reference/program/mongos/)' as well. ### Enable Logging of Redacted and Anonymized Query Data Include redacted and anonymized `$queryStats` output in MongoDB logs. `$queryStats` output does not contain literals or field values. Enabling this setting might impact the performance of your cluster. **Note:** You can enable logging of query data only for Atlas clusters that run MongoDB 7.1 or later. ### Set Minimum TLS Protocol Version Set the minimum TLS version that the cluster accepts for incoming connections. This option corresponds to configuring the [`net.tls.disabledProtocols`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-net.tls.disabledProtocols) configuration file option for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. IMPORTANT: Atlas no longer supports TLS (Transport Layer Security) 1.0 or 1.1. All clusters reject attempts to connect with TLS (Transport Layer Security) 1.0 or 1.1. Set the minimum TLS (Transport Layer Security) version of your clusters to 1.2 or higher. ### Set Custom Cipher Suite Configuration From a list of cipher suites, select which will be used for your cluster's node-to-node and client-to-Atlas communications. The list of available ciphers depends on the cluster's [minimum TLS version.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-set-minimum-tls-protocol-version) **Note:** If you have a custom TLS (Transport Layer Security) 1.2 cipher configuration and you want to upgrade to TLS (Transport Layer Security) 1.3, you must update the configuration to include the TLS (Transport Layer Security) 1.3 ciphers. ### Require Indexes for All Queries **Important:** The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see [Public Preview Availability.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing/#public-preview-availability) Enable or disable the execution of queries that require a collection scan to return results. This option corresponds to modifying the [`notablescan`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.notablescan) parameter via the [`setParameter`](https://www.mongodb.com/docs/manual/reference/command/setParameter.md#mongodb-dbcommand-dbcmd.setParameter) command for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. **Important:** If you're creating MongoDB Search indexes, you might need to disable this parameter. To learn more, see [Considerations for MongoDB Search Indexes.](https://www.mongodb.com/docs/search/indexes/manage-indexes.md#std-label-ref-index-considerations) ### Default Write Concern You can't set a default write concern on an Atlas Infinite cluster. To learn how write concern works on an Atlas Infinite cluster, see [Write Concern on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-architecture.md#std-label-atlas-infinite-write-concern) Set the [default level of acknowledgment requested from MongoDB for write operations](https://www.mongodb.com/docs/manual/reference/write-concern.md#std-label-write-concern) for this cluster. The default write concern for clusters is [majority.](https://www.mongodb.com/docs/manual/reference/write-concern.md#std-label-wc-w) ### Set Transaction Lifetime **Important:** The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see [Public Preview Availability.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing/#public-preview-availability) Set the maximum lifetime of [multi-document transactions](https://www.mongodb.com/docs/manual/core/transactions/). This option corresponds to modifying the [`transactionLifetimeLimitSeconds`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.transactionLifetimeLimitSeconds) parameter via the [`setParameter`](https://www.mongodb.com/docs/manual/reference/command/setParameter.md#mongodb-dbcommand-dbcmd.setParameter) command for each [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) in the cluster. **Important:** You can't set the transaction lifetime to less than one second. The default transaction lifetime for clusters is 60 seconds. ### Enable or Disable Fast Disk Pre-Warming **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) Atlas offers the Fast Disk Pre-Warming setting for clusters hosted AWS (Amazon Web Services) and Azure (Microsoft Azure). Atlas enables fast disk pre-warming by default for these clusters. To disable fast disk pre-warming for an AWS (Amazon Web Services) or Azure (Microsoft Azure) cluster, select Off under the Fast Disk Pre-Warming setting. To enable it again, select Fast Pre-Warming (Default). Due to the design of the underlying cloud provider infrastructure, disk pre-warming occurs whenever Atlas performs a [Cloud-based initial sync](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-cloud-based-initial-sync), such as when Atlas adds a new node to an existing region in your cluster. During a Cloud-based initial sync, Atlas temporarily [hides](https://www.mongodb.com/docs/manual/core/replica-set-hidden-member.md#std-label-replica-set-hidden-members) the new node to prevent it from serving reads until it is ready. Fast disk pre-warming is quicker than background disk warming. When fast disk pre-warming is enabled, the new node consumes most of its provisioned IOPS (Input/Output Operations per Second) while it pre-warms, so Atlas keeps the node hidden until pre-warming completes. When fast disk pre-warming is disabled, Atlas unhides the node as soon as the node is ready and warms the disk in the background, so the node becomes visible sooner. On `M40+` AWS (Amazon Web Services) clusters that don't use [NVMe storage](https://www.mongodb.com/docs/atlas/nvme-storage.md#std-label-nvme-storage), Atlas temporarily provisions a higher-performance AWS (Amazon Web Services) storage volume to support fast disk pre-warming during a Cloud-based initial sync. After disk pre-warming is complete, Atlas modifies the volume back to the node's original storage settings. This modification uses one of the four EBS volume modifications that AWS (Amazon Web Services) allows for each EBS volume in any 24-hour period. To learn more about the EBS volume modification limit, see [Change Storage Capacity or IOPS on AWS.](https://www.mongodb.com/docs/atlas/customize-storage.md#std-label-change-storage-capacity-aws) Provisioning a higher-performance temporary storage volume can temporarily increase the storage costs of your cluster on your monthly Atlas bill. To learn more, see [Storage Capacity.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-storage-capacity) Consider the following recommendations: - If you have workloads that seek consistent query latency, enable this setting. - If you have workloads that seek maximum availability guarantees over consistent query performance, and you require that the newly added or replaced node is immediately active and visible, disable this setting, and [use a custom connection string with tags](https://www.mongodb.com/docs/atlas/reference/replica-set-tags.md#std-label-reduce-secondary-disk-warming-example) for the node that undergoes pre-warming, until the pre-warming process completes. Using this connection string prevents reads on the node while most of its IOPS (Input/Output Operations per Second) are utilized by the pre-warming process. ### Set Default Timeout for Read Operations For clusters running MongoDB version 8.0+, you can specify the default maximum timeout in milliseconds of all read operations for these clusters. This protects your database against unintentional long-running queries. This option corresponds to the cluster parameter [defaultMaxTimeMS.](https://www.mongodb.com/docs/upcoming/reference/cluster-parameters/defaultMaxTimeMS/) ### Configure Replica Set Scaling Mode **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) Modify the [replica set](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-replica-set) scaling mode for your cluster. Atlas uses the scaling mode In Parallel By Workload Type by default. Atlas can also scale a replica set with the In Parallel By Node Type and Sequential modes. The following list describes the available scaling modes: - In Parallel By Workload Type mode applies only to clusters with read-only [operational nodes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-operational-node) and [analytics nodes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-analytics-node). Atlas uses this scaling mode by default, unless you specify another scaling mode. In this mode, Atlas scales your analytics nodes in parallel with your operational nodes. **Note:** If your cluster has only [electable](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-electable-node) nodes, the scaling mode In Parallel By Workload Type doesn't affect cluster behavior. - In Parallel By Node Type mode is for large, dynamic workloads requiring frequent and timely cluster tier scaling. In this mode, Atlas scales your [electable](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-electable-node) nodes in parallel with your [read-only](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-read-only-node) and [analytics](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-analytics-node) nodes. This is the fastest scaling strategy, but it might impact latency of workloads when performing extensive secondary reads. - Sequential mode is for steady-state workloads and applications performing latency-sensitive secondary reads. In this mode, Atlas scales all nodes sequentially. ### Enable Log Redaction Toggle this on to prevent logging of potentially sensitive information in field values. For more information, see [Log Redaction.](https://www.mongodb.com/docs/manual/administration/monitoring/#log-redaction) A rolling restart is required for enabling and disabling log redaction. ### Atlas-Managed Config Servers for Sharded Clusters Enable or disable Atlas management of the [config server](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server) type for a new sharded cluster. An Atlas-managed config server automatically switches the [config server type](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-types) based on [criteria](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-change-criteria) for optimal performance and cost savings. If you don't enable an Atlas-managed config server for a sharded cluster, Atlas always uses a dedicated config server for the cluster. For all 8.0 Atlas sharded clusters, Atlas-managed config servers are On by default. To disable Atlas-managed config servers, set the toggle to Off. If the cluster has fewer than 11 shards and embedded config servers, turning off Atlas-managed config servers immediately transitions the cluster to dedicated config servers. **Note:** Embedded config servers or config shards are not supported on [Global Clusters.](https://www.mongodb.com/docs/atlas/global-clusters.md#std-label-global-clusters) #### Config Server Types For each new sharded cluster with Atlas-managed config servers enabled, Atlas deploys an embedded config server for clusters with fewer than 11 shards and a dedicated config server for clusters with more than 10 shards. Embedded config servers colocate your application data with config data on a config shard. Embedded config server clusters cost less because they use fewer resources. Dedicated config servers use a separate, dedicated config server replica set for config data. Your application data is not colocated with config data for dedicated config servers. Dedicated config server clusters cost more because they use an additional replica set. To learn more about considerations for config server types, see [Config Server Considerations.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-considerations) #### Config Server Change Criteria If you enable Atlas-managed config servers, Atlas determines the initial cluster config server type as follows: - If the cluster shard count is greater than 10, Atlas uses a dedicated config server. - If the cluster shard count is 10 or fewer, Atlas uses an embedded config server. When you add or remove shards with Atlas-managed config servers enabled, Atlas automatically re-selects your sharded cluster's config server type using the same criteria. When you upgrade an existing sharded cluster from MongoDB 7.0 to 8.0, Atlas turns on Atlas-managed config servers but doesn't change the cluster's existing config server type. These criteria apply to shard-count changes only. #### Config Server Considerations All clusters with a version lower than MongoDB 8.0 use a dedicated config server. Atlas will not change your config server type if you use any of the following features: - [Time series data](https://www.mongodb.com/docs/manual/core/timeseries-collections/) - [Queryable encryption](https://www.mongodb.com/docs/manual/core/queryable-encryption/) - [MongoDB Search indexes](https://www.mongodb.com/docs/search/indexes/manage-indexes.md#std-label-fts-manage-indexes) If you have a cluster with more than 10 shards that is unable to transition to a dedicated config server due to the use of these features, contact [MongoDB Support](https://www.mongodb.com/docs/atlas/support.md#std-label-request-support) to change your configuration server type. If you enable Atlas-managed config servers, the following considerations apply: - For clusters running MongoDB 8.0 or later, replica set IDs **don't** reflect the type of data stored on the replica set. - Replica sets that contain the term `shard` in their replica set ID might store application data, config data, or both (for example: `atlas-abc123-shard-0`). - Replica sets that contain the term `config` in their replica set ID might store application data (for example: `atlas-abc123-config-0`). ##### Backup Snapshot Considerations - You can restore snapshots from a cluster with a dedicated config server only to a cluster that also uses a dedicated config server. - You can restore snapshots from a cluster with an embedded config server only to a cluster that also uses an embedded config server.