配置数据库

在本页面

config数据库中的集合支持:

重要 config数据库的 schema 是内部的,可能会在 MongoDB 的版本之间发生变化。 config数据库不是可靠的 API,用户不应在正常操作或维护过程中将数据写入config数据库。

支持 Sharded Cluster 操作的集合

要访问config数据库并查看支持分片操作的集合列表,请将mongo shell 连接到分片 cluster 中的mongos实例,并发出以下命令:

use config

show collections

配置数据库主要供内部使用,在正常操作期间,您绝不应手动插入或存储数据。但是,如果需要验证分片 cluster 的配置服务器的写入可用性,则可以将文档插入到测试集合中(确保该 name 的集合不存在之后):

警告 在正常运行的系统上修改config数据库可能会导致数据集不稳定或不一致。如果必须修改config数据库,请使用mongodump创建config数据库的完整备份。

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

如果操作成功,则配置服务器可用于 process 写入。

服务器的未来版本可能包含配置数据库中的不同集合,因此在为测试集合选择 name 时要小心。

MongoDB 使用config数据库中的以下集合来支持分片:

  • config. changelog

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

更新日志 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("<...>")
    }
 }
}

更新日志集合中的每个文档都包含以下字段:

  • config.changelog. _id

    • changelog._id的 value 是:<hostname>-<timestamp>-<increment>
  • config.changelog. server

    • 保存此数据的服务器的主机名。
  • config.changelog. clientAddr

    • 一个包含 client 地址的 string,一个启动此更改的mongos实例。
  • config.changelog. time

    • 一个ISODate时间戳,反映何时发生更改。
  • config.changelog. what

    • 反映记录的更改类型。可能的值是:
  • dropCollection

  • dropCollection.start

  • dropDatabase

  • dropDatabase.start

  • moveChunk.start

  • moveChunk.commit

  • split

  • multi-split

  • config.changelog. ns

    • 发生更改的命名空间。
  • config.changelog. details

    • 包含有关更改的其他详细信息的文献细节文档的结构取决于更改的类型。
  • config. chunks

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

collection 存储 cluster 中每个块的文档。对于名为records.pets-animal_\"cat\"的块,请考虑以下文档示例:

{
   "_id" : "mydb.foo-a_\"cat\"",
   "lastmod" : Timestamp(1000, 3),
   "lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc"),
   "ns" : "mydb.foo",
   "min" : {
         "animal" : "cat"
   },
   "max" : {
         "animal" : "dog"
   },
   "shard" : "shard0004"
}

这些文档存储描述minmax字段中的块的 shard key 的值范围。此外,shard字段标识 cluster 中“拥有”块的分片。

  • config. collections

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

collections集合存储 cluster 中每个分片集合的文档。给定records数据库中名为pets的集合,collections集合中的文档将类似于以下内容:

{
   "_id" : "records.pets",
   "lastmod" : ISODate("1970-01-16T15:00:58.107Z"),
   "dropped" : false,
   "key" : {
         "a" : 1
   },
   "unique" : false,
   "lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc")
}
  • config. databases

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

数据库 collection 存储 cluster 中每个数据库的文档,并跟踪数据库是否启用了分片。 数据库表示不同文档中的每个数据库。当数据库启用了分片时,primary字段保存主要碎片的 name。

{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "mydb", "partitioned" : true, "primary" : "shard0000" }
  • config. lockpings

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

lockpings集合跟踪分片 cluster 中的 active 组件。如果在example.com:30000上运行的 cluster,则lockpings集合中的文档类似于:

{ "_id" : "example.com:30000:1350047994:16807", "ping" : ISODate("2012-10-12T18:32:54.892Z") }
  • config. locks

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

集合存储分布式锁。配置服务器副本集的主要通过将文档插入locks集合来获取锁定。

{
   "_id" : "test.myShardedCollection",
   "state" : 2,
   "process" : "ConfigServer",
   "ts" : ObjectId("5be0b9ede46e4f441a60d891"),
   "when" : ISODate("2018-11-05T21:52:00.846Z"),
   "who" : "ConfigServer:Balancer",
   "why" : "Migrating chunk(s) in collection test.myShardedCollection"
}

