/ /

Config Database

このバージョンのドキュメントはアーカイブされており、サポートされなくなりました。6.0 配置をアップグレードするには、 MongoDB 7.0 のアップグレード手順を参照してください。

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

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

注意

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

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

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

制限事項

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

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

重要

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

注意

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

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

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

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

config.collections

Tip

内部 MongoDB メタデータ

collections コレクションでは、クラスター内のシャーディングされた各コレクションにドキュメントが格納されます。records データベースに pets という名前のコレクションがある場合、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", "partitioned" : true, "version" : { "uuid" : UUID("516a5f79-5eb9-4844-8ee9-b8e9de91b760"), "timestamp" : Timestamp(1626894204, 1), "lastMod" : 1 } }
{ "_id" : "hr", "primary" : "shardA", "partitioned" : false, "version" : { "uuid" : UUID("8e39d61d-6259-4c33-a5ed-bcd2ae317b6f"), "timestamp" : Timestamp(1626895015, 1), "lastMod" : 1 } }
{ "_id" : "reporting", "primary" : "shardB", "partitioned" : false, "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.rangeDeletions

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

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

config.settings

Tip

内部 MongoDB メタデータ

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

範囲サイズ。範囲サイズを変更するには、「シャーディングされたクラスターの範囲サイズの変更」を参照してください。指定された chunksize 値はメガバイト単位です。
バランサー設定。バランサーのステータスを含むバランサー設定を変更するには、「シャーディングされたクラスターバランサーの管理」を参照してください。
Autosplit:
MongoDB 6.0.3 以降では、自動チャンク分割は実行されません。これはバランシングポリシーの改善によるものです。自動分割コマンドは引き続き存在しますが、操作は実行されません。詳細については、「バランシングポリシーの変更」を参照してください。
MongoDB 6.0 より前のバージョンの場合:
- 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 データベースには、スタンドアロン、レプリカセット、シャーディングされたクラスターの不特定のコンシステントセッションと、レプリカセットとシャーディングされたクラスターの再試行可能な書き込みとトランザクションをサポートするための内部コレクションが含まれています。

警告

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

mongod または mongos インスタンスのこれらのコレクションにアクセスするには、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 コレクションを手動で修正したり削除したりしないでください。

戻る

シャーディングされたクラスターのトラブルシューティング

ストレージ