setIndexCommitQuorum
setIndexCommitQuorumsetIndexCommitQuorumコマンドは、プライマリ ノードがインデックスをコミットする前に、ローカル インデックス構築をコミットするために準備しておく必要があるデータを保持するノードの最小数を設定します。
互換性
このコマンドは、次の環境でホストされている配置で使用できます。
MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです
注意
このコマンドは、すべての MongoDB Atlas クラスターでサポートされています。すべてのコマンドに対する Atlas のサポートについては、 「サポートされていないコマンド」を参照してください。
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
構文
このコマンドの構文は、次のとおりです。
db.runCommand( { setIndexCommitQuorum: <string>, indexNames: [ <document> ], commitQuorum: <int> | <string>, comment: <any> } )
コマンドフィールド
このコマンドは、次のフィールドを使用します。
フィールド | タイプ | 説明 |
|---|---|---|
string | インデックスが構築されるコレクションの名前。 | |
array | 変更する進行中のインデックス ビルドの配列。 配列の各要素は、インデックスの名前である必要があります。
| |
int or string | データを保持するレプリカセット ノードの最小数（ コミットクォーラム）で、プライマリが MongoDB v 5.0以降、 コミットクォーラムが commitQuorum を更新するには、ノード レプリカセット ノードで 次の値をサポートします。
| |
comment | any | 任意。このコマンドに添付するユーザー指定のコメント。設定すると、このコメントは以下の場所にこのコマンドの記録と合わせて表示されます。
コメントには、有効な BSON 型（string, integer, object, array など）を使用できます。 |
動作
注意
FeatureCompatibilityVersion 4.4 以上が必要です。
レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります。
インデックス作成はマルチステージ プロセスです。 インデックス作成プロセスでは、セカンダリ ノードでのレプリケーションラグを最小限に抑えるためにcommit quorumが使用されます。
セカンダリ ノードがcommitIndexBuild oplog エントリを受信すると、そのノードはローカル インデックスのビルドがコミットされるまで、それ以上の oplog アプリケーションを停止します。 インデックスビルドが完了までにかかる時間は 秒から 日までであるため、セカンダリ ノードのビルドがプライマリ ノードよりも遅い場合、レプリケーションラグが大きくなる可能性があります。
レプリケーションラグを管理するために、 コミットクォーラム は、最小数のセカンダリもインデックス ビルドをコミットする準備ができるまで、プライマリ ノードでのインデックス ビルドのコミットを遅らせます。
コミットクォーラムは、コマンドの完了時にセカンダリのインデックスが使用可能になることを保証するものではありません。 特定の数のセカンダリを使用可能にするには、適切な書込み保証 ( write concern) を設定します。
コミットクォーラムに含まれていないセカンダリ ノードがcommitIndexBuild oplog エントリを受信した場合、そのノードはインデックスのビルドが完了するまでレプリケーションをブロックする可能性があります。
setIndexCommitQuorumを発行しても、 commitQuorumが0のインデックスビルドには影響しません。
重要
buildIndexesがfalseに設定されているレプリカセット ノードはコミットクォーラムに含めることができません。
コミットクォーラムと書込み保証の対比
インデックス構築にはコミットクォーラムを使用します。
書き込み操作には書込み保証が必要です。
クラスタ内の各データ保有ノードは投票ノードです。
コミットクォーラムは、プライマリを含むデータを保持する投票ノードの数、またはどの投票ノードがインデックス構築を同時にコミットする準備ができている必要があるかを指定し、その後プライマリがコミットを実行します。
書き込み保証 (write concern) とは、指定された数のインスタンスに書き込み (write) が伝わったことを確認するレベルです。
バージョン 8.0 での変更: コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築の oplog エントリを複製する必要があるノードの数が指定されます。
以前のリリースでは、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築を完了する必要があるノードの数が指定されていました。
例
レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセット ノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード（コミットクォーラム）でインデックス構築を完了する必要があります。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。
次の操作では、2 つのインデックスのインデックスビルドを開始します。
db.getSiblingDB("examples").invoices.createIndexes( [ { "invoices" : 1 }, { "fulfillmentStatus" : 1 } ] )
デフォルトでは、インデックスビルドでは"votingMembers"コミットクォーラム、またはすべてのデータを持つ投票レプリカセット メンバーが使用されます。 次の操作を実行すると、インデックスビルドのコミットクォーラムが"majority"またはデータを保持する投票ノードの単純過半数に変更されます。
db.getSiblingDB("examples").runCommand( { "setIndexCommitQuorum" : "invoices", "indexNames" : ["invoices_1", "fullfillmentStatus_1"], "commitQuorum" : "majority" } )
indexNamesに指定されるインデックスは、特定のインデックス ビルダに関連付けられている進行中のビルドのセット全体である必要があります（つまりcreateIndexes()操作）。indexNamesフィールドは、インデックスの名前を指定します。 インデックスは明示的な名前なしで作成されたため、MongoDB はインデックス フィールドの名前とソート順序を連結してインデックス名を生成しました。