Config Database

db.testConfigServerWriteAvail.insertOne( { a : 1 } )

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:

config.changelog

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The changelog collection stores a document for each change to the metadata of a sharded collection.

Example

The following example displays a single record of a chunk split from a changelog collection:

{
 "_id" : "<hostname>-<timestamp>-<increment>",
 "server" : "<hostname><:port>",
 "clientAddr" : "127.0.0.1:63381",
 "time" : ISODate("2012-12-11T14:09:21.039Z"),
 "what" : "split",
 "ns" : "<database>.<collection>",
 "details" : {
    "before" : {
       "min" : {
          "<database>" : { $minKey : 1 }
       },
       "max" : {
          "<database>" : { $maxKey : 1 }
       },
       "lastmod" : Timestamp(1000, 0),
       "lastmodEpoch" : ObjectId("000000000000000000000000")
    },
    "left" : {
       "min" : {
          "<database>" : { $minKey : 1 }
       },
       "max" : {
          "<database>" : "<value>"
       },
       "lastmod" : Timestamp(1000, 1),
       "lastmodEpoch" : ObjectId(<...>)
    },
    "right" : {
       "min" : {
          "<database>" : "<value>"
       },
       "max" : {
          "<database>" : { $maxKey : 1 }
       },
       "lastmod" : Timestamp(1000, 2),
       "lastmodEpoch" : ObjectId("<...>")
    },
    "owningShard" : "<value>"
 }
}

Each document in the changelog collection contains the following fields:

config.changelog._id

The value of changelog._id is: <hostname>-<timestamp>-<increment>.

config.changelog.server

The hostname of the server that holds this data.

config.changelog.clientAddr

A string that holds the address of the client, a mongos instance that initiates this change.

config.changelog.time

A ISODate timestamp that reflects when the change occurred.

config.changelog.what

The type of change recorded. Possible values include:

• dropCollection

• dropCollection.start

• dropDatabase

• dropDatabase.start

• moveChunk.start

• moveChunk.commit

• split

• multi-split

config.changelog.ns

Namespace where the change occurred.

config.changelog.details

A document that contains additional details for the change. The structure of the details document depends on the type of change.

config.chunks

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The config.chunks collection stores a document for each chunk in the cluster. The following example shows a document:

{
   _id: ObjectId('65a954c0de11596e08e7c1dc'),
   uuid: UUID('a4479215-a38d-478f-a82b-e5e95d455e55'),
   min: { a: Long('121204345') },
   max: { a: Long('993849349') },
   shard: 'shard01',
   lastmod: Timestamp({ t: 1, i: 0 }),
   history: [
      {
         validAfter: Timestamp({ t: 1705596095, i: 14 }),
         shard: 'shard01'
      }
   ]
}

In the document:

• _id is the chunk identifier.

• min and max are the range of values for the chunk's shard key.

• shard is the name of the shard that stores the chunk in the cluster.

Tip

To find the chunks in a collection, retrieve the collection's uuid identifier from the config.collections collection. Then, use uuid to retrieve the matching document with the same uuid from the config.chunks collection.

config.collections

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

Starting in MongoDB 8.0, config.collections stores metadata for all sharded collections and unsharded collections moved with moveCollection.

In MongoDB versions earlier than 8.0, config.collections only stores metadata for sharded collections.

config.collections only stores metadata about collections, not the documents stored in the collections.

For a collection named pets in the records database, a document in the collections collection would resemble the following:

{
   "_id" : "records.pets",
   "lastmod" : ISODate("2021-07-21T15:48:15.193Z"),
   "timestamp": Timestamp(1626882495, 1),
   "key" : {
         "a" : 1
   },
   "unique" : false,
   "lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc"),
   "uuid" :  UUID("f8669e52-5c1b-4ea2-bbdc-a00189b341da")
}

config.csrs.indexes

New in version 7.0.

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The indexes collection stores a document for each global index available on a shard.

Each document in the collection contains the following fields:

Field	Data Type	Description
name	String	Name of the global index.
keyPattern	Document	Index key specification.
options	Document	Provides information on specified index options, including whether the index is a global index.
lastmod	Timestamp	Timestamp that provides information on when the index was last modified and the index version.
collectionUUID	UUID	UUID of the sharded collection.
indexCollectionUUID	UUID	UUID of the secondary collection that tracks the global index.

config.databases

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The databases collection stores a document for each database in the cluster.

For each database, the corresponding document displays the name, the database's primary shard , and a version.

