Config Servers

Replica Set Config Servers

The following restrictions apply to a replica set configuration when used for config servers:

• Must have zero arbiters.

• Must have no delayed members.

• Must build indexes (i.e. no member should have members[n].buildIndexes setting set to false).

Read and Write Operations on Config Servers

The admin database and the config database exist on the config servers.

Config Server Availability

If the config server replica set loses its primary and cannot elect a primary, the cluster's metadata becomes read only. You can still read and write data from the shards, but no chunk migration or chunk splits will occur until the replica set can elect a primary.

In a sharded cluster, mongod and mongos instances monitor the replica sets in the sharded cluster (e.g. shard replica sets, config server replica set).

If all config servers become unavailable, the cluster can become inoperable. To ensure that the config servers remain available and intact, backups of config servers are critical. The data on the config server is small compared to the data stored in a cluster, and the config server has a relatively low activity load.

See A Config Server Replica Set Member Become Unavailable for more information.

Sharded Cluster Metadata

Config servers store metadata in the config database.

To access the config database, issue the following command in mongosh:

use config

In general, you should never edit the content of the config database directly. The config database contains the following collections:

• changelog

• chunks

• collections

• databases

• csrs.indexes

• mongos

• settings

• shards

• version

For more information on these collections and their role in sharded clusters, see Config Database. See Read and Write Operations on Config Servers for more information about reads and updates to the metadata.

Sharded Cluster Security

Use Self-Managed Internal/Membership Authentication to enforce intra-cluster security and prevent unauthorized cluster components from accessing the cluster. You must start each mongod in the cluster with the appropriate security settings in order to enforce internal authentication.

Starting in MongoDB 5.3, SCRAM-SHA-1 cannot be used for intra-cluster authentication. Only SCRAM-SHA-256 is supported.

In previous MongoDB versions, SCRAM-SHA-1 and SCRAM-SHA-256 can both be used for intra-cluster authentication, even if SCRAM is not explicitly enabled.

See Deploy Self-Managed Sharded Cluster with Keyfile Authentication for a tutorial on deploying a secured sharded cluster.

Config Shards

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.

You cannot use the same config shard for multiple sharded clusters.

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

use admin
db.system.version.find()

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

db.adminCommand( {
   transitionToDedicatedConfigServer: 1
} )

db.adminCommand( { listDatabases: 1, nameOnly: true } )

db.adminCommand(
   {
     listCollections: 1,
     nameOnly: true,
     filter: { type: { $ne: "view" } }
   }
)

db.adminCommand(
   {
     moveCollection: "<database>.<collection>",
     toShard: "<new shard>",
   }
)

db.adminCommand( {
   transitionToDedicatedConfigServer: 1
} )

db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )