ジャーナリング
障害発生時に耐久性を確保するため、MongoDB では、ディスク上の ジャーナル ファイルへの 先行書込みログ が使用されます。
ジャーナリングと WiredTigerストレージ エンジン
重要
このセクションで言及されているログは、MongoDB ログ ファイルではなく、WiredTiger の先行書き込みログ（つまり、ジャーナル）を指します。
WiredTiger は、チェックポイントを使用して、ディスク上のデータの一貫したビューを提供し、MongoDB が最後のチェックポイントから回復できるようにします。ただし、チェックポイント間で MongoDB が予期せず終了した場合は、最後のチェックポイント後に発生した情報を回復するためにジャーナリングが必要になります。
注意
MongoDB 6.1 以降では、ジャーナリングは常に有効になっています。その結果、MongoDB は storage.journal.enabled オプションと、対応する --journal および --nojournal コマンドライン オプションを削除します。
ジャーナリングを使用すると、回復プロセスは次のようになります。
データ ファイルを調べて、最後のチェックポイントの識別子を見つけます。
ジャーナル ファイル内で最後のチェックポイントの識別子と一致するレコードを検索します。
最後のチェックポイント以降のジャーナル ファイル内の操作を適用します。
ジャーナリング プロセス
ジャーナリングを使用すると、WiredTiger はクライアントが開始した書込み操作ごとに 1 つのジャーナル レコードを作成します。ジャーナル レコードには、最初の書込みによって発生したすべての内部書込み操作が含まれます。たとえば、コレクション内のドキュメントをアップデートすると、インデックスが変更される可能性があります。WiredTiger は、アップデート操作とそれに関連するインデックスの変更の両方を含む単一のジャーナル レコードを作成します。
MongoDB は、ジャーナル レコードを保存するためにメモリ内バッファリングを使用するように WiredTiger を構成します。スレッドは調整してバッファの自分の部分を割り当て、コピーします。128 KB までのすべてのジャーナル レコードがバッファリングされます。
WiredTiger では、次のいずれかの条件で、バッファされたジャーナル レコードがディスクに同期されます。
レプリカセットのノード（プライマリおよびセカンダリ）の場合
書込み操作に
j: trueの書込み保証が含まれているか、または暗示されている場合。さらにセカンダリノードの場合は、oplog エントリの各バッチ適用後に同期されます。
注意
writeConcernMajorityJournalDefaultが true であれば、書込み保証"majority"がj: trueであることを意味します。100ミリ秒ごと（
storage.journal.commitIntervalMsを参照してください）。WiredTiger が新しいジャーナル ファイルを作成する場合。MongoDB ではジャーナル ファイルのサイズが 100 MB に制限されているため、WiredTiger ではデータ約 100 MB ごとに新しいジャーナル ファイルが作成されます。
重要
書込み操作の合間に、ジャーナル レコードが WiredTiger バッファーに残っている間は、mongod のハード シャットダウン後にアップデート内容が失われる可能性があります。
Journal Files
ジャーナル ファイルの場合、MongoDB は dbPath ディレクトリの下に journal という名前のサブディレクトリを作成します。WiredTiger ジャーナル ファイルの名前は次の形式になります WiredTigerLog.<sequence>。ここで、<sequence> は 0000000001 から始まるゼロの多い数字です。
ジャーナル レコード
ジャーナル ファイルには、クライアントが開始した書込み操作ごとに記録が含まれます。
ジャーナル レコードには、最初の書込みによって発生したすべての内部書込み操作が含まれます。たとえば、コレクション内のドキュメントをアップデートすると、インデックスが変更される可能性があります。WiredTiger は、アップデート操作とそれに関連するインデックスの変更の両方を含む単一のジャーナル レコードを作成します。
各レコードにはユニークな識別子があります。
WiredTiger の最小ジャーナル レコード サイズは 128 バイトです。
圧縮
デフォルトでは、MongoDB は WiredTiger がジャーナリング データに snappy 圧縮を使用するように構成します。別の圧縮アルゴリズムを指定するか、圧縮を行わない場合は、storage.wiredTiger.engineConfig.journalCompressor 設定を使用します。詳しくは、「WiredTiger Journal Compressor を変更する」を参照してください。
注意
ログレコードが バイト（WiredTiger 128の最小 ログレコードサイズ ）WiredTigerはそのレコードを圧縮しません。
ジャーナル ファイルのサイズ制限
WiredTiger ジャーナル ファイルの最大サイズ制限は約 100 MB です。ファイルのサイズがその制限を超えると、WiredTiger は新しいジャーナル ファイルを作成します。
WiredTiger は古いジャーナル ファイルを自動的に削除し、最後のチェックポイントから回復するために必要なファイルのみを維持します。ジャーナル ファイル用に確保するディスク領域の量を決定するには、次の点を考慮してください。
チェックポイントのデフォルトの最大サイズは2 GB です
MongoDB がチェックポイントから回復するときに新しいジャーナル ファイルを書き込むために追加のスペースが必要になる場合があります
MongoDB はジャーナル ファイルを圧縮します
チェックポイントの復元にかかる時間は、ユースケースによって異なります。
最大チェックポイントのサイズをオーバーライドするか、圧縮を無効にすると、計算が大幅に異なる可能性があります。
これらの理由により、必要な追加スペースの量を正確に計算することは困難です。ディスク容量を過大評価すると、常により安全です。
重要
ジャーナル ファイル用に十分なディスク領域を確保しないと、MongoDB サーバーがクラッシュします。
事前割り当て
WiredTiger はジャーナル ファイルを事前に割り当てます。
ジャーナリングとインメモリ ストレージ エンジン
MongoDB Enterprise では、インメモリ ストレージ エンジン が一般提供（GA）の一部になっています。データはメモリ内に保存されるため、ジャーナルは別途作成されません。書込み保証（write concern）がある j: true の書込み操作は、ただちに承認されます。
レプリカセットのいずれかの投票ノードが、インメモリ ストレージエンジンを使用している場合は、writeConcernMajorityJournalDefault から false まで設定する必要があります。
注意
バージョン 4.2（および 4.0.13 および 3.6.14）以降、レプリカセットのノードが、インメモリ ストレージエンジン（投票または非投票）を使用している場合に、レプリカセットで writeConcernMajorityJournalDefault が true に設定されている場合、レプリカセットのノードは起動時に警告をログに記録します。
writeConcernMajorityJournalDefault を false に設定すると、MongoDB は書き込みを確認する前に、オンディスク ジャーナルに w: "majority" 書き込みが書き込まれるのを待たなくなります。そのため、"majority" 特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。