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

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

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

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

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

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

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

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

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

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

同様に、インデックス構築が進行中に、アプリケーションはproduct_sku の重複する値を持つdocumentを inventoryコレクションに正常に書き込むことができます。

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

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

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

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

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

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

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

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

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

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

createIndexes は、コレクションでの 1 つ以上のインデックスの構築をサポートしています。createIndexes はメモリとディスク上の一時ファイルの組み合わせを使用してインデックスを構築します。デフォルトのメモリ制限は、createIndexes コマンドあたり 200 メガバイトで、そのコマンドでビルドされたすべてのインデックス間で均等に共有されます。例、1 つの createIndexes コマンドで 10 インデックスをビルドする場合、 MongoDB はデフォルトのメモリ制限である 200 を使用して、各インデックス20 メガバイトをインデックス構築プロセスに割り当てます。メモリ制限に達すると、 MongoDB はビルドを完了するために --dbpath 内の _tmp サブディレクトリに一時ファイルを作成します。

maxIndexBuildMemoryUsageMegabytes パラメーターを使用してメモリ制限を調整します。このパラメータを増やす必要があるのは、単一の createIndexes コマンドで多数の同時インデックス構築を実行する場合や、500 GBより大きいデータセットをインデックスする場合など、まれなケースのみです。

各 createIndexes コマンドには maxIndexBuildMemoryUsageMegabytes の制限があります。デフォルトの maxNumActiveUserIndexBuilds である 3 を使用する場合、すべての同時インデックスビルドの合計メモリ使用量は、maxIndexBuildMemoryUsageMegabytes の値の最大 3 倍に達します。

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

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

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

• インデックス構築にはコミットクォーラムを使用します。

• 書き込み操作には書込み保証が必要です。

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

コミットクォーラムでは、データを保持する投票権を持つノードの数、または同時インデックス構築をコミットするために準備が必要な投票権を持つノード（プライマリを含む）を指定した後に、プライマリによりコミットが実行されます。

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

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

プライマリまたはセカンダリ mongod が "force" : true を使用してクリーンな shutdown を実行するか、インデックス構築中に SIGTERM シグナルを受信し、commitQuorum がデフォルトの votingMembers に設定されている場合、インデックス構築の進捗がディスクに保存されます。mongod は再起動時にインデックス構築を自動的に回復し、保存されたチェックポイントから続行します。

mongod が正常にシャットダウンされずにクラッシュした場合、コミットクォーラムの設定に関係なく、インデックス構築を再開することはできません。mongod がオンラインに戻ると、インデックス構築は最初からやり直されます。

インデックス構築は、保存されたチェックポイントから一度だけ再開できます。同じインデックス構築が進行中に mongod が再起動した場合、ビルドはチェックポイントから再開されず、最初からやり直されます。

mongod は、インデックス構築をリカバリしていますながらスタートアッププロセスを実行できます。

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

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

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

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

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

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

• ロールバックしてもインデックス構築が取り消されない場合、MongoDB はロールバック完了後にインデックス構築を再開します。

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

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

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

• unique キー制約を使用してインデックスを作成し、1 つのシャードに重複 document を含むチャンクが含まれている場合。このような場合、インデックスの作成操作は、重複のないシャードでは成功するものの、重複のあるシャードでは成功しない可能性があります。

• 複数のシャードにわたってインデックスをローリング処理で作成する場合（複数のシャードにわたって手作業でインデックスを 1 つずつビルドする場合）、関連付けられたシャードのインデックス作成に失敗するか、異なる仕様で誤ったインデックスをビルドする場合のいずれかになります。

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

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

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

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

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

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