データが存在するコレクションでのインデックス構築

項目一覧

動作

インデックス構築がデータベースのパフォーマンスに与える影響
複製された環境でのインデックス構築
構築の失敗と復元
進行中のインデックス構築の監視
進行中のインデックス構築の終了
インデックス構築のプロセス

インデックス構築では、最適化された構築プロセスを使用し、インデックス構築の開始時と終了時にコレクションを排他ロックします。構築プロセスの残りの部分は、読み取り操作と書込み (write) 操作のインターリーブによって一時停止されます。インデックス構築プロセスとロック動作の詳細については、「インデックス構築プロセス」を参照してください。

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持する全レプリカセットノードで同時に構築されます。プライマリでは、最小数のデータを保持する投票ノード（コミットクォーラム）が必要です。これにはプライマリ自身も含まれます。また、インデックスが使用可能とマークされる前に構築を完了する必要があります。「投票」ノードとは、members[n].votes が 0 より大きいレプリカセットのノードです。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

MongoDB 7.1 以降では、インデックス構築でのエラー報告が高速化され、障害回復力が高まります。新しいindexBuildMinAvailableDiskSpaceMBパラメータを使用して、インデックスビルドに必要な最小ディスク容量を設定することもできます。これにより、ディスク容量が低すぎる場合はインデックスビルドが停止します。

次の表は、MongoDB 7.1 以降と以前のバージョンのインデックス構築動作を比較したものです。

MongoDB 7.1 以降の動作	以前の MongoDB バージョンでの動作
重複キーエラーを除く、コレクションスキャンフェーズ中に見つかったインデックスエラーは直ちに返され、その後インデックスのビルドは停止します。以前の MongoDB バージョンでは、インデックスビルドの終了間際に発生するコミットフェーズでエラーが返されます。 MongoDB 7.1 は、インデックスエラーを迅速に診断するのに役立ちます。たとえば、互換性のないインデックス値の形式が見つかった場合は、すぐにエラーが返されます。	MongoDB 7.1 と比較して、インデックス構築エラーが返されるまでに長い時間がかかる可能性があります。このエラーはコミットフェーズのインデックス構築の終了間して返されるためです。
配置の回復力を強化。インデックスビルドエラーが発生した場合、セカンダリノードはプライマリメンバーにインデックスビルドの停止をリクエストでき、セカンダリノードはクラッシュしません。インデックスビルドを停止するリクエストは常に可能ではありません。ノードがすでにインデックスをコミットするために投票している場合、セカンダリはインデックスビルドの停止をリクエストできず、セカンダリはクラッシュします（MongoDB 7.0 以前と同様）。	インデックス構築エラーにより、セカンダリノードがクラッシュする可能性があります。
インデックスビルドのためのディスク領域の管理を改善しました。使用可能なディスク容量が`indexBuildMinAvailableDiskSpaceMB`パラメータで指定された最小値を下回ると、インデックスビルドが自動的に停止されることがあります。ノードがすでにインデックスをコミットするために投票している場合、インデックスのビルドは停止されません。	使用可能なディスク容量が不足しても、インデックスの構築は停止しません。

注意

Atlas でのインデックス作成の詳細については、Atlas ドキュメントの「インデックス管理ページ」を参照してください。

動作

フォアグラウンド構築とバックグラウンド構築との比較

MongoDB の以前のバージョンでは、フォアグラウンドまたはバックグラウンドでのインデックスの構築がサポートされていました。フォアグラウンドでのインデックス構築は高速で、より効率の高いインデックスデータ構造が生成されていましたが、構築中はインデックスされるコレクションの親データベースへの読取りおよび書込みアクセスをすべてブロックする必要がありました。バックグラウンドでのインデックス構築は遅く、結果の効率も低いものでしたが、構築プロセス中にデータベースとそのコレクションへの読取りおよび書込みアクセスが可能でした。

インデックス構築では、メタデータの変更を保護するために、構築プロセスの開始時と終了時に、インデックスが作成されるコレクションのみが排他ロックされるようになりました。構築プロセスの残りの部分では、バックグラウンドインデックス構築の一時停止動作を使用して、構築中のコレクションへの読み取り/書込みアクセスを最大化しています。インデックス構築では、ロック動作の制限が緩いにもかかわらず、効率的なインデックスデータ構造が生成されます。

