The collections in the
config database support:
- sharded cluster operations, and
- starting in MongoDB 3.6, causally consistent sessions for standalones, replica sets, and sharded clusters and retryable writes for replica sets and sharded clusters.
The schema of the
config database is internal and may change between releases of MongoDB. The
config database is not a dependable API, and users should not write data to the
config database in the course of normal operation or maintenance.
The config database is mainly for internal use, and during normal operations you should never manually insert or store data in it. However, if you need to verify the write availability of the config server for a sharded cluster, you can insert a document into a test collection (after making sure that no collection of that name already exists):
Modification of the
config database on a functioning system may lead to instability or inconsistent data sets. If you must modify the
config database, use
mongodump to create a full backup of the
If the operation succeeds, the config server is available to process writes.
Future releases of the server may include different collections in the config database, so be careful when selecting a name for your test collection.
MongoDB uses the following collections in the
config database to support sharding:
changelogcollection stores a document for each change to the metadata of a sharded collection.
The following example displays a single record of a chunk split from a
Each document in the
changelogcollection contains the following fields:
A string that holds the address of the client, a
mongosinstance that initiates this change.
A ISODate timestamp that reflects when the change occurred.
Reflects the type of change recorded. Possible values are:
chunkscollection stores a document for each chunk in the cluster. Consider the following example of a document for a chunk named
These documents store the range of values for the shard key that describe the chunk in the
maxfields. Additionally the
shardfield identifies the shard in the cluster that “owns” the chunk.
collectionscollection stores a document for each sharded collection in the cluster. Given a collection named
recordsdatabase, a document in the
collectionscollection would resemble the following:
databasescollection stores a document for each database in the cluster. For each database, the corresponding document displays the name, the database’s primary shard, and the database’s sharding enabled status.
lockpingscollection keeps track of the active components in the sharded cluster. Given a cluster with a
example.com:30000, the document in the
lockpingscollection would resemble:
lockscollection stores the distributed locks. The primary of the config server replica set takes a lock by inserting a document into the
As of version 3.4, the
statefield will always have a value
2to prevent any legacy
mongosinstances from performing the balancing operation. The
whenfield specifies the time when the config server member became the primary.
In version 3.4, when the balancer is active, the balancer takes a lock, as in the following 3.4 example:
Starting in version 3.6, the balancer no longer takes a “lock”. If you have upgraded from 3.4 to 3.6, you may choose to delete any residual
"_id" : "balancer"documents.