Config Database

config データベースのコレクションは以下をサポートします。

シャーディングされたクラスター操作
スタンドアロン、レプリカセット、シャーディングされたクラスターの場合は不特定にコンシステントセッションと、レプリカセットとシャーディングされたクラスターの場合は再試行可能な書き込み。

注意

シャーディングされたクラスターは、mongos に接続するか mongod に接続するかに応じて、config データベースに異なるコレクションを表示する場合があります。

mongosでは、config データベースにcollections やchunks などのコンフィギュレーションサーバー上にあるコレクションが表示されます。
mongodでは、config データベースに、migrationCoordinators やrangeDeletions など、指定されたシャードに固有のコレクションが表示されます。

コンフィギュレーションサーバーとシャードが同じノードでホストされている場合、mongos は、config データベース内の一部のシャードローカルコレクションにアクセスできる可能性があります。

制限事項

MongoDB5.0 以降では、次の読み取り保証（readconfig.transactions concern）とオプションのあるコレクションでは非トランザクションは読み取れません。

"snapshot"
"majority" と afterClusterTime オプションが設定されている
因果整合性のあるセッション内でMongoDBドライバーとを使用する場合"majority"

重要

config データベースのスキーマは内部的なものであり、MongoDB のリリース間で変更される可能性があります。config データベースは信頼できる API ではないため、ユーザーは通常の操作またはメンテナンス中に config データベースにデータを書き込まないでください。

注意

マルチドキュメントトランザクション内では、config データベース内のコレクションに対して読み取り/書き込み操作を実行することはできません。

MongoDB 8.0 以降では、一部の config コレクションを読み取るには mongos に接続する必要があります。これらのコレクションの一覧については、単一シャードコレクションの読み取りを参照してください。

シャーディングされたクラスター操作をサポートするコレクション

configデータベースにアクセスし、シャーディング操作をサポートするコレクションのリストを表示するには、mongosh mongosをシャーディングされたクラスター内のインスタンスに接続し、次のコマンドを実行します。

use config
show collections

注意

アクセス権制御を使用して実行中の場合は、データベースに対して listCollections アクションを許可する特権があることを確認してください。

コンフィギュレーションデータベースは主に内部使用を目的として、通常の操作中はデータを手動で挿入したり保存したりしないでください。ただし、シャーディングされたクラスターのコンフィギュレーションサーバーの書き込み可否を確認する必要がある場合は、テストコレクションにドキュメントを挿入できます（その名前のコレクションがまだ存在しないことを確認した後に）。

警告

機能しているシステム上で config データベースを変更すると、不安定性が生じたり、データセットの一貫性が失われたりする可能性があります。config データベースを変更する必要がある場合は、mongodump を使用して config データベースの完全なバックアップを作成してください。

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

操作が成功すると、コンフィギュレーションサーバーは書き込みを処理できるようになります。

サーバーの今後のリリースでは、コンフィギュレーションデータベースにさまざまなコレクションが含まれる可能性があるため、テストコレクションの名前を選択するときは注意してください。

MongoDB は、シャーディングをサポートするために config データベース内の次のコレクションを使用します。

config.changelog

Tip

内部 MongoDB メタデータ

コンフィギュレーションデータベースは内部的なものであり、アプリケーションおよび管理者は、通常の操作中にその内容を変更したり、利用したりしないようにしてください。

changelog コレクションには、シャーディングされたコレクションのメタデータに対する変更ごとにドキュメントが保存されます。

例

次の例では、changelog コレクションから分裂チャンクの 1 つのレコードを表示します。

{
 "_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>"
 }
}

changelogコレクション内の各ドキュメントには次のフィールドが含まれています。

config.changelog._id: changelog._id の値は <hostname>-<timestamp>-<increment> です。

config.changelog.server: このデータを保持するサーバーのホスト名。

config.changelog.clientAddr: この変更を開始する 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: 変更に関する追加の詳細が記載されたドキュメント。details ドキュメントの構造は変更の種類によって異なります。

config.chunks

Tip

内部 MongoDB メタデータ