最適化されたインデックス構築のパフォーマンスは、最低でもバックグラウンドのインデックス構築と同等です。構築プロセス中に更新がほとんどまたはまったく受信されないワークロードの場合、最適化されたインデックス構築の速度は、同じデータでのフォアグラウンドインデックス構築と同等です。

進行中のインデックス構築の進行状況をモニタリングするには、db.currentOp() を使用します。

MongoDB では、createIndexesまたはそのシェルヘルパーcreateIndex()createIndexes()に指定されている場合は background インデックス構築は無視されます。

インデックス構築中の制約違反

一意のインデックスなど、コレクションに制約を強制するインデックスの場合、 mongodはインデックスのビルド完了後に、既存のドキュメントと同時に書込まれたすべてのドキュメントをチェックし、それらの制約に違反しているかどうかをチェックします。インデックス制約に違反するドキュメントは、インデックスのビルド中に存在する可能性があります。ビルドの最後にインデックス制約に違反するドキュメントがある場合、 mongodはビルドを終了し、エラーをスローします。

たとえば、データが入ったコレクションinventoryを考えてみましょう。管理者が、 product_skuフィールドに一意のインデックスを作成したいと考えています。コレクション内のいずれかのドキュメントでproduct_skuの値が重複している場合でも、インデックスのビルドは正常に開始できます。ビルドの最後に違反がまだ存在する場合、 mongodはビルドを終了し、エラーをスローします。

同様に、インデックスのビルドが進行中に、アプリケーションはproduct_skuの重複する値を持つドキュメントをinventoryコレクションに正常に書き込むことができます。ビルドの最後に違反がまだ存在する場合、 mongodはビルドを終了し、エラーをスローします。

制約違反によるインデックス構築失敗のリスクを軽減するには、以下の対策を取ります。

コレクション内のドキュメントがどれもインデックス制約に違反していないことを検証します。
違反のない書き込み操作を保証できないアプリケーションからの、コレクションへの書き込みをすべて停止します。

シャーディングされたコレクション

複数のシャードに分散されたシャーディングされたコレクションの場合、1 つ以上のシャードに重複したドキュメントを含むチャンクが含まれる場合があります。そのため、インデックスの作成操作は、一部のシャード（重複のないシャード）では成功するものの、他のシャード（重複のあるシャード）では成功しない場合があります。シャード間で不整合なインデックスが残らないようにするには、mongos から db.collection.dropIndex() を発行して、コレクションからインデックスを削除します。

この問題が発生するリスクを軽減するには、インデックスを作成する前に次の手順を実行します。

コレクション内のドキュメントがどれもインデックス制約に違反していないことを検証します。
違反のない書き込み操作を保証できないアプリケーションからの、コレクションへの書き込みをすべて停止します。

Tip

以下も参照してください。

シャーディングされたコレクションのインデックスの整合性チェック

同時インデックス構築の最大数

デフォルトでは、サーバーでは最大 3 つの同時インデックス構築が許可されています。許可される同時インデックス構築の数を変更するには、 maxNumActiveUserIndexBuilds パラメータを変更します。

同時インデックス構築の数が maxNumActiveUserIndexBuilds で指定された制限に達した場合、サーバーは、同時インデックス構築の数が制限を下回るまで、それ以上のインデックス構築をブロックします。

インデックス構築がデータベースのパフォーマンスに与える影響

書き込み負荷の高いワークロード中のインデックス構築

対象コレクションの書き込み負荷が高い時間帯にインデックスを構築すると、書込みパフォーマンスが低下し、インデックス構築に通常よりも時間がかかる場合があります。

こうした場合、アプリケーションでコレクションに対する書込み操作を停止または削減するメンテナンスウィンドの指定を検討します。このメンテナンスウィンド中にインデックス構築を開始して、構築プロセスによる潜在的な悪影響を軽減します。

使用可能なシステムメモリ (RAM) の不足

createIndexesは、コレクションに 1 つ以上のインデックスの構築をサポートしています。 createIndexesはメモリとディスク上の一時ファイルの組み合わせを使用してインデックス構築を完了します。 createIndexesのメモリ使用量のデフォルト制限は200メガバイトで、単一のcreateIndexesコマンドを使用してビルドされたすべてのインデックスに共有されます。メモリ制限に達すると、 createIndexesは--dbpathディレクトリ内の_tmpという名前のサブディレクトリにある一時ディスクファイルを使用してビルドを完了します。

