> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Configure Independent Shard Scaling For Atlas CLI commands that you use to deploy and manage Atlas clusters on the cloud, you can configure how the cluster handles resource scaling by using the `--autoScalingMode` option. You can use this option for the following commands to specify whether the cluster shards scale together or independently: - [atlas setup](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-setup.md#std-label-atlas-setup) - `atlas-deployments-setup``atlas-deployments-delete``atlas-deployments-list``atlas-deployments-pause``atlas-deployments-start` - [atlas clusters create](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-create.md#std-label-atlas-clusters-create)[atlas clusters update](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-update.md#std-label-atlas-clusters-update)[atlas clusters describe](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-describe.md#std-label-atlas-clusters-describe)[atlas clusters list](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-list.md#std-label-atlas-clusters-list)[atlas clusters watch](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-watch.md#std-label-atlas-clusters-watch)[atlas clusters pause](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-pause.md#std-label-atlas-clusters-pause)[atlas clusters start](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-start.md#std-label-atlas-clusters-start)[atlas clusters delete](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-delete.md#std-label-atlas-clusters-delete) The `--autoScalingMode` option takes the following values: ## clusterWideScaling ### Indicates that cluster nodes scale together across all shards. ```javascript atlas setup --clusterName symmetricShardCluster --provider AWS --autoScalingMode clusterWideScaling --projectId 5e2211c17a3e5a48f5497de3 --tier M10 ``` For clusters configured with `clusterWideScaling`, the JSON (Javascript Object Notation) output looks similar to the following: ```json { "clusterType": "SHARDED", "name": "symmetricShardCluster", "diskSizeGB": 0, "replicationSpecs": [ { "id": "internalId", "numShards": 2, "regionConfigs": [ { "electableSpecs": { ... }, "readOnlySpecs": { ... }, ... } ], "zoneName": "string" } ], ... } ``` To learn more about the output, see the [getCluster](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/2024-10-23/#tag/Clusters/operation/getCluster) endpoint. If you omit the `--autoScalingMode` option, the command defaults to `clusterWideScaling` mode. ## independentShardScaling ### Indicates that cluster nodes scale independently. ```javascript atlas setup --clusterName asymmetricShardCluster --provider AWS --autoScalingMode independentShardScaling --projectId 5e2211c17a3e5a48f5497de3 --tier M10 ``` For clusters configured with `independentShardScaling`, the JSON (Javascript Object Notation) output looks similar to the following: ```json { "clusterType": "SHARDED", "name": "asymmetricShardCluster", "replicationSpecs": [ { "id": "externalId", "regionConfigs": [ { "electableSpecs": { "diskSizeGB": 10, ... }, "readOnlySpecs": { "diskSizeGB": 10, ... }, } ], "zoneId": "string",// for GET/UPDATE "zoneName": "string" }, ... ] } ``` The JSON (Javascript Object Notation) output includes the `replicationSpecs` object that describes the properties of a single shard. The `replicationSpecs` elements define the number of shards instead of the `numShards` field. The `diskSizeGB` field is inside each shard's `replication_specs.regionConfig` object. The `zoneId` field that identifies the zone for Global cluster is returned in the output. To learn more about the output, see the [getCluster](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-getgroupcluster) endpoint. ## Disabling independentShardScaling ### Reverting a sharded cluster to cluster-wide scaling To revert a sharded cluster using independent shard scaling back to cluster-wide scaling, perform the following procedure: 1. Retrieve the independent shard scaling schema. Make a request to the Atlas Administration API [Return One Cluster from One Project](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-getgroupcluster) endpoint. The request returns one `replicationSpecs` entry per shard. 2. Select a template schema. From among the `replicationSpecs`, select one to which to match the other shards for symmetric scaling. Note the following properties from the chosen shard's `regionConfigs`: - `instanceSize` for each shard role such as `electableSpecs`, `readOnlySpecs`, or `analyticsSpecs`. - `diskSizeGB`, `ebsVolumeType`, and `diskIOPS`, or equivalent storage fields for the various cluster vendors. To ensure continuity of performance, select your highest-tier shard as the template. 3. Compose a symmetric `replicationSpecs` array. Using your chosen template schema as a basis, compose a `PATCH` request payload in which each shard's `instanceSize` values for `electableSpecs` and `readOnlySpecs` are identical. ```json { "replicationSpecs": [ { "id": "SHARD_ID_0", "regionConfigs": [ { "providerName": "AWS", "regionName": "US_EAST_1", "zoneName": "Zone1", "electableSpecs": { "instanceSize": "M60", "nodeCount": 3, "diskSizeGB": 2048, "ebsVolumeType": "PROVISIONED", "diskIOPS": 4000 }, "readOnlySpecs": { . . . }, "analyticsSpecs": { . . . } } ] }, { "id": "SHARD_ID_1", "regionConfigs": [ . . . ] }, . . . ] } ``` You must preserve the `id` values of existing shards. Match the tier, storage, and disk settings for every shard. 4. Apply the `PATCH`. Make a request to the Atlas Administration API [Update One Cluster in One Project]() endpoint using the payload defined previously. This initiates a rolling resize of all shards in the cluster. Once you resize your shards to restore symmetry, you can revert to using the `2024-10-23` API resource version. This version relies on the symmetric `replicationSpecs.numShards` model.