Docs Menu
Docs Home
/
MongoDB Manual
/
Sharding
/
Administration
/
Config Shard

Convert a Replica Set to a Sharded Cluster with an Embedded Config Server

On this page

  • About this Task
  • Steps
  • Learn More

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 or embedded config server.

Converting your replica set into a sharded cluster with an embedded config server can reduce:

  • The number of nodes required in your deployment.

  • Complexity for maintaining one-shard clusters.

About this Task

You can't directly convert a replica set to a config shard. To convert a replica set to an embedded config server, you must:

Access Control

If access control is enabled, the transitionFromDedicatedConfigServer command requires the transitionFromDedicatedConfigServer authorization action for the cluster.

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

Steps

The following example converts a self-managed replica set to a config shard that contain pre-existing user data from the replica set.

1

Convert your replica set to a sharded cluster with a dedicated config server

This tutorial assumes that you know how to convert your self-managed replica set to a sharded cluster. For full instructions, see Convert a Self-Managed Replica Set to a Sharded Cluster.

2

Connect to mongos

For example, to connect to your mongos instance running on host mongodb6.example.net as an admin user named admin01:

mongosh "mongodb://admin01@mongodb6.example.net:27017"
3

Run the transitionFromDedicatedConfigServer command

To configure your dedicated config server to run as a config shard, run the transitionFromDedicatedConfigServer command from the admin database:

db.adminCommand( {
   transitionFromDedicatedConfigServer: 1
} )
4

Verify that the config server is now a config shard

To confirm that a sharded cluster uses a config shard, run the listShards command against the admin database while connected to a mongos and inspect the output for a document where _id is set to "config". If the listShards output does not contain a document where _id is set to "config", the cluster does not use a config shard.

The following example runs the listShards command and tries to find a document where _id is set to "config".

db.adminCommand({ listShards: 1 })["shards"].find(element => element._id === "config")

In this example, the returned document has _id set to "config" which confirms that this cluster uses a config shard.

{
  _id: "config",
  host: "configRepl/localhost:27018",
  state: 1,
  topologyTime: Timestamp({ t: 1732218671, i: 13 }),
  replSetConfigVersion: Long('-1')
}

Note

If the balancer is running, it automatically migrates data across the shards. Otherwise, use the moveCollection or moveChunk commands to manually distribute your data.

5

Reduce the number of shards in your cluster to one

To reduce the cluster to a single shard after adding the config shard, move all unsharded collections to the config shard using the moveCollection command and remove the first shard in the cluster with the removeShard command. This step reduces your cluster to a single config shard.

For full instructions on removing shards in your cluster, see Remove Shards from a Sharded Cluster.

Learn More

Back

Config Shard

Next

Start with a Config Shard