{ "_id" : "test", "primary" : "shardA", "version" : { "uuid" : UUID("516a5f79-5eb9-4844-8ee9-b8e9de91b760"), "timestamp" : Timestamp(1626894204, 1), "lastMod" : 1 } }
{ "_id" : "hr", "primary" : "shardA", "version" : { "uuid" : UUID("8e39d61d-6259-4c33-a5ed-bcd2ae317b6f"), "timestamp" : Timestamp(1626895015, 1), "lastMod" : 1 } }
{ "_id" : "reporting", "primary" : "shardB", "version" : { "uuid" : UUID("07c63242-51b3-460c-865f-a67b3372d792"), "timestamp" : Timestamp(1626895826, 1), "lastMod" : 1 } }

The method sh.status() returns this information in the Databases section.

config.migrationCoordinators

The migrationCoordinators collection exists on each shard and stores a document for each in-progress chunk migration from this shard to another shard. The chunk migration fails if the document cannot be written to a majority of the members of the shard's replica set.

When a migration is complete, the document describing the migration is deleted from the collection.

config.mongos

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The mongos collection stores a document for each mongos instance affiliated with the cluster. The cluster maintains this collection for reporting purposes.

Each document in the mongos collection contains these fields:

Field	Data Type	Description
_id	String	The hostname and port where the mongos is running. The _id is formatted as <hostname>:<port>.
advisoryHostFQDNs	Array of strings	Array of the mongos's fully qualified domain names (FQDNs).
created	Date	When the mongos was started. New in version 5.2.
mongoVersion	String	Version of MongoDB that the mongos is running.
ping	Date	mongos instances send pings to the config server every 30 seconds. This field indicates the last ping time.
up	NumberLong	Number of seconds the mongos has been up as of the last ping.
waiting	Boolean	This field is always true and is only included for backward compatibility.

The following document shows the status of the mongos running on example.com:27017.

[
   {
     _id: 'example.com:27017',
     advisoryHostFQDNs: [ "example.com" ],
     created: ISODate("2021-11-22T16:32:13.708Z"),
     mongoVersion: "5.2.0",
     ping: ISODate("2021-12-15T22:09:23.161Z"),
     up: Long("2007429"),
     waiting: true
   }
]

config.rangeDeletions

The rangeDeletions collection exists on each shard and stores a document for each chunk range that contains orphaned documents. The chunk migration fails if the document cannot be written to a majority of the members of the shard's replica set.

When the orphaned chunk range is cleaned up, the document describing the range is deleted from the collection.

config.settings

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The settings collection holds the following sharding configuration settings:

• Range size. To change range size, see Modify Range Size in a Sharded Cluster. The specified chunksize value is in megabytes.

• Balancer settings. To change the balancer settings, including balancer status, see Manage Sharded Cluster Balancer.

• Autosplit:

  Starting in MongoDB 6.0.3, automatic chunk splitting is not performed. This is because of balancing policy improvements. Auto-splitting commands still exist, but do not perform an operation.

  In MongoDB versions earlier than 6.1:

  • balancerStart also enables auto-splitting for the sharded cluster.

  • balancerStop also disables auto-splitting for the sharded cluster.

  • To enable or disable the autosplit flag, use the corresponding sh.enableAutoSplit() method or sh.disableAutoSplit() method.

Example documents in the settings collection:

{ "_id" : "chunksize", "value" : 64 }
{ "_id" : "balancer", "mode" : "full", "stopped" : false }

config.shards

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The shards collection represents each shard in the cluster in a separate document, as in the following:

{ "_id" : "shard0000", "host" : "localhost:30000", "state" : 1 }

If the shard is a replica set, the host field displays the name of the replica set, then a slash, then a comma-separated list of the hostnames of each member of the replica set, as in the following example:

{ "_id" : "shard0001", "host" : "shard0001/localhost:27018,localhost:27019,localhost:27020", "state" : 1 }

If the shard has zones assigned, this document has a tags field, that holds an array of the zones to which it is assigned, as in the following example:

{ "_id" : "shard0002", "host" : "localhost:30002", "state" : 1, "tags": [ "NYC" ] }

config.tags

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The tags collection holds documents for each zone range in the cluster. The documents in the tags collection resemble the following:

{
    "_id" : { "ns" : "records.users", "min" : { "zipcode" : "10001" } },
    "ns" : "records.users",
    "min" : { "zipcode" : "10001" },
    "max" : { "zipcode" : "10281" },
    "tag" : "NYC"
}

config.version

Tip

Internal MongoDB Metadata

The config database is internal. Applications and administrators should not modify or depend on its content during normal operation.

The version collection holds the current metadata version number. This collection contains only one document. For example:

{ "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5d8bc01a690d8abbd2014ddd") }

To access the version collection, you must use the db.getCollection() method. For example, to retrieve the collection's document:

db.getCollection("version").find()