maxIndexBuildMemoryUsageMegabytesサーバーパラメータを設定することで、メモリ制限を上書きできます。メモリ制限を高く設定すると、より早くインデックス構築を完了できる可能性があります。ただし、システム上の未使用 RAM に対してこの制限を高く設定しすぎると、メモリが不足し、サーバーがシャットダウンする可能性があります。

ホストマシンで使用可能な空き RAM が限られている場合は、 mongod RAM 使用量を変更する前に、メンテナンス期間をスケジュールしてシステム RAM の合計を増やす必要がある場合があります。

複製された環境でのインデックス構築

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります。

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセットノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード（コミットクォーラム）でインデックス構築を完了する必要があります。

重要

データを含む投票ノードにアクセスできなくなり、 commitQuorumがデフォルトのvotingMembersに設定されている場合、そのノードがオンラインに戻るまでインデックスビルドがハングする可能性があります。

ビルドプロセスの概要は以下の通りです。

プライマリが createIndexes コマンドを受信し、インデックス構築に関連付けられた "startIndexBuild" oplog エントリが直ちに作成されます。
セカンダリでは " StartIndexBuild " oplog エントリが複製された後に、インデックス構築を開始します。
コレクション内のデータのインデックス作成が終了したら、各ノード間でビルドへのコミットについての ”投票” が行われます。
セカンダリノードは、プライマリが投票の定足数を確認するまで、引き続きインデックスへの新しい書込み操作を処理します。
プライマリで投票の定足数に達すると、重複キーエラーなどキーに関する制約違反がないかどうかがチェックされます。
- キーの制約違反がない場合、プライマリはインデックス構築を完了し、インデックスを使用可能としてマークし、関連する " CommitIndexBuild " oplog エントリを作成します。
- キーの制約違反がある場合、インデックス構築は失敗します。プライマリはインデックス構築を中止し、関連する "abortIndexBuild" oplog エントリを作成します。
セカンダリは "CommitIndexBuild" oplog エントリを複製し、インデックス構築を完了します。
代わりに、セカンダリが " AbortIndexBuild " oplog エントリを複製すると、インデックス構築が中止され、構築ジョブが破棄されます。

シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。

インデックス構築プロセスの詳細については、「インデックス構築プロセス」を参照してください。

デフォルトでは、インデックス構築ではコミットクォーラム "votingMembers" またはすべてのデータを持つ投票ノードが使用されます。デフォルト以外のコミットクォーラムでインデックス構築を開始するには、 commitQuorumパラメータをcreateIndexesまたはそのシェルヘルパーdb.collection.createIndex()およびdb.collection.createIndexes()に指定します。

進行中の同時インデックス構築に必要なコミットクォーラムを変更するには、setIndexCommitQuorum コマンドを使用します。

注意

インデックス構築はレプリカセットのパフォーマンスに影響を与える可能性があります。インデックス構築によるパフォーマンスの低下を許容できないワークロードの場合は、ローリング処理によるインデックス構築プロセスの実行を検討します。ローリング処理によるインデックス構築では、一度に最大 1 つのレプリカセットノードを使用します。セカンダリノードから始まり、そのノードにスタンドアロンとしてインデックスが構築されます。ローリング処理によるインデックス構築には、少なくとも 1 回のレプリカセット選挙が必要です。

レプリカセットのインデックス構築については、「レプリカセットのインデックス構築」を参照してください。
シャーディングされたクラスターでのインデックス構築については、「シャーディングされたクラスターでのインデックス構築」を参照してください。

コミットクォーラムと書込み保証の対比

コミットクォーラムと書込み保証には重要な違いがあります。

インデックス構築にはコミットクォーラムを使用します。
書き込み操作には書込み保証が必要です。

クラスタ内の各データ保有ノードは投票ノードです。

コミットクォーラムでは、データを保持する投票ノードの数、またはプライマリがコミットを実行する前にプライマリを含めてどの投票ノードが同時インデックス構築のコミット準備をしておく必要があるかを指定します。

書込み保証 (write concern) とは、指定された数のインスタンスに書込み (write) が伝わったことを確認するレベルです。

