Navigation

Scale a Cluster

Note

This feature is not available for Free Tier clusters. For more information, see Atlas M0 (Free Tier) Limitations.

For an existing Atlas cluster in your group, you can modify:

  • the instance size.
  • the replication factor.
  • the cluster topology from a replica set to a sharded cluster.
  • the number of shards for a sharded cluster.
  • the enabling or disabling of backup.
  • the MongoDB version of a cluster running 3.2 to 3.4.

Considerations

Some configuration changes require migration to new servers; e.g. changing the instance size. Depending on the amount of data to migrate, migrations can take a significant amount of time.

To maximize availability:

  • For a replica set, Atlas migrates one member at a time, starting with the secondary members 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 member at a time, starting with the secondary members first and then the primary.

Downtime occurs during the migration of the primary when the current primary becomes unavailable and lasts until the election of a new primary, generally under a minute.

Migration can affect performance if your primary is already reaching operational capacity: each newly migrated replica set member 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.

Scale an Existing Cluster

1

Go to the Clusters view.

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.

Atlas displays the configuration screen for the cluster.

2

Modify the cluster configuration.

For an existing cluster, you can modify the fields listed in the table below. As you make changes, Atlas displays the updated costs.

Note

Atlas deploys mongod process to its own instance. For sharded clusters, the six routers (the mongos processes) run on six of the shard servers; i.e. each of the six mongos processes shares an instance with one mongod process.

Option Description
MongoDB Version

You can upgrade a cluster running MongoDB 3.2 to MongoDB 3.4.

Atlas always upgrades the cluster to the latest stable release of the specified version.

Important

You cannot downgrade an existing cluster from MongoDB 3.4 to MongoDB 3.2.

Instance Size

You can change the memory, storage, and IOPS (speed) specification.

Atlas provides various instance sizes to support different use cases:

  • For development environments and low traffic websites, M0, M10 and M20 instance sizes.
  • For production environments that support high traffic applications or large datasets, M30 or larger instances sizes.

For a sharded cluster, the selected instance size must be M30 or larger.

Each instance size comes with a default set of resources. Depending on the selected cloud service provider and instance size, Atlas can provide the following configuration options:

  • Custom Storage Capacity: The size of the server root volume. Changes to storage capacity affects cost.
  • Custom Storage Speed: The input/output operations per second (IOPS) the system can perform. Changes to storage speed affects cost.
  • Use encrypted storage volumes: Encrypts root volume for data at rest inside the volume and all data moving between the volume and the instance.

For more information on the default resources and available configuration options for each cloud service provider, see:

Replication Factor

You can change the number of members in your cluster’s replica set.

Atlas deploys replica set members across the cluster’s region. For more information, see Amazon Availability Zones for AWS, GCP Zones for GCP, or Azure Fault Domains for Azure.

The number of availability zones, zones, or fault domains in a region has no affect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes.

Each member of the replica set runs on a separate instance. For details on how the number of server instances affects cost, see Number of Servers.

If your deployment is a sharded cluster, each shard is a replica set, and the replica factor determines the number of members in each shard replica set.

For more information on replica sets, see Replication in the MongoDB manual.

Do you want a sharded cluster?

If your cluster is a replica set, you can change the deployment to a sharded cluster. Sharded clusters support horizontal scaling.

For a sharded cluster, the selected instance size must be M30 or larger.

  • Atlas deploys each shard as a replica set, consisting of the number of members specified by the replication factor. The shard servers have the selected instance size.
  • Atlas deploys the config servers as a three-member replica set. The config servers run on M30 instances.
  • Atlas deploys six routers (mongos programs) for a sharded cluster. Atlas runs the routers on the shard servers.

For details on how the number of server instances affects cost, see Number of Servers.

For more information on sharded clusters, see Sharding in the MongoDB manual.

Important

Changing to a sharded cluster requires a new connection string for accessing MongoDB. For the new connection string, see Connect to a Cluster after the changes are deployed. You must update your applications to use the new string.

Number of Shards This field appears only if the value for Do you want a sharded cluster? is Yes. You can increase or decrease the number of shards. You cannot have fewer than two shards.
Do you want to enable backup? If enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your group’s retention policy. You can restore a backup to the same cluster or any cluster in your group that has the same topology.
3

Click Confirm & Deploy.