Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

commitTransitionToDedicatedConfigServer (database command)

commitTransitionToDedicatedConfigServer

Commits the transition from an embedded config server to a dedicated config server.

In order to run this command, you must transition to a dedicated config server with the startTransitionToDedicatedConfigServer command. This command tells the balancer to move chunks from the shard to other shards in the cluster. You must also manually move databases that use the shard as the primary shard and unsharded collections stored on the shard before running the commitTransitionToDedicatedConfigServer command.

The command returns ok: 0 with an error if the transition to the dedicated config server does not complete or if it contains a database or unsharded collection. If the transition occurs and all databases and unsharded collections migrated off of the shard, the command returns ok: 1.

To start transitioning to a dedicated config server see the startTransitionToDedicatedConfigServer command.

To show the status of the transition from an embedded config server to a dedicated config server, see the getTransitionToDedicatedConfigServerStatus command.

To stop the in-progress transition from an embedded config server to a dedicated config server stopTransitionToDedicatedConfigServer command.

New in version 8.3.

This command is available in deployments hosted in the following environments:

  • MongoDB Enterprise: The subscription-based, self-managed version of MongoDB

  • MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB

Note

This command is not supported in MongoDB Atlas. See Modify your Atlas Sharded Cluster to drain the embedded config server.

The command has the following syntax:

db.adminCommand( {
commitTransitionToDedicatedConfigServer: 1
} )

If you have authorization enabled, you must have the clusterManager role or any role that includes the removeShard action.

Each database in a sharded cluster has a primary shard. If the transitioning shard is also the primary of one of the cluster's databases, then you must manually move the databases from its primary shard to a new shard after migrating all data from the shard.

If there is a database that uses the shard you want to use as a primary, the commitTransitionToDedicatedConfigServer command returns an error.

For details, see the movePrimary command and the Remove Shards from a Sharded Cluster for more information.

Unsharded collections are stored on individual shards. If one of these collections is on the shard you want to transition from embedded to dedicated config server, you must first migrate the collection to a different shard.

If there is an unsharded collection stored on the shard you want to transition from embedded to dedicated config server, the commitTransitionToDedicatedConfigServer command returns an error.

To migrate an unsharded collection, see the moveCollection command.

To start draining a shard, use the db.adminCommand() method to run the startTransitionToDedicatedConfigServer command:

db.adminCommand( { startTransitionToDedicatedConfigServer: "1" } )

To check the status of the draining operation, use the getTransitionToDedicatedConfigServerStatus command:

db.adminCommand( { getTransitionToDedicatedConfigServerStatus: "1" } )
{
"state" : "drainingComplete",
"msg" : "draining completed successfully",
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1772142838, 176),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1772142838, 174)
}

If the output shows any databases in the dbsToMove field, use the movePrimary command to move them onto a different shard.

If the output shows any unsharded collections in the collectionsToMove field, use the moveCollection command to move them onto a different shard.

When getTransitionToDedicatedConfigServerStatus shows { state: "completed" }, the balancer has finished moving chunks off the shard. You can now remove the shard:

db.adminCommand( { commitTransitionToDedicatedConfigServer: "1" } )
{
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1772142839, 19),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1772142839, 19)
}

Back

commitShardRemoval

On this page