MongoDBでのジャーナリングの管理

MongoDBは、他のデータベースと同様に、書き込み操作の実行時に失敗する可能性があります。その場合、データベースが操作に復元されたときにデータベースを再開できるように、操作をどこかに保持する戦略が必要です。

MongoDBでは、ジャーナルを使用して、障害が発生した場合にデータを利用できるように、ディスク上のジャーナルファイルに先行書き込みログを記録します。 WiredTigerストレージエンジンはチェックポイントを使用して、ディスク上のデータの一貫したビューを提供し、MongoDBが最後のチェックポイントから回復できるようにしますが、予期せず終了しなかった場合に限ります。それ以外の場合は、最後のチェックポイントで発生した情報について、そのようなデータを回復するためにジャーナリングが有効になっている必要があります。

リカバリプロセスの手順は次のとおりです。データベースはデータファイルを調べて最後のチェックポイントの識別子を見つけ、この識別子を使用してジャーナルファイルでそれに一致するレコードを検索します。次に、最後のチェックポイント以降のジャーナルファイルの操作を適用します。

WiredTigerストレージエンジンでのジャーナルの仕組み

書き込み操作を開始するすべてのクライアントに対して、WiredTigerは、最初の書き込みによってトリガーされた内部書き込み操作で構成されるジャーナルレコードを作成します。更新されるコレクション内のドキュメントについて考えてみます。そのインデックスも変更されると予想されます。 WiredTigerは、更新操作と対応するインデックスの変更を組み込んだ単一のジャーナルレコードを作成します。

このレコードは、最大容量が128kBのメモリ内バッファに保存されます。次に、ストレージエンジンは、次のいずれかが満たされたときに、このバッファリングされたジャーナルレコードをディスクに同期します。

書き込み操作には、j：trueの書き込みに関する懸念が含まれます/暗黙的に示されます。
WiredTigerは、100MBのデータごとに新しいジャーナルファイルを作成します。
storage.journal.commitIntervalMsに応じて100ミリ秒ごと。
レプリカセットメンバーの場合：
- oplogエントリを待機している操作のインスタンス。つまり、因果整合性のあるセッションの一部として実行された読み取り操作と、oplogに対する転送スキャンクエリ。
- セカンダリメンバーの場合、oplogエントリのすべてのバッチアプリケーションの後。

mongodのハードシャットダウンの場合、書き込み操作が進行中の場合、ジャーナルレコードがWiredTigerバッファーに残っていても、更新が失われる可能性があります。

ジャーナルデータ圧縮

MongoDBのデフォルト設定は、WiredTigerにジャーナルデータにスナップ圧縮を使用するように指示します。これは、storage.wiredTiger.engineConfig.journalCompressor設定を使用して、必要な圧縮アルゴリズムに応じて変更できます。これらのログレコードは、サイズがWiredTigerの最小ログレコードサイズである128バイトを超える場合にのみ圧縮されます。

ジャーナルファイルのサイズを制限するジャーナルファイルの最大サイズは100MBであるため、ファイルがこの制限を超えると、新しいファイルが作成されます。

ジャーナルファイルがリカバリで使用された後、または最後のチェックポイントからのリカバリに使用できるファイルよりも古いファイルがある場合、WiredTigerはそれらを自動的に削除します。

事前割り当て

mongodプロセスが、新しいファイルを作成するよりもジャーナルファイルを事前に割り当てる方が効率的であると判断した場合、ジャーナルファイルをWiredTigerストレージエンジンで事前に割り当てることができます。

インメモリストレージエンジンでのジャーナルの仕組み

インメモリストレージエンジンは、MongoDB Enterpriseバージョン3.2.6以降の一般提供（GA）の一部として記述されていました。このストレージエンジンでは、データがメモリに保持されるため、個別のジャーナル技術はありません。書き込みに関係のある書き込み操作（j：true）がある場合は、すぐに確認されます。

メモリ内ストレージエンジンを使用して投票メンバーが設定されたレプリカの場合、writeConcernMajorityJournalDefaultをfalseに設定する必要があります。それ以外の場合、これがtrueに設定されていると、レプリカセットは起動警告をログに記録します。

このオプションがfalseに設定されている場合、データベースは、書き込みを確認する前に、w：「大部分」の書き込みがディスク上のジャーナルに書き込まれるのを待機しません。このアプローチの欠点は、大多数の書き込み操作では、特定のレプリカセット内の大多数のノードの一時的な損失（再起動やクラッシュなど）が発生した場合にロールバックする可能性があることです。

MMapv1ストレージエンジンを使用している場合、mongodの起動時に--nopreallocationオプションを使用してジャーナルの事前割り当てを無効にできます。

