- Sharding >
- Sharding Concepts >
- Sharded Cluster Components >
- Config Servers
Config Servers¶
Config servers are special mongod
instances that store the
metadata for a sharded cluster.
A production sharded cluster has exactly three config servers. All config servers must be available to deploy a sharded cluster or to make any changes to cluster metadata. Config servers do not run as replica sets.
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.
Warning
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.
Tip
Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime.
Read and Write Operations on Config Servers¶
Config servers store the cluster’s metadata in the config
database. The mongos
instances
cache this data and use it to route reads and writes to shards.
MongoDB only writes data to the config server when the metadata changes, such as
- after a chunk migration, or
- after a chunk split.
When writing to the three config servers, a coordinator dispatches the
same write commands to the three config servers and collects the
results. Differing results indicate an inconsistent writes to the
config servers and may require manual intervention. Once the config
servers become inconsistent, the balancer will not perform any chunk
migration and mongos
will not perform auto-splits of chunks.
MongoDB reads data from the config server in the following cases:
- A new
mongos
starts for the first time, or an existingmongos
restarts. - After change in the cluster metadata, such as after a chunk migration.
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. 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. These properties facilitate finding a window 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.