Config Servers

Important

Starting in 3.4, the use of the deprecated mirrored mongodinstances as config servers (SCCC) is no longer supported. Before youcan upgrade your sharded clusters to 3.4, you must convert your configservers from SCCC to CSRS.

To convert your config servers from SCCC to CSRS, see the MongoDB 3.4manual Upgrade Config Servers to Replica Set.

Config servers store the metadata for a sharded cluster. The metadatareflects state and organization for all data and components within thesharded cluster. The metadata includes the list of chunks on every shard andthe ranges that define the chunks.

The mongos instances cache this data and use it to routeread and write operations to the correct shards. mongosupdates the cache when there are metadata changes for the cluster, suchas Chunk Splits or adding ashard. Shards also read chunkmetadata from the config servers.

The config servers also store Authentication configurationinformation such as Role-Based AccessControl or internalauthentication settings forthe cluster.

MongoDB also uses the config servers to manage distributed locks.

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

Warning

Administrative operations conducted on config servers may have significantimpact on sharded cluster performance and availability. Depending on thenumber of config servers impacted, the cluster may be read-only oroffline 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 bedeployed as a replica set (CSRS) instead of threemirrored config servers (SCCC). Using a replica set for the configservers improves consistency across the config servers, since MongoDBcan take advantage of the standard replica set read and write protocolsfor the config data. In addition, using a replica set for configservers allows a sharded cluster to have more than 3 config serverssince a replica set can have up to 50 members. To deploy config serversas a replica set, the config servers must run the WiredTigerstorage engine.

In version 3.4, MongoDB removes support for SCCC config servers.

The following restrictions apply to a replica set configuration when usedfor config servers:

  • Must have zero arbiters.
  • Must have no delayed members.
  • Must build indexes (i.e. no member should havebuildIndexes setting set tofalse).

Read and Write Operations on Config Servers

The admin database and the config database exist on the config servers.

Writes to Config Servers

The admin database contains the collections related to theauthentication and authorization as well as the other system.*collections for internal use.

The config database contains thecollections that contain the sharded cluster metadata. MongoDB writesdata to the config database whenthe metadata changes, such as after a chunk migration or a chunk split.

Users should avoid writing directly to the config database in thecourse of normal operation or maintenance.

When writing to the config servers, MongoDB uses a write concern of "majority".

Reads from Config Servers

MongoDB reads from the admin database for authentication andauthorization data and other internal uses.

MongoDB reads from the config database when a mongosstarts or after a change in the metadata, such as after a chunkmigration. Shards also read chunk metadata from the config servers.

When reading from the replica set config servers, MongoDB uses aRead Concern level of "majority".

Config Server Availability

If the config server replica set loses its primary and cannot elect aprimary, the cluster’s metadata becomes read only. You can still readand write data from the shards, but no chunk migration or chunk splitswill occur until the replica set can elect a primary.

In a sharded cluster, mongod and mongos instancesmonitor the replica sets in the sharded cluster (e.g. shard replicasets, config server replica set).

If all config servers become unavailable, the cluster can becomeinoperable. To ensure that the config servers remain available andintact, backups of config servers are critical. The data on the configserver is small compared to the data stored in a cluster, and theconfig server has a relatively low activity load.

For 3.2 sharded clusters, if the number of consecutive unsuccessfulattempts to monitor the config server replica set exceedsreplMonitorMaxFailedChecks parameter value, the monitoringmongos or mongod instance becomes unusable untilyou restart the instance. Seev3.2 troubleshooting guidefor a workaround.

See A Config Server Replica Set Member Become Unavailable for moreinformation.

Sharded Cluster Metadata

Config servers store metadata in the Config Database.

Important

Always back up the config database before doing anymaintenance on the config server.

To access the config database, issue the following command from themongo shell:

  1. use config

In general, you should never edit the content of the configdatabase directly. The config database contains the followingcollections:

For more information on these collections and their role in shardedclusters, see Config Database. SeeRead and Write Operations on Config Servers for more information about readsand updates to the metadata.

Sharded Cluster Security

Use Internal/Membership Authentication to enforce intra-clustersecurity and prevent unauthorized cluster components from accessing thecluster. You must start each mongod in the cluster with theappropriate security settings in order to enforce internal authentication.

See Deploy Sharded Cluster with Keyfile Authentication for atutorial on deploying a secured sharded cluster.