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": [ . . . ] }, . . . ] }
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.