Docs Menu
Docs Home
/
MongoDB Manual
/ /

Config Shard

On this page

  • Use Cases
  • Behavior
  • Get Started
  • 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 mongod node that provides both config server and shard server functionality is called a config shard. A mongod node that runs as a standalone --configsvr without shard server functionality is called a dedicated config server.

A sharded cluster must have a config server, but it can be either a config shard (embedded config server) or a dedicated config server. Using a config shard reduces the number of nodes required and can simplify your deployment. A config shard cluster is also called an embedded config server cluster. You cannot use the same config server for multiple sharded clusters.

You can consider using a config shard if your cluster has three or fewer shards.

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.

You should use a dedicated config server if you satisfy one or more of the following conditions:

  • You plan to use more than three shards.

  • You plan to use Time series collections or Queryable Encryption collections.

  • You plan to use queryable backups (on-prem).

In an embedded config server cluster, a config shard will be used to store cluster metadata and user data. It helps reduce the complexity of a sharded cluster deployment.

You can store sharded and unsharded collection data in your config shard. It has all the properties of a shard as well as acting as the config server.

To confirm that a sharded cluster uses a config shard, run the serverStatus command and check the configServerInShardCache status:

db.adminCommand( {
serverStatus: 1,
} ).shardingStatistics.configServerInShardCache
true

To identify the config server as a config shard, inspect the document in the admin.system.version collection. In this example, shardName is set to 'config':

{
_id: 'shardIdentity',
shardName: 'config',
clusterId: ObjectId("<objectID>"),
configsvrConnectionString: '<config server replica set connection string>',
}

The following example retrieves a shard identity document from admin.system.version in the admin database:

use admin
db.system.version.find()

Output extract:

{
_id: 'shardIdentity',
shardName: 'config',
clusterId: ObjectId("6441bdd6779584849dcac095"),
configsvrConnectionString: 'configRepl/localhost:27007'
}

To configure a dedicated config server to run as a config shard, run the transitionFromDedicatedConfigServer command.

To configure a config shard to run as a dedicated config server, run the transitionToDedicatedConfigServer command.

Back

Drop Hashed Shard Key Index