- Sharding >
- Sharded Cluster Components >
- Config Servers
Config Servers¶
On this page
Config servers store the metadata for a sharded cluster. The metadata reflects state and organization for all data and components within the sharded cluster. The metadata includes the list of chunks on every shard and the ranges that define the chunks.
In MongoDB 3.2+, you can deploy config servers as a replica set (CSRS). See Replica Set Config Servers.
The mongos
instances cache this
data and use it to route read and write operations to the correct shards.
mongos
updates the cache when there are metadata changes for the
cluster, such as Chunk Splits or
adding a shard.
The config servers store Authentication configuration information such as Role-Based Access Control or internal authentication settings for the cluster.
A single sharded cluster must have exclusive use of its config servers. If you have multiple sharded clusters, each cluster must have its own CSRS.
Warning
Administrative operations conducted on config servers may have significant impact on sharded cluster performance and availability. Depending on the number of config servers impacted, the cluster may be read-only or offline for a period of time.
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 replica 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 a replica set config server deployment, 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 existingmongos
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.
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.
For 3.2 sharded clusters, if the number of consecutive unsuccessful
attempts to monitor the config server replica set exceeds
replMonitorMaxFailedChecks
parameter value, the monitoring
mongos
or mongod
instance becomes unusable until
you restart the instance. See
A Config Server Replica Set Member Become Unavailable for a workaround.
See A Config Server Replica Set Member Become Unavailable for more information.
Sharded Cluster Metadata¶
Config servers store metadata in the Config Database.
Important
Always back up the config
database before doing any
maintenance on the config server.
To access the config
database, issue the following command from the
mongo
shell:
In general, you should never edit the content of the config
database directly. The config
database contains the following
collections:
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 Internal 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.
See Deploy Sharded Cluster with Keyfile Access Control for a tutorial on deploying a secured sharded cluster.