Docs Menu
Docs Home
/
MongoDB Manual
/ / /

transitionToDedicatedConfigServer

On this page

  • Definition
  • Syntax
  • Behavior
  • Access Control
  • Example
  • Learn More
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 a config server between being a config shard and a dedicated config server.

A cluster requires a config server, but it can be a config shard instead of a dedicated config server. Using a config shard reduces the number of nodes required and can simplify your deployment.

If your application has demanding availability and resiliency requirements, consider deploying a dedicated config server. A dedicated config server provides isolation, dedicated resources, and consistent performance for critical cluster operations.

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.

Command syntax:

db.adminCommand( {
transitionToDedicatedConfigServer: 1
} )

The transitionToDedicatedConfigServer command moves application data from the config shard to the other shards in the cluster in the same way that the removeShard command moves data.

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.

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" ]
)

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.

Back

transitionFromDedicatedConfigServer