Navigation

Scale a Cluster

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

  • the instance size, including upgrading from Free Tier M0 to M2 are larger.
  • 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, or 3.4 to 3.6.
  • the number of regions in which to deploy your cluster.

Considerations

Migration, Downtime, and Performance Impact

Some configuration changes, such as changing the instance size, require migration to new servers. 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 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.

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

Free Tier

Upgrading an M0 Free Tier cluster to an M2 or greater paid tier cluster starts billing for the cluster. See Billing for complete documentation on Atlas billing.

Scale a Cluster

Atlas Configuration Options

MongoDB Version The MongoDB version of the cluster. You can only upgrade clusters running MongoDB 3.2 to MongoDB 3.4.
Region Deploy or modify a cross-region cluster.
Instance Size The instance size of the cluster.
Replication Factor

The number of replica set nodes in the cluster. For sharded clusters, the number of replica set nodes in each shard.

Only available for clusters with an Instance Size of M10 or larger.

Do you want a sharded cluster?

If your cluster is a replica set, you can change the deployment to a sharded cluster.

Only available for clusters with an Instance Size of M30 or larger.

Number of shards Configure the number of shards in the sharded cluster. This field only appears if the deployment is a sharded cluster.
Do you want to enable backup? Enable or disable backups for the cluster. Only available for clusters with an Instance Size of M10 or larger.
Confirm and Deploy Confirm and deploy your cluster with the selected changes.

Walkthrough

The following sections provide complete documentation for each of the Atlas cluster scaling configuration options.

A. Display the Upgrade cluster modal

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 Tier clusters, you can also click the Upgrade button for the cluster.

B. Upgrade the MongoDB Version of the cluster

Atlas supports the following upgrade paths:

  • MongoDB 3.2 -> MongoDB 3.4
  • MongoDB 3.4 -> MongoDB 3.6

Atlas running with MongoDB 3.2 must upgrade to MongoDB 3.4 before upgrading to MongoDB 3.6.

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.

C. Deploy your cluster across more than one Region

For clusters with Instance Size of M10 or greater, you can specify additional regions to distribute your cluster across for high availability or local reads.

AWS Only

If this is the first M10+ dedicated paid cluster for the selected region or regions and you plan on creating one or more VPC peering connections, please review the documentation on VPC Peering Connections before continuing.

To deploy a cross-region cluster, click Enable cross-region configuration options. Cross-region clusters deploy with each node using the same configuration options as specified during cluster configuration.

Note

Having a large number of regions or having nodes spread across long distances may lead to long election times or replication lag.

Important

For a given region in an Atlas project with multi-region clusters, the total sum of MongoDB nodes on all other regions in that project cannot exceed 40. This limit applies across all cloud service providers.

For example, if an Atlas project has 20 nodes in Region A and 20 nodes in Region B, you can deploy no more than 20 additional nodes in that project in any given region. This limit applies even if Region A and Region B are backed by different cloud service providers.

For Atlas projects where every cluster is deployed to a single region, you cannot create a multi-region cluster in that project if there are already 40 or more nodes in that single region.

The following options are available when configuring cross-region clusters, and are only available for clusters using an Instance Size of M10 or greater:

Deploy across multiple regions

Toggle this field to Yes to enable distributing your cluster across multiple regions in the specified cloud provider, increasing availability of a cluster during a partial or total region outage. By default Atlas displays a Preferred Region, which replaces the Region dropdown. The Preferred Region is the region Atlas places your primary node on deployment.

Backup Data Center Location

If this cluster is the first backup-enabled cluster in the project, Atlas selects the backup data center location for the project based on the geographical location of the cluster’s Preferred Region. See Backup a Cluster for more information.

Click Add Region to add a new row for region selection and select the region from the dropdown. Specify the desired number of Nodes for the region.

Each node in the region can participate in elections, and can become the primary as long as the majority of nodes in the replica set are available. The total number of electable nodes across all regions, excluding read-only regions, must be 3, 5, or 7.

