Config Database
config
データベースのコレクションは以下をサポートします。
スタンドアロン、レプリカセット、シャーディングされたクラスターの場合は不特定にコンシステント セッションと、レプリカセットとシャーディングされたクラスターの場合は再試行可能な書き込み。
注意
シャーディングされたクラスターは、mongos
に接続するか mongod
に接続するかに応じて、config
データベースに異なるコレクションを表示する場合があります。
mongos
では、config
データベースに、collections
またはchunks
などのコンフィギュレーションサーバーにあるコレクションが表示されます。mongod
では、config
データベースに、migrationCoordinators
またはrangeDeletions
など、指定されたシャードに固有のコレクションが表示されます。
コンフィギュレーションサーバーとシャードが同じノードでホストされている場合、mongos
は、config
データベース内の一部のシャード ローカル コレクションにアクセスできる可能性があります。
制限事項
MongoDB 5.0 以降では、次の読み取り保証(read concern)とオプションのある config.transactions
コレクションでは非トランザクションは読み取れません。
"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
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.clientAddr
この変更を開始する
mongos
インスタンスである、クライアントのアドレスを保持する文字列。
config.changelog.time
変更が発生した日時を反映する ISODate タイムスタンプ。
config.chunks
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
MongoDB 8.0 以降、
config.collections
は、moveCollection
によって移動されたすべてのシャーディングされたコレクションとシャーディングされていないコレクションのメタデータを保存します。8.0 より前のバージョンの MongoDB では、
config.collections
はシャーディングされたコレクションのメタデータのみを保存します。config.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.csrs.indexes
バージョン 7.0 で追加。
indexes
コレクションには、シャードで使用可能な各グローバル インデックスのドキュメントが保存されます。コレクション内の各ドキュメントには、次のフィールドが含まれています。
フィールドデータ型説明name
文字列
グローバル インデックスの名前。
keyPattern
ドキュメント
インデックスキーの指定。
options
ドキュメント
インデックスがグローバル インデックスかどうかなど、指定されたインデックスオプションに関する情報を提供します。
lastmod
タイムスタンプ
インデックスが最後に変更された日時とインデックスのバージョンに関する情報を提供するタイムスタンプ。
collectionUUID
UUID
シャーディングされたコレクションの UUID。
indexCollectionUUID
UUID
グローバル インデックスを追跡するセカンダリ コレクションのUUID。
config.databases
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
mongos
コレクションには、クラスターに関連付けられた各mongos
インスタンスのドキュメントが格納されます。クラスターはレポート作成の目的でこのコレクションを維持します。mongos
コレクション内の各ドキュメントにはこれらのフィールドが含まれています。フィールドデータ型説明_id
文字列
mongos
が実行されているホスト名とポート。_id
は<hostname>:<port>
としてフォーマットされます。advisoryHostFQDNs
文字列の配列
mongos
の完全修飾ドメイン名(FQDN) の配列。created
日付
mongos
が開始されたとき。バージョン 5.2 で追加。
mongoVersion
文字列
mongos
が実行している MongoDB のバージョン。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
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
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
tags
コレクションには、クラスター内の各ゾーン範囲のドキュメントが保持されます。tags
コレクション内のドキュメントは次のようになります。{ "_id" : { "ns" : "records.users", "min" : { "zipcode" : "10001" } }, "ns" : "records.users", "min" : { "zipcode" : "10001" }, "max" : { "zipcode" : "10281" }, "tag" : "NYC" }
config.version
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
コレクションを手動で修正したり削除したりしないでください。