从 version 3.4 开始,state字段将始终具有 value 2,以防止任何 legacy mongos实例执行平衡操作。 when字段指定配置服务器成员成为主服务器时的 time。

在 version 3.4 中,当平衡器为 active 时,平衡器会锁定,如下面的 3.4 example:

{
   "_id" : "balancer",
   "state" : 2,
   "ts" : ObjectId("5be0bc6cb20effa83b15baa8"),
   "who" : "ConfigServer:Balancer",
   "process" : "ConfigServer",
   "when" : ISODate("2018-11-05T21:56:13.096Z"),
   "why" : "CSRS Balancer"
}

从 version 3.6 开始,平衡器不再需要“锁定”。如果您已从 3.4 升级到 3.6,则可以选择删除任何剩余的"_id" : "balancer"文档。

  • config. mongos

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

mongos集合为 cluster 附属的每个mongos实例存储一个文档。 mongos实例每 30 秒向所有 cluster 成员发送 ping,因此 cluster 可以验证mongos是否为 active。 ping字段显示上次 ping 的 time,而up字段报告上次 ping 时mongos的正常运行时间。 cluster 维护此集合以用于报告目的。

以下文档显示example.com:30000 running 在example.com:30000上的状态。

{ "_id" : "example.com:30000", "ping" : ISODate("2012-10-12T17:08:13.538Z"), "up" : 13699, "waiting" : true }
  • config. settings

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

设置集合包含以下分片 configuration 设置:

以下是 example settings集合:

{ "_id" : "chunksize", "value" : 64 }
{ "_id" : "balancer", "stopped" : false }
{ "_id" : "autosplit", "enabled" : true }
  • config. shards

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

碎片集合在单独的文档中表示 cluster 中的每个分片,如下所示:

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

如果分片是副本集,则host字段显示副本集的 name,然后是斜杠,然后是副本集的每个成员的主机名的 comma-separated 列表,如下面的示例所示:

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

如果分片已分配zones,则此文档具有tags字段,该字段包含分配给它的 zones 的 array,如下面的示例所示:

{ "_id" : "shard0002", "host" : "localhost:30002", "tags": [ "NYC" ] }
  • config. tags

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

标签集合保存 cluster 中每个 zone 范围的文档。 标签集合中的文档类似于以下内容:

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

    内部 MONGODB METADATA config数据库是内部的:applications 和管理员不应在正常操作过程中修改或依赖其内容。

集合包含当前元数据 version number。此集合仅包含一个文档:

要访问集合,您必须使用db.getCollection()方法。对于 example,要显示集合的文档:

mongos> db.getCollection("version").find()
{ "_id" : 1, "version" : 3 }

支持会话的集合

version 3.6 中的新内容。

从 MongoDB 3.6 开始,config数据库包含内部集合,以支持独立站,副本_set 和分片集群的因果关系一致以及副本集和分片集群的可重试写入。

警告 不要手动修改或删除这些集合。

要访问mongodmongos实例的这些集合,请将mongo shell 连接到实例。

  • config.system. sessions

    • system.sessions collection stores session 记录可供部署的所有成员使用。

当用户在mongodmongos实例上创建 session 时,session 的 record 最初仅在实例上存在 in-memory。实例会定期将其缓存的会话同步到system.sessions集合;在 time,它们对部署的所有成员都是可见的。

要查看system.sessions集合中的记录,请使用$listSessions

警告 不要手动修改或删除system.sessions集合。

在分片 cluster 中,system.sessions集合是分片的。将分片添加到分片 cluster 时,如果要添加的分片已包含其自己的system.sessions集合,MongoDB 会在 add process 期间删除新分片的system.sessions集合。

  • config. transactions

    • transactions collection stores 记录用于支持可重写的写入用于副本_set 和分片群集。

警告 不要手动修改或删除transactions集合。