Deploy a Sharded Cluster¶
On this page
You can configure Online Archive to move infrequently accessed data from your Atlas cluster to a MongoDB-managed read-only Data Lake instead of sharding your collection or upgrading your cluster tier. To learn more about Online Archive, see Archive Data.
Overview¶
To deploy your cluster as a sharded cluster,
toggle Shard your cluster (M30 and up) to Yes.
Sharded clusters support horizontal scaling and consist of shards, config servers and mongos routers:
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
mongodper 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.
Atlas deploys the config servers as a three-node replica set. The config servers run on M30 cluster tiers.
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.
Atlas deploys one
mongosrouter 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
mongosrouters 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.
For details on how the number of server instances affect cost, see Number of Nodes.
For more information on 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.
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.
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.
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.