config.chunksコレクションには、クラスター内の各チャンクのドキュメントが保存されます。次の例は、ドキュメントを示しています。

{
   _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'
      }
   ]
}

ドキュメント内:

_id は、チャンク識別子です。
min と max はチャンクのシャードキーの値の範囲です。
shard は、クラスターにチャンクを保存するシャードの名前です。

Tip

コレクション内のチャンクを見つけるには、コレクションからコレクションのuuid config.collections識別子を取得します。次に、uuid uuidを使用して、config.chunks コレクションから同じに一致するドキュメントを取得します。

config.collections

Tip

内部 MongoDB メタデータ

MongoDB 8.0 以降、config.collections は、moveCollection によって移動されたすべてのシャーディングされたコレクションとシャーディングされていないコレクションのメタデータを保存します。

8.0 より前のバージョンの MongoDB では、config.collections はシャーディングされたコレクションのメタデータのみを保存します。

config.collections は、コレクションに関するメタデータのみを保存し、コレクションに保存されているドキュメントは保存しません。

petsrecordsデータベース内のという名前のコレクションの場合、collections コレクション内のドキュメントは次のようになります。

{
   "_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.databases

Tip

内部 MongoDB メタデータ

databasesコレクションには、クラスター内の各データベースのドキュメントが保存されます。

各データベースに対応するドキュメントには、名前、データベースのプライマリシャード、およびバージョンが表示されます。

{ "_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 } }

sh.status() メソッドは、データベースセクションでこの情報を返します。

config.migrationCoordinators

migrationCoordinatorsコレクションは各シャードに存在し、このシャードから別のシャードへの移行において、進行中の各チャンクのドキュメントを保存します。シャードのレプリカセットの過半数のノードにドキュメントを書き込めない場合、チャンクの移行は失敗します。

移行が完了すると、移行を説明するドキュメントがコレクションから削除されます。

config.mongos

Tip

内部 MongoDB メタデータ

mongosコレクションには、クラスターに関連付けられた各mongos インスタンスのドキュメントが保存されます。クラスターはレポート作成の目的でこのコレクションを維持します。

mongosコレクション内の各ドキュメントにはこれらのフィールドが含まれています。

フィールド	データ型	説明
`_id`	文字列	`mongos`が実行されているホスト名とポート。`_id`は`<hostname>:<port>`としてフォーマットされます。
`advisoryHostFQDNs`	文字列の配列	`mongos`の完全修飾ドメイン名（FQDN）の配列。
`created`	日付	`mongos`が開始されたとき。バージョン5.2の新機能。
`mongoVersion`	文字列	`mongos`が実行している MongoDB のバージョン。
`ping`	日付	`mongos`インスタンスが 30 秒ごとに構成サーバーに ping を送信します。このフィールドは、最後の ping 時間を示します。
`up`	NumberLong	最後の ping の時点で `mongos` が起動していた秒数。
`waiting`	ブール値	このフィールドは常に `true` であり、下位互換性のためだけに含まれています。

次のドキュメントは、example.com:27017 で実行されている mongos のステータスを示しています。

[
   {
     _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.placementHistory

Tip

内部 MongoDB メタデータ

placementHistoryコレクションはコンフィギュレーションサーバーに存在し、特定のクラスタータイムスタンプ時にデータベースまたはコレクションのデータが含まれていたシャードを記録します。 MongoDB はこの情報を使用して履歴データ配置を再構築します。

myCollectiontestデータベース内のという名前のコレクションの場合、placementHistory コレクション内のドキュメントは次のようになります。

{
  _id: ObjectId("61e0a1f4e5b8c9d0a1b2c3d4"),
  nss: "test.myCollection",
  collUuid: UUID("07c63242-51b3-460c-865f-a67b3372d792"),
  timestamp: Timestamp(1626895826, 1),
  shards: [ "shardA", "shardB" ]
}

nss フィールドには、名前空間またはデータベース名いずれかを含めることができます。collUuid フィールドは、コレクションにのみ存在します。

config.rangeDeletions

rangeDeletionsコレクションは各シャードに存在し、孤立したドキュメントを含む各チャンク範囲にドキュメントを保存します。シャードのレプリカセットの過半数のノードにドキュメントを書き込めない場合、チャンクの移行は失敗します。

孤立したチャンク範囲が完了されると、その範囲を説明するドキュメントがコレクションから削除されます。

config.settings

Tip

内部 MongoDB メタデータ

settingsコレクションには、次のシャーディング構成設定が保持されます。

範囲サイズ。範囲サイズを変更するには、「シャーディングされたクラスターの範囲サイズの変更」を参照してください。指定された chunksize 値はメガバイト単位です。
バランサー設定。バランサーのステータスを含むバランサー設定を変更するには、「シャーディングされたクラスターバランサーの管理」を参照してください。
Autosplit:

MongoDB 6.0.3以降、自動チャンク分割は実行されません。これはバランシングポリシーの改善によるものです。自動分割コマンドは引き続き存在しますが、操作は実行されません。

MongoDB 6.1 より前のバージョンの場合:
- balancerStart は、シャーディングされたクラスターの自動分割も有効にします。
- balancerStop は、シャーディングされたクラスターの自動分割も無効にします。
- 自動分割フラグを有効または無効にするには、対応する sh.enableAutoSplit() メソッドまたは sh.disableAutoSplit() メソッドを使用します。

settings コレクション内のドキュメントの例:

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

config.shards

Tip

内部 MongoDB メタデータ

shardsコレクションは、次のように、クラスター内の各シャードを個別のドキュメントで表します。

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

シャードがレプリカセットの場合、次の例のように host フィールドにはレプリカセットの名前、次にスラッシュ、次にレプリカセットの各ノードのホスト名のカンマ区切りリストが表示されます。

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

シャードにゾーンが割り当てられている場合、このドキュメントには tags フィールドがあり、次の例のように、割り当てられているゾーンの配列が保持されます。

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

config.tags

Tip

内部 MongoDB メタデータ

tagsコレクションには、クラスター内の各ゾーン範囲のドキュメントが保持されます。tags コレクション内のドキュメントは次のようになります。

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

config.version

Tip

内部 MongoDB メタデータ

versionコレクションには、現在のメタデータのバージョン番号が保持されます。このコレクションには 1 つのドキュメントのみが含まれています。（例: ）。

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

versionコレクションにアクセスするには、db.getCollection() メソッドを使用する必要があります。例、コレクションのドキュメントを取得するには、次のようにします。

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

セッションをサポートするコレクション

config データベースには、スタンドアロン、レプリカセット、シャーディングされたクラスターの不特定のコンシステントセッションと、レプリカセットとシャーディングされたクラスターの再試行可能な書き込みとトランザクションをサポートするための内部コレクションが含まれています。

警告

これらのコレクションを手動で変更したり削除したりしないでください。

またはmongodmongos mongoshインスタンスのこれらのコレクションにアクセスするには、をインスタンスに接続します。

config.system.sessions

system.sessions コレクションには、配置のすべてのノードが利用できるセッションレコードが保存されます。

ユーザーが mongod または mongos インスタンスでセッションを作成すると、セッションのレコードは最初はインスタンスのメモリ内にのみ存在します。インスタンスはキャッシュされたセッションを system.sessions コレクションに定期的に同期します。同期されると、配置のすべてのノードにそのセッションが表示されます。

system.sessions コレクション内のレコードを表示するには、$listSessions を使用します。

警告

system.sessions コレクションを手動で修正したり削除したりしないでください。

シャーディングされたクラスターでは、system.sessions コレクションがシャーディングされます。

シャードをシャーディングされたクラスターに追加するときに、追加するシャードにすでに独自の system.sessions コレクションが含まれている場合、MongoDB は追加プロセス中に新しいシャードの system.sessions コレクションを削除します。

config.transactions: transactions コレクションには、レプリカセットとシャーディングされたクラスターの再試行可能な書き込みとトランザクションをサポートするために使用されたレコードが保存されます。
警告
transactions コレクションを手動で修正したり削除したりしないでください。

戻る

参照

シャーディングされたコレクションのデフラグ