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-deployments-setupatlas-deployments-deleteatlas-deployments-listatlas-deployments-pauseatlas-deployments-start
The --autoScalingMode option takes the following values:
atlas setup --clusterName symmetricShardCluster --provider AWS --autoScalingMode clusterWideScaling --projectId 5e2211c17a3e5a48f5497de3 --tier M10
For clusters configured with clusterWideScaling, the JSON output looks similar to the following:
{ "clusterType": "SHARDED", "name": "symmetricShardCluster", "diskSizeGB": 0, "replicationSpecs": [ { "id": "internalId", "numShards": 2, "regionConfigs": [ { "electableSpecs": { ... },the "readOnlySpecs": { ... }, ... } ], "zoneName": "string" } ], ... }
To learn more about the output, see the getCluster endpoint. If you omit the --autoScalingMode option, the command defaults to clusterWideScaling mode.
atlas setup --clusterName asymmetricShardCluster --provider AWS --autoScalingMode independentShardScaling --projectId 5e2211c17a3e5a48f5497de3 --tier M10
For clusters configured with independentShardScaling, the JSON output looks similar to the following:
{ "clusterType": "SHARDED", "name": "asymmetricShardCluster", "replicationSpecs": [ { "id": "externalId", "regionConfigs": [ { "electableSpecs": { "diskSizeGB": 10, ... }, "readOnlySpecs": { "diskSizeGB": 10, ... }, } ], "zoneId": "string",// for GET/UPDATE "zoneName": "string" }, ... ] }
The JSON 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 endpoint.
To revert a sharded cluster using independent shard scaling back to cluster-wide scaling, perform the following procedure:
Retrieve the independent shard scaling schema.
Make a request to the Atlas Administration API Return One Cluster from One Project endpoint. The request returns one replicationSpecs entry per shard.
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:
instanceSizefor each shard role such aselectableSpecs,readOnlySpecs, oranalyticsSpecs.diskSizeGB,ebsVolumeType, anddiskIOPS, or equivalent storage fields for the various cluster vendors.
To ensure continuity of performance, select your highest-tier shard as the template.
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.
{ "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.
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.