transitionToDedicatedConfigServer (database command)

Definition

transitionToDedicatedConfigServer

New in version 8.0.

Starting in MongoDB 8.0, you can:

Configure a config server to store your application data in addition to the usual sharded cluster metadata. A config server that stores application data is called a config shard.
Transition between a config shard and a dedicated config server.

Every sharded cluster requires a config server. A config shard qualifies as a config server. Use a config shard instead of a dedicated config server to reduce the number of required nodes and simplify your deployment.

A dedicated config server requires its own replica set. A config shard combines the config server role with an existing shard replica set, so your cluster needs fewer replica sets and costs less. Using a config shard has no measurable performance impact at low shard counts.

A dedicated config server isolates cluster metadata from application data. Certain features require this isolation. To learn which deployment fits your cluster, see Config Shard Use Cases.

The transitionToDedicatedConfigServer command configures a config shard to run as a dedicated config server. The command causes the balancer to prioritize moving the chunks from the config shard to other shards in the cluster.

Before you run transitionToDedicatedConfigServer, connect to mongos and use the admin database.

The sharded cluster must have featureCompatibilityVersion set to at least 8.0.

Syntax

Command syntax:

db.adminCommand( {
   transitionToDedicatedConfigServer: 1
} )

Behavior

The transitionToDedicatedConfigServer command moves application data from the config shard to the other shards in the same way that removeShard moves data. The balancer moves sharded collection data to other eligible shards in the cluster. You must move unsharded collection data and databases to a shard of your choice in the cluster. For the procedure to remove a config shard, see Remove Shards from a Sharded Cluster.

Internally, transitionToDedicatedConfigServer runs the removeShard command. transitionToDedicatedConfigServer returns the same response as removeShard. The response after a successful data move contains state: "completed". For full response details and examples, see removeShard Example. Review the removeShard documentation before running transitionToDedicatedConfigServer to understand how it may affect your deployment.

If you run transitionToDedicatedConfigServer twice and the shard data is currently moving to other shards, the second run of transitionToDedicatedConfigServer returns the current status of the data move. transitionToDedicatedConfigServer returns the same response as removeShard.

After transitionToDedicatedConfigServer completes the data move, the config server is a dedicated config server and is no longer a config shard.

Access Control

If access control is enabled, the transitionToDedicatedConfigServer command requires the transitionToDedicatedConfigServer authorization action for the cluster:

{
   resource: { cluster : true },
   actions: [ "transitionToDedicatedConfigServer" ]
}

The clusterManager role has transitionToDedicatedConfigServer authorization action and can be assigned to a user.

The following example assigns the clusterManager role to a user named testUser:

db.grantRolesToUser(
   "testUser",
   [ "clusterManager" ]
)

Example

The following example configures a config shard to run as a dedicated config server:

db.adminCommand( {
   transitionToDedicatedConfigServer: 1
} )

For details, see Downgrade Feature Compatibility Version.

Learn More

Back

transitionFromDedicatedConfigServer

unsetSharding