Configure Additional Settings

Choosing a Release Cadence

You can set your Atlas clusters to follow either a major release cadence or a rapid release cadence.

Free-tier and shared-tier clusters must follow a major release cadence. You can configure a dedicated-tier cluster to follow a major release cadence by selecting a specific MongoDB version from the dropdown in the Additional Settings section of the cluster form.

Atlas does not automatically upgrade clusters on the major release cadence. You must schedule a manual upgrade to each new major release as it enters general availability.

You can configure a dedicated-tier cluster to follow a rapid release cadence by selecting Latest Release from the dropdown in the Additional Settings section of the cluster form.

You can configure a cluster for rapid releases only if it is running the most recent major release of MongoDB. If your cluster is running a prior major release, manually upgrade to the most recent major release to enable the transition to rapid release.

Atlas uses the most recent MongoDB release for clusters that follow the rapid release cadence. Atlas automatically upgrades these clusters to the new major and rapid release versions via a rolling process to maintain cluster availability as each release becomes available. During the upgrade to the next rapid release version, the cluster in the Atlas UI Clusters page might show the FCV of your cluster instead of the MongoDB version to reflect the features that are currently available on your cluster.

You can revert a cluster that follows the rapid release cadence to the major release cadence by selecting the most recent major release from the Select a Version dropdown menu. However, you can only do this before the first rapid release of the year is available. After a cluster updates from a major release version to a rapid release version, you can't revert the cluster until the next major release.

To learn more about MongoDB versions, see MongoDB Versioning in the MongoDB Manual. For additional details about the rapid release cadence, see Understanding the MongoDB Stable API and Rapid Release Cadence.

M2/M5 Tier Backup Options

Atlas automatically enables backups for M2 and M5 Shared clusters and you can't disable them. To learn more, see Shared Cluster Backups.

M10+ Tier Backup Options

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

Atlas provides the following backup options for M10+ clusters:

About Shard Deployment

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

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

About Config Servers Deployment

For dedicated config servers, Atlas deploys the config servers 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.

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.

A regional outage or regional outage simulation that affects the highest priority regions in a sharded cluster could cause the cluster to become inoperable for read operations. To restore the config servers, do the following:

• Configure a read preference that is suitable for querying secondary nodes for reads.

• Reconfigure the cluster for regaining electable nodes.

About mongos Deployment

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

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

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.

To learn more about sharded clusters, see 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). 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.

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.

Consideration for Upgrading a Replica Set to a Sharded Cluster

If your cluster tier is M30 or higher, you can upgrade your replica set deployment to a sharded cluster deployment.

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.

Read Preferences

The following table describes the available read preferences for BI Connector and their corresponding readPreference and readPreferenceTag connection string options.

Sampling Settings

To generate a relational schema, the BI Connector requires sampling data from MongoDB.

You can't use a .drdl file, or use the mongodrdl command to replace the sampling stage in the Atlas BI Connector.

You can configure the following sampling settings:

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.

• 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.

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 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.

Considerations

Atlas dynamically modifies the Oplog Size for replica sets and sharded clusters. 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?.

View and Edit Additional Settings

To view and edit these settings:

atlas clusters advancedSettings update <clusterName> [options]

Set Minimum Oplog Window

Modify the retention duration for oplog entries in the oplog of the cluster. By default, Atlas retains entries for 24 hours before the mongod removes them from the oplog.

This option corresponds to modifying the storage.oplogMinRetentionHours configuration file option for each 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 before the mongod removes them from the oplog.

Set Oplog Size

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.

For clusters that have storage auto-scaling enabled, you can set the Minimum Oplog Window instead. See Set Minimum Oplog 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.

2. Authenticate as a user with the Atlas admin role.

3. Run the rs.printReplicationInfo() method.

Atlas displays the current oplog size and replication lag time.

To set a fixed oplog size:

1. Opt out of storage autoscaling.

2. Set the Minimum Oplog 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() 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 configuration file option for each 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.

Enforce Index Key Limit

Enable or disable enforcement of the 1024-byte index key limit. Documents can only be updated or inserted if, for all indexed fields on the target collection, the corresponding index entries don't exceed 1024 bytes.

If disabled, mongod writes documents that breach the limit but doesn't index them. This option corresponds to modifying the param.failIndexKeyTooLong parameter via the setParameter command for each mongod in the cluster.

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 configuration file option for each mongod in the cluster.

• If your cluster runs MongoDB version 5.0 or greater, this option corresponds to modifying the security.javascriptEnabled configuration file option for each mongod and 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 configuration file option for each mongod and mongos in the cluster.

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.

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 configuration file option for each mongod in the cluster.

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 will depend on the cluster's minimum TLS version.

Require Indexes for All Queries

Enable or disable the execution of queries that require a collection scan to return results. This option corresponds to modifying the notablescan parameter via the setParameter command for each mongod in the cluster.

Default Write Concern

Set the default level of acknowledgment requested from MongoDB for write operations for this cluster.

Starting with MongoDB 5.0, the default write concern for clusters is majority.

Set Transaction Lifetime

Set the maximum lifetime of multi-document transactions. This option corresponds to modifying the transactionLifetimeLimitSeconds parameter via the setParameter command for each mongod in the cluster.

The default transaction lifetime for clusters is 60 seconds.

Set Chunk Migration Concurrency

For sharded Atlas clusters running MongoDB version 5.0.15 or 6.0.6 and higher versions, you can set the number of threads on the source and receiving shard to improve the performance of chunk migration. You can set the value to half the total number of CPU cores. To learn more, see chunkMigrationConcurrency.

Enable or Disable Fast Disk Pre-Warming

To enable fast disk pre-warming for a cluster, toggle Allow Fast Disk Pre-Warming to Yes.

To disable fast disk pre-warming for a cluster, toggle Allow Fast Disk Pre-Warming to No.

Due to the design of the underlying cloud provider infrastructure, disk pre-warming occurs whenever Atlas needs to provision a new node in a cluster, such as when you add a new node to an existing region. Disk pre-warming temporarily uses a hidden secondary node.

Fast disk pre-warming is quicker than background disk warming. By default, Atlas enables fast disk pre-warming for your deployment. When disk pre-warming is enabled, Atlas hides the node and this prevents this node from running read operations.

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 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 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.

Configure Replica Set Scaling Mode

Modify the replica set scaling mode for your cluster. By default, Atlas scales nodes In Parallel By Workload Type, which means Atlas scales your analytics in parallel to your operational nodes.

Atlas can also scale a replica set with the In Parallel By Node Type and Sequential modes.

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 nodes in parallel with your read-only and analytics 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, which means 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.

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 type for a new sharded cluster. An Atlas-managed config server automatically switches the config server type based on 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 less than four shards and embedded config servers, turning off Atlas-managed config servers immediately transitions the cluster to dedicated config servers.