バージョン8.0での変更:コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築をコミットした時に、書込み保証 (write concern)保証によって、コマンドが成功を返す前にインデックス構築のoplogエントリを複製する必要があるノードの数が指定されます。

以前のリリースでは、プライマリがインデックス構築をコミットしたときに、書込み保証 (write concern)によって、コマンドが成功を返す前にインデックス構築を完了する必要があるノードの数が指定されていました。

構築の失敗と復元

プライマリで中断されたインデックス構築 `mongod`

MongoDB 5.0以降では、プライマリmongodが"force" : trueを使用してクリーンなshutdownを実行するか、インデックス構築中にSIGTERMシグナルを受信し、 commitQuorumがデフォルトのvotingMembersに設定されている場合、インデックス構築進行状況はディスクに保存されます。 mongodは再起動時に自動的にインデックス構築を回復し、保存されたチェックポイントから続行します。以前のバージョンでは、インデックスの構築が中断された場合、最初からやり直す必要がありました。

セカンダリで中断されたインデックス構築 `mongod`

MongoDB 5.0以降では、セカンダリ mongod が "force" : true を使用してクリーン shutdown を実行するか、インデックス構築中に SIGTERM シグナルを受信し、commitQuorum がデフォルトの votingMembers に設定されている場合、インデックス構築の進行状況がディスクに保存されます。mongod は、再起動時にインデックス構築を自動的に回復し、保存されたチェックポイントから続行します。以前のバージョンでは、インデックス構築が中断された場合、最初からやり直す必要がありました。

mongodは、リカバリインデックスの構築中にスタートアッププロセスを実行できます。

mongodをスタンドアロン（ replication.replSetNameを削除またはコメントアウトするか、 --replSetNameを省略すると、 mongodはインデックスビルドを再開できなくなります。手動でdroppedになるまで、ビルドは一時停止状態のままになります。

スタンドアロンで中断されたインデックス構築 `mongod`

インデックスビルド中にmongodがシャットダウンすると、インデックスビルドジョブとすべての進行状況が失われます。 mongodを再起動しても、インデックスビルドは再開されません。インデックスのビルドを再開するには、 createIndex()操作を再発行する必要があります。

ビルドプロセス中のロールバック

MongoDB 5.0以降では、インデックスビルド中にノードが以前の状態にロールバックされた場合、インデックスビルドの進行状況がディスクに保存されます。ロールバックが完了したときに実行する作業がまだある場合、 mongodは自動的にインデックス構築を回復し、保存されたチェックポイントから続行します。

MongoDB では、進行中のインデックス構築を一時停止してロールバックを実行できます。

ロールバックしてもインデックス構築が取り消されない場合、MongoDB はロールバック完了後にインデックス構築を再開します。
ロールバックによってインデックス構築が取り消された場合は、ロールバックの完了後に 1 つまたは複数のインデックスを再作成する必要があります。

シャーディングされたコレクションのインデックスの整合性チェック

コレクションのチャンクを含む各シャードにまったく同じインデックス（インデックスオプションを含む）がない場合、シャーディングされたコレクションのインデックスには一貫性がありません。通常の操作では一貫性のないインデックスは発生しないはずですが、次のような一貫性のないインデックスが発生する可能性があります。

ユーザーが unique キー制約を使用してインデックスを作成していて、1 つのシャードに重複ドキュメントを含むチャンクが含まれている場合。このような場合、インデックスの作成操作は、重複のないシャードでは成功するものの、重複のあるシャードでは成功しない可能性があります。
ユーザーが複数のシャードにわたってインデックスをローリング処理で作成している（複数のシャードにわたって手作業でインデックスを 1 つずつ構築している）時、関連付けられたシャードのインデックス作成に失敗した場合、または異なる仕様で誤ったインデックスを構築した場合。

コンフィギュレーションサーバーのプライマリは、シャーディングされたコレクションのシャード間でのインデックスの不整合を定期的にチェックします。これらの定期的チェックを構成するには、 enableShardedIndexConsistencyCheckとshardedIndexConsistencyCheckIntervalMSを参照してください。

コマンドserverStatusは、構成サーバーのプライマリで実行された場合にインデックスの不整合を報告するフィールド shardedIndexConsistency を返します。

シャーディングされたコレクションに一貫性のないインデックスがないかどうかを確認するには、「シャード間で一貫性のないインデックスを検索する」を参照してください。

