On this page
Starting in 3.4, the use of the deprecated mirrored
instances as config servers (SCCC) is no longer supported. Before you
can upgrade your sharded clusters to 3.4, you must convert your config
servers from SCCC to CSRS.
To convert your config servers from SCCC to CSRS, see Upgrade Config Servers to Replica Set.
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.
mongos instances cache this data and use it to route
read and write operations to the correct shards.
updates the cache when there are metadata changes for the cluster, such
as Chunk Splits or adding a
shard. Shards also read chunk
metadata from the config servers.
MongoDB also uses the config servers to manage distributed locks.
Each sharded cluster must have its own config servers. Do not use the same config servers for different sharded clusters.
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.
Replica Set Config Servers¶
Changed in version 3.4.
Starting in MongoDB 3.2, config servers for sharded clusters can be deployed as a replica set (CSRS) instead of three mirrored config servers (SCCC). 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.
In version 3.4, MongoDB removes support for SCCC config servers. To upgrade your config servers from SCCC to CSRS, see Upgrade Config Servers to Replica Set.
The following restrictions apply to a replica set configuration when used for config servers:
Read and Write Operations on Config Servers¶
admin database and the config database exist on the config servers.
Writes to Config Servers¶
admin database contains the collections related to the
authentication and authorization as well as the other system.*
collections for internal use.
The config database contains the collections that contain the sharded cluster metadata. MongoDB writes data to the config database when the metadata changes, such as after a chunk migration or a chunk split.
Users should avoid writing directly to the config database in the course of normal operation or maintenance.
When writing to the config servers, MongoDB uses a write concern of
Reads from Config Servers¶
MongoDB reads from the
admin database for authentication and
authorization data and other internal uses.
MongoDB reads from the
config database when a
starts or after a change in the metadata, such as after a chunk
migration. Shards also read chunk metadata from 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. If all config databases become unavailable, the cluster can become inoperable.
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
instances until after the config servers are accessible again. If you
mongos instances before the config servers are
mongos cannot 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.