You can also use this option to increase the replication factor of single-region clusters by modifying the number of Nodes for your Preferred Region only. You do not have to add additional regions to modify the replication factor of your Preferred Region.

To remove a region, click the X next to that region. You cannot remove the Preferred Region.

Atlas provides checks for whether your selected cross-regional configuration provides availability during partial or whole regional outages.

Deploy read-only replicas

Toggle this field to Yes to enable creating regions for deploying read-only nodes for facilitating local secondary reads.

Click Add Read-Only Region to add a new row for region selection and select the region from the dropdown. Specify the desired number of Nodes for the region.

Each node in the region cannot participate in elections, and cannot become the primary. Read-only regions do not provide high availability.

To remove a read-only region, click the X next to that region.

Regions marked as Recommended provide higher availability compared to other regions. For more information, see:

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.

D. Change the Instance Size of the cluster

Free Tier

You cannot downgrade a cluster to an M0 Free Tier cluster.

You can change the instance size, as well as the memory, storage, and IOPS (speed) specifications for the selected instance size.

The memory, storage, and IOPS specification for each data-bearing server [1] for your Atlas cluster.

Atlas provides various instance sizes to support different use cases:

  • For starter environments, M0, M2, and M5 instance sizes. These instances provide access to a subset of Atlas features and functionality. For a complete list of M0, M2, and M5 instance limitations, see Atlas M0 (Free Tier), M2, and M5 Limitations.
  • For low traffic websites and development, 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.

    As of July 11th, 2017, new Atlas clusters are encrypted by default.

  • Auto-Expand Storage: When disk usage reaches 90%, automatically increase storage. For AWS and GCP, increase storage by an amount necessary to achieve 70% utilization. For Azure, scale the cluster to the next available size. This option is available only for M10 and larger clusters.

    Note

    If the size of the cluster oplog is small, Atlas may be unable to automatically expand disk capacity.

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

E. Change the Replication Factor of the cluster

The replication factor of your cluster is the number of replica set nodes in the cluster. Each node keeps a copy of your database, providing high availability and data redundancy. If your deployment is a sharded cluster, each shard is a replica set, and the replication factor determines the number of nodes in each shard replica set.

This option is only available for clusters using an Instance Size of M10 or greater.

To modify this value, under Region select Enable cross-region configuration options. Modify the number of Nodes for your Primary Region. You must select either 3, 5, or 7 nodes.

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

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

F. Convert your replica set to a sharded cluster

Toggle Do you want a sharded cluster? to Yes to deploy your cluster as a Sharded Cluster.

Sharded clusters support horizontal scaling and consists of shards, config servers and mongos routers .

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 nodes specified by the replication factor. The shard servers have the selected instance size. For cross-region clusters, the nodes of each shard replica set are distributed across the selected regions.
  • Atlas deploys the config servers as a three-node replica set. The config servers run on M30 instances. For cross-region clusters, the nodes of the config server replica set are distributed to ensure optimal availability. For example, Atlas might deploy the config servers across three distinct availability zones and three distinct regions, if possible.
  • Atlas deploys six routers (mongos programs) for a sharded cluster. Atlas runs the routers on the shard servers. For cross-region clusters, Atlas spreads the routers across the selected regions.

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.

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

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

G. Change the Number of Shards in your sharded cluster

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. You cannot have fewer than two shards.

H. Enable or Disable Backup for the cluster

Toggle Do you want to enable backup? to Yes to enable backups for the cluster. You cannot enable backups for clusters using an Instance Size smaller than M10.

If enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your project’s retention policy.

You can disable backups by toggling this option to No. Once you disable backup, Atlas immediately deletes any backup snapshots for the cluster. See Back Up a Cluster for more information.

I. Confirm and deploy your changes

Click Confirm & Deploy deploy your changes.

If you are upgrading from an M0 Free Tier cluster, Atlas prompts you to enter payment information before deploying 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 instance costs.