Config Servers

Config servers are special mongod instances that store the metadata for a sharded cluster. Config servers use a two-phase commit to ensure immediate consistency and reliability. Config servers do not run as replica sets. All config servers must be available to deploy a sharded cluster or to make any changes to cluster metadata.

A production sharded cluster has exactly three config servers. For testing purposes you may deploy a cluster with a single config server. But to ensure redundancy and safety in production, you should always use three.


If your cluster has a single config server, then the config server is a single point of failure. If the config server is inaccessible, the cluster is not accessible. If you cannot recover the data on a config server, the cluster will be inoperable.

Always use three config servers for production deployments.

Each sharded cluster must have its own config servers. Do not use the same config servers for different sharded clusters.


Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime.

Config Database

Config servers store the metadata in the config database. The mongos instances cache this data and use it to route reads and writes to shards.

Read and Write Operations on Config Servers

MongoDB only writes data to the config server in the following cases:

  • To create splits in existing chunks. For more information, see chunk splitting.
  • To migrate a chunk between shards. For more information, see chunk migration.

MongoDB reads data from the config server data in the following cases:

  • A new mongos starts for the first time, or an existing mongos restarts.
  • After a chunk migration, the mongos instances update themselves with the new cluster metadata.

MongoDB also uses the config server to manage distributed locks.

Config Server Availability

If one or two config servers become unavailable, the cluster’s metadata becomes read only. You can still read and write data from the shards, but no chunk migrations or splits will occur until all three servers are available.

If all three config servers are unavailable, you can still use the cluster if you do not restart the mongos instances until after the config servers are accessible again. If you restart the mongos instances before the config servers are available, the mongos will be unable to route reads and writes.

Clusters become inoperable without the cluster metadata. Always, ensure that the config servers remain available and intact. As such, backups of config servers are critical. The data on the config server is small compared to the data stored in a cluster. This means the config server has a relatively low activity load, and the config server does not need to be always available to support a sharded cluster. As a result, it is easy to back up the config servers.

If the name or address that a sharded cluster uses to connect to a config server changes, you must restart every mongod and mongos instance in the sharded cluster. Avoid downtime by using CNAMEs to identify config servers within the MongoDB deployment.

See Renaming Config Servers and Cluster Availability for more information.