WiredTigerストレージエンジンでは、MongoDBバージョン4.0以降では、WiredTigerストレージエンジンを使用するレプリカセットメンバーに対して--nojournalオプションまたはstorage.journal.enabled：falseを指定することはできません。

ジャーナリングの管理ジャーナリングの無効化

ジャーナルはスタンドアロン展開でのみ無効にでき、実稼働システムでは推奨されません。 MongoDBバージョン4.0以降では、WiredTigerストレージエンジンを使用するレプリカセットメンバーが関与している場合、-nojournalオプションもstorage.journal.enabled：falseも指定できません。

ジャーナリングを無効にするには、-nojournalコマンドラインオプションを使用してmongodを起動します。

ジャーナルステータスの監視

ジャーナルの統計を取得するには、wiredTiger.logを返すコマンドdb.serverStatus（）を使用します。

コミット確認を取得する

コミット確認を取得するために、jオプションを使用した書き込み懸念を使用します。 {j：true}。この場合、ジャーナリングを有効にする必要があります。有効にしないと、mongodインスタンスでエラーが発生する可能性があります。

ジャーナリングが有効になっている場合、w：「大部分」これはj：trueを意味する場合があります。

レプリカセットの場合、j：trueの場合、セットアップでは、w：書き込みの懸念に関係なく、プライマリのみがジャーナルに書き込む必要があります。

ただし、レプリカセットにj：trueが設定されている場合でも、レプリカセットのプライマリフェイルオーバーが原因でロールバックが発生する可能性があります。

予期しないシャットダウンデータの回復

サーバーが検出される前にMongoDBがクラッシュから再起動するたびに、ジャーナルディレクトリ内のすべてのジャーナルファイルが再生されます。この操作はログ出力に記録されるため、-repairを実行する必要はありません。

WiredTigerJournalCompressorの変更

Snappyコンプレッサーは、ジャーナルのデフォルトの圧縮アルゴリズムです。ただし、mongodインスタンスの設定に応じてこれを変更できます。

スタンドアロンのmongodインスタンスの場合：

storage.wiredTiger.engineConfig.journalCompressorを新しい値に設定して、更新します。これを行う最も適切な方法は、構成ファイルを使用することですが、コマンドラインオプションを使用する場合は、再起動時に--wiredTigerJournalCompressorコマンドラインオプションを更新する必要があります。
インスタンスのmongoシェルに接続してmongodインスタンスをシャットダウンし、次のコマンドを発行します：db.shutdownServer（）またはdb.getSiblingDB（'admin ）.shutdownServer（）
mongodインスタンスを再起動します：
1. 構成ファイルを使用する場合は、mongod-f
2. コマンドラインオプションを使用する場合は、wiredTigerJournalCompressorを更新します。
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

レプリカセットメンバーの場合：

mongodインスタンスをシャットダウンします：db.shutdownServer（）またはdb.getSiblingDB（‘admin）.shutdownServer（）
構成ファイルに次の変更を加えます。
1. storage.journal.enabledをfalseに設定します。
2. レプリケーション設定をコメントします
3. パラメーターdisableLogicalSessionCacheRefreshをtrueに設定します。

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

mongodインスタンスを再起動します：
1. 構成ファイルを使用する場合は、mongod-f
  を使用します。
2. コマンドラインオプションを使用する場合：--nojournalオプションを含め、レプリケーションコマンドラインオプションをすべて削除しますつまり、-replSetを設定し、パラメータdisableLogicalSessionCacheRefreshをtrueに設定します
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

mongodインスタンスをシャットダウンします：

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

構成ファイルを更新して、新しいジャーナルコンプレッサーでレプリカセットメンバーを再起動できるようにします。ストレージを削除します。 journal.enabled、デプロイメントのレプリケーション設定のコメントを解除し、disableLogicalSessionCacheRefreshオプションを削除し、最後にstorage.wiredTiger.engineConfig.journalCompressorを削除します。

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

mongodインスタンスをレプリカセットメンバーとして再起動します

構成ファイルを使用する場合は、mongod-f
コマンドラインオプションを使用する場合：--nojournalおよび--wiredTigerJournalCompressorオプションを削除します。レプリケーションコマンドラインオプションを含め、disableLogicalSessionCacheRefreshパラメーターを削除します。

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

結論

MongoDBが書き込み操作の耐久性を保証するために、ジャーナリングが使用され、データがディスク上に先に書き込まれますロギング。 WiredTigerストレージエンジン（最も推奨されます）が最後のチェックポイントを介してデータを回復できる限り、MongoDBが予期せず終了し、ジャーナル処理が有効になっていない場合、そのようなデータの回復は不可能になります。それ以外の場合、ジャーナリングが有効になっていると、MongoDBは再起動時に書き込み操作を再適用し、一貫した状態を維持できます。