transitionToDedicatedConfigServer
Definition
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.
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.