Docs Menu
Docs Home
/
MongoDBマニュアル
/ /

Config Database

項目一覧

  • 制限事項
  • シャーディングされたクラスター操作をサポートするコレクション
  • セッションをサポートするコレクション

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

  • シャーディングされたクラスター操作、および

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

注意

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

  • mongos では、 config データベースに、collectionschunks などのコンフィギュレーションサーバー上にあるコレクションが表示されます。

  • mongod では、 config データベースに、migrationCoordinators または rangeDeletions など、指定されたシャードに固有のコレクションが表示されます。

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

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

重要

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 メタデータ

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

chunksコレクションには、クラスター内の各チャンクのドキュメントが保存されます。 mydb.foo-a_\"cat\"という名前のチャンクのドキュメントの次の例を考えてみましょう。

{
"_id" : "mydb.foo-a_\"cat\"",
"lastmod" : Timestamp(2, 1),
"uuid": "c025d039-e626-435e-b2d2-c1d436038041",
"min" : {
"animal" : "cat"
},
"max" : {
"animal" : "dog"
},
"shard" : "shard0004",
"history" : [ { "validAfter" : Timestamp(1569368571, 27), "shard" : "shard0004" } ]
}

これらのドキュメントは、min フィールドとmax フィールドのチャンクを記述するシャードキーの値の範囲を保存します。さらに、 shardフィールドは、チャンクを「所有する」クラスター内のシャードを識別します。

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.lockpings

Tip

内部 MongoDB メタデータ

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

lockpingsコレクションは、シャーディングされたクラスター内のアクティブなコンポーネントを追跡します。 example.com:30000上でmongosが実行されているクラスターの場合、 lockpingsコレクション内のドキュメントは次のようになります。

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

Tip

内部 MongoDB メタデータ

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

locksコレクションには分散されたロックが保存されています。 コンフィギュレーションサーバー レプリカセットのプライマリは、 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"
}

バージョン3.4以降、 stateフィールドには常に値2が含まれ、レガシーのmongosインスタンスがバランシング操作を実行するのを防ぎます。 whenフィールドは、コンフィギュレーションサーバーのノードがプライマリになった時間を指定します。

バージョン3.4では、バランサーがアクティブな場合、次の3.4のようにバランサーはロックを取得します。 例:

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

バージョン3.6以降、バランサーは「ロック」を取得しなくなりました。 3.4から3.6にアップグレードした場合は、残りの"_id" : "balancer"ドキュメントを削除することを選択できます。

config.migrationCoordinators

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

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

config.mongos

Tip

内部 MongoDB メタデータ

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

mongosコレクションには、クラスターに関連付けられた各mongosインスタンスのドキュメントが保存されます。 mongosインスタンスが30秒ごとにクラスターのすべてのノードに ping を送信することで、クラスターはmongosがアクティブであることを確認できます。 pingフィールドには最後の ping の時間が表示され、 upフィールドには最後の ping 時点でのmongosのアップタイムが報告されます。 クラスターはレポート作成の目的でこのコレクションを維持します。

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

{
"_id" : "example.com:27017",
"advisoryHostFQDNs" : [
"example.com"
],
"mongoVersion" : "4.2.0",
"ping" : ISODate("2019-09-25T19:26:52.360Z"),
"up" : NumberLong(50),
"waiting" : true
}
config.rangeDeletions

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

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

config.settings

Tip

内部 MongoDB メタデータ

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

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

以下は、 settingsコレクションに含まれるサンプル ドキュメントの一部です。

{ "_id" : "chunksize", "value" : 64 }
{ "_id" : "balancer", "mode" : "full", "stopped" : false }
{ "_id" : "autosplit", "enabled" : true }
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()

バージョン 3.6 の新機能

MongoDB 3.6 以降では、 データベースには、スタンドアロン、レプリカセット、シャーディングされたクラスターの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 コレクションを削除します。

  • バージョン4.4以降(および4.2.7 )、 MongoDB は、 system.sessionsコレクションを少なくとも1024チャンクに自動的に分割し、そのチャンクをクラスター内のシャード全体に均等に分散します。

config.transactions

transactions コレクションには、レプリカセットとシャーディングされたクラスターの再試行可能な書き込みトランザクションをサポートするために使用されたレコードが保存されます。

警告

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

戻る

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