- Sharding >
- Sharding Concepts >
- Sharded Cluster Components >
- Config Servers
Config Servers¶
On this page
Config servers store the metadata for a sharded cluster.
Warning
If the config servers become inaccessible, the cluster is not accessible. If you cannot recover the data on a config server, the cluster will be inoperable.
MongoDB also uses the config servers to manage distributed locks.
Replica Set Config Servers¶
Changed in version 3.2: Starting in MongoDB 3.2, config servers for sharded clusters can be deployed as a replica set. Using a replica set for the config servers improves consistency across the config servers, since MongoDB can take advantage of the standard replica set read and write protocols for the config data. In addition, using a replica set for config servers allows a sharded cluster to have more than 3 config servers since a replica set can have up to 50 members. To deploy config servers as a relica set, the config servers must run the WiredTiger storage engine.
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 buildIndexes setting set to false).
Earlier versions of MongoDB required exactly three mirrored mongod instances to act as the config servers. If you are using mirrored config servers, each server’s system clock must be within 30 seconds of each other server for the distributed lock manager to work properly. With mirrored config servers, minimize clock skew by running the network time protocol (NTP) ntpd on your servers. MongoDB 3.2 deprecates the use of three mirrored mongod instances for config servers.
With replica set config servers, clock skew does not affect distributed lock management.
Each sharded cluster must have its own config servers. Do not use the same config servers for different sharded clusters.
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 servers when the metadata changes, such as
- after a chunk migration, or
- after a chunk split.
When writing to the replica set config servers, MongoDB uses a write concern of "majority".
MongoDB reads data from the config server in the following cases:
- A new mongos starts for the first time, or an existing mongos restarts.
- After change in the cluster metadata, such as after a chunk migration.
When reading from the replica set config servers, MongoDB uses a Read Concern level of "majority".
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. If all config databases become unavailable, the cluster can become inoperable.
The mongos instances cache the metadata from the config servers. As such, if all config server members become 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.
See A Config Server Replica Set Member Become Unavailable for more information.