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

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

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

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

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

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

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

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

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

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

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

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

• コレクション内のドキュメントがどれもインデックス制約に違反していないことを検証します。

• 違反のない書き込み操作を保証できないアプリケーションからの、コレクションへの書き込みをすべて停止します。

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

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

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

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

ターゲットとなるコレクションの書き込み負荷が大きい時間帯にインデックスを構築すると、書き込みパフォーマンスが低下し、インデックス構築に時間がかかる可能性があります。

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

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

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

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

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

プライマリで中断されたインデックス構築 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 を返します。

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

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

インデックスが構築されている間、進捗状況は MongoDB ログに記録されます。インデックス構築が停止して再開されると、次のようなフィールドを含むログメッセージが表示されます。

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