進行中のインデックス構築の監視

インデックス構築操作のステータスを確認するには、のdb.currentOp() mongoshメソッドを使用できます。インデックス作成操作の現在の操作をフィルタリングする方法の例については、「アクティブなインデックス作成操作」を参照してください。

msg フィールドには、インデックス構築プロセスの現在の段階の完了率の測定値が含まれます。

インデックス構築の停止と再開をログで確認

インデックス構築中は、進行状況がMongoDB ログに書き込まれます。インデックス構築が停止され、その後再開された場合、以下のようなフィールドを含むログメッセージが表示されます。

 "msg":"Index build: wrote resumable state to disk",
 "msg":"Found index from unfinished build",

進行中のインデックス構築の終了

進行中のインデックス構築を終了するには、 dropIndexes コマンドまたはそのシェルヘルパー dropIndex() または dropIndexes() を使用します。詳細については、「進行中のインデックス構築の停止」を参照してください。

レプリカセットまたはシャーディングされたクラスターで進行中のインデックス構築を終了するためにkillOp は使用しないでください。

インデックス構築のプロセス

次の表は、インデックス構築プロセスの各段階について説明しています。

ステージ	説明
ロック	`mongod`は、インデックス作成されるコレクションに対して排他`X`ロックを取得します。これにより、コレクションを対象とする複製された書込み (write) 操作やメタデータコマンドの適用など、コレクションに対するすべての読み取り操作と書込み (write) 操作がブロックされます。 The `mongod` does not yield this lock.
初期化	`mongod`は、この初期状態で次の 3 つのデータ構造を作成します。初期インデックスのメタデータエントリ。ビルドプロセス中にインデックスされるコレクションへの書込みによって生成されたキーを格納する一時テーブル（サイド書込みテーブル）。キー生成エラーを引き起こす可能性のあるすべてのドキュメントの一時テーブル（制約違反テーブル）。ドキュメントのインデックスフィールドに無効なキーがある場合、キー生成エラーが発生します。たとえば、ユニークインデックスを構築するときにフィールド値が重複しているドキュメント、または 2dsphere インデックスを構築するときに GeoJSON オブジェクトが不正な場合などです。
ロック	`mongod`は、排他的`X` `IX`ロックを意向排他ロックにダウングレードします。 `mongod`は、読み取り操作と書込み（write）操作をインターリーブするためにこのロックを定期的にロックします。
コレクションのスキャン	コレクション内の各ドキュメントに対して、 `mongod`はそのドキュメントのキーを生成し、そのキーを外部ソーターにダンプします。コレクションスキャン中に`mongod`がキーを生成中にキー生成エラーが発生した場合、後で処理できるように制約違反テーブルに保存されます。 `mongod`がキーの生成中に他のエラーに発生した場合、ビルドはエラーで失敗します。 `mongod`がコレクションスキャンを完了すると、ソートされたキーをインデックスにダンプします。
プロセスサイド書込みテーブル	`mongod`は、先入れ先出しの優先順位を使用してサイド書き込みテーブルを空にします。 `mongod`がサイド書込みテーブルでキーを処理中にキー生成エラーを発生した場合、後で処理できるように制約違反テーブルに保存されます。 `mongod`がキーを処理中に他のエラーが発生した場合、ビルドはエラーで失敗します。 `mongod` は、構築プロセス中にコレクションに書き込まれるドキュメントごとに、そのドキュメントのキーを生成し、後で処理できるようにサイド書込みテーブルに格納します。`mongod` はスナップショットシステムを使用して、処理するキーの数に制限を設定します。
投票とコミットクォーラムの待機	レプリカセットの一部ではない`mongod`は、このステージをスキップします。 `mongod`は、インデックスをコミットするためにプライマリに「投票」を送信します。具体的には、プライマリ上の内部複製コレクションに「投票」を書込みます。 `mongod`がプライマリの場合、コミットクォーラムが投票（デフォルトではすべての投票データを保持するノード）に達するまで待機してから、インデックスビルドプロセスを続行します。 `mongod` がセカンダリの場合、"commitIndexBuild" または "abortIndexBuild" oplog エントリのいずれかが複製されるまで待機します。 `mongod`が "CommitIndexBuild" oplog エントリを複製すると、サイド書込みテーブルの処理が完了し、インデックス構築プロセスの次の段階に進みます。 `mongod` が "abortIndexBuild" oplog エントリを複製すると、インデックス構築が中止され、構築ジョブが破棄されます。コミットクォーラムを待っている間、`mongod` は、インデックス付けされるコレクションへの書込み (write) 操作から生成された追加のキーをサイド書込みテーブルに追加し、定期的にテーブルを空にします。
ロック	`mongod`は、コレクションの意向排他`IX`ロックを共有`S`ロックにアップグレードします。これにより、コレクションを対象とする複製された書込み (write) 操作やメタデータコマンドの適用など、コレクションへのすべての書込み (write) 操作がブロックされます。
一時サイド書き込みテーブルの処理の完了	`mongod` は、一時テーブル内の残りのレコードの処理を続行します。`mongod` はこの段階でレプリケーションを一時停止する可能性があります。 `mongod`がサイド書込みテーブルでキーを処理中にキー生成エラーを発生した場合、後で処理できるように制約違反テーブルに保存されます。 `mongod`がキーを処理中に他のエラーが発生した場合、ビルドはエラーで失敗します。
ロック	`mongod` は、コレクションの共有 `S` ロックをコレクションの排他的 `X` ロックにアップグレードします。これにより、コレクションを対象とする複製された書込み (write) 操作やメタデータコマンドの適用など、コレクションに対するすべての読み取り操作と書込み (write) 操作がブロックされます。`mongod` はこのロックを停止しません。
サイド書き込みテーブルの削除	`mongod`は、削除する前にサイド書込みテーブル内の残りの操作を適用します。 `mongod`がサイド書込みテーブルでキーを処理中にキー生成エラーを発生した場合、後で処理できるように制約違反テーブルに保存されます。 `mongod`がキーを処理中に他のエラーが発生した場合、ビルドはエラーで失敗します。この時点で、インデックスにはコレクションに書き込まれたすべてのデータが含まれます。
プロセス制約違反テーブル	`mongod` がプライマリの場合、先入れ先出しの優先順位を使用して制約違反テーブルを空にします。制約違反テーブルのどのキーもキー生成エラーを生成しない場合、またはテーブルが空の場合、 `mongod`はテーブルを削除し、"commitIndexBuild" oplog エントリを作成します。セカンダリは、oplog エントリを複製した後、関連するインデックスのビルドを完了できます。制約違反テーブル内のいずれかのキーでもキー生成エラーが発生する場合、 `mongod`はビルドを中止し、エラーをスローします。 `mongod`は、関連する "abortIndexBuild" oplog エントリを作成し、セカンダリがインデックス構築ジョブを中止して破棄する必要があることを示します。 `mongod`がセカンダリの場合、制約違反テーブルが削除されます。 "commitOplogEntry" oplog エントリを作成する前に、プライマリが制約違反テーブルを正常に空にする必要があるため、セカンダリは違反が存在しないことを前提とできます。
インデックスを準備完了としてマークします	`mongod`はインデックスを使用可能としてマークするようにインデックスメタデータを更新します。
ロック	`mongod`はコレクションの`X`ロックを解放します。

Tip

以下も参照してください。

FAQ：同時実行性

戻る

一意への変換

レプリカセットでの作成

注意

動作

フォアグラウンド構築とバックグラウンド構築との比較

インデックス構築中の制約違反

シャーディングされたコレクション

Tip

以下も参照してください。

同時インデックス構築の最大数

インデックス構築がデータベースのパフォーマンスに与える影響

書き込み負荷の高いワークロード中のインデックス構築

使用可能なシステムメモリ (RAM) の不足

複製された環境でのインデックス構築

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

重要

注意

コミットクォーラムと書込み保証の対比

構築の失敗と復元

プライマリで中断されたインデックス構築 mongod

セカンダリで中断されたインデックス構築 mongod

スタンドアロンで中断されたインデックス構築 mongod

ビルドプロセス中のロールバック

シャーディングされたコレクションのインデックスの整合性チェック

進行中のインデックス構築の監視

インデックス構築の停止と再開をログで確認

進行中のインデックス構築の終了

インデックス構築のプロセス

Tip

以下も参照してください。

プライマリで中断されたインデックス構築 `mongod`

セカンダリで中断されたインデックス構築 `mongod`

スタンドアロンで中断されたインデックス構築 `mongod`