Config Database

項目一覧

制限事項

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

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

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

注意

シャーディングされたクラスターは、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 メタデータ

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 コレクションには、次のシャーディング構成設定が保持されます。

チャンクサイズ。チャンクサイズを変更するには、「シャーディングされたクラスターのチャンクサイズの変更」を参照してください。指定されたchunksize値はメガバイト単位です。
バランサー設定。バランサーのステータスを含むバランサー設定を変更するには、「シャーディングされたクラスターバランサーの管理」を参照してください。
MongoDB 4.2 以降:
- balancerStart は、シャーディングされたクラスターの自動分割も有効にします。
- balancerStop は、シャーディングされたクラスターの自動分割も無効にします。
自動分割。自動分割フラグを有効または無効にするには、対応するsh.enableAutoSplit()メソッドまたはsh.disableAutoSplit()メソッドを使用します。
MongoDB 4.2 以降:
- balancerStart は、シャーディングされたクラスターの自動分割も有効にします。
- balancerStop は、シャーディングされたクラスターの自動分割も無効にします。

以下は、 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 コレクションを手動で修正したり削除したりしないでください。

戻る

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

ストレージ