Journaling

based on v. 39 (2011/05/04 追従) - オリジナル

MongoDB v1.7.5+ より journaling 機能がサポートされました。これはオペレーションの journal への先行書き込みによって、容易で素早いリカバリーとストレージエンジンの durability を実現します。

ジャーナルとは、ファイルシステムに対して行われる変更を循環バッファーに記録する特殊なファイルのことです。ジャーナルは定期的にファイルシステムにコミット (フラッシュ) されます。そのためクラッシュが発生した場合には、ジャーナルをチェックポイントとして使用して、未保存の情報を回復し、ファイルシステムのメタデータの破損を回避することができます。

有効化

journaling を有効にするには mongod 起動時に --journal コマンドラインオプションを付与します。

# mongod --journal 

この際にMongoDB journal ファイルを再配置するか、必要に応じて作成するかの速い方を選択します。もし Mongo DB がファイルの再配置を決定すると、このプロセスが完了するまでの数分の間は port 27017 に listen できない状態になります。これはあなたのアプリケーションやシェルが journal 有効化後の初期スタートにおいて接続可能になるまで待ち時間があることを意味します。

MongoDB が再配置のためにビジー状態であるかどうかをログで確認しましょう。完了時には "waiting for connections on port whatever" と表示されるようになります。

無効化

もし journaling が有効化されている状態ならば、無効化は (1) mongod をシャットダウンして (2) --journal オプション無しに再起動することによって行います。

Journal ファイル

--journal 有効化によって、journal ファイルが db path 内の journal/ サブディレクトリ下に作成されます。これらのファイルは先行書き込み redo ログです。加えて数字の連番が最新のファイル(lsn: last sequence number)、 journal/lsn, が作成されます。そしてクリーンシャットダウン時には journal/ 以下のファイルは全て削除されます。

Mongo データファイル (database.ns, database.0, database.1, ...) と同じフォーマットになっていますので、MongoDBのバージョンアップグレードプロセスも、ロールバックプロセスもシームレスです。(v.1.7.5 以前へロールバックをする場合は mongod をまずシャットダウンをして手動で journal/ サブディレクトリを削除してから再起動する事を忘れないで下さい。 )

リカバリー

クラッシュ時には journal/ 内の journal ファイルは消去されずに残っています。クラッシュ後の再起動ではこれらのファイルによって、サーバーのクラッシュ以前に反映されていなかったオペレーション（journal ログの内容）が、ユーザの接続以前に実行されます。以前のように repair を実行はありません。

journal サブディレクトリ

もしできるなら、mongod プロセスを起動する前に、 journal/ ディレクトリをシンボリックリンクにしておきます。
You may wish, before starting mongod to symlink the journal/ directory to a dedicated hard drive to speed the frequent (fsynced) sequential writes which occur to the current journal file.

Group Commits

--journal オプションを使用した場合、MongoDB は group commits (バッチコミット) を使用します。これはまとまった時間ごとに、その期間の一連のオペレーションを一度にコミットする（journal バッファから journal ファイル[ログ] に書き込む）仕組みです。これによって高いパフォーマンスを達成しています。v1.8.0 では 約100ms ごとに group commits が実行されるようになっています、このインターバルは今後より短くなっていく予定です。

( journaling有効環境におけるデータが実際にDBに書き込まれる時間) = ( 100msごとの journal ファイルへのログ書き込み時間) + ( fsync の時間: i.e. メモリから ディスクへデータが書き込み時間 )

Commit Acknowledgement

group commit からの返答シグナル(Acknoulegement)はgetLastError コマンドが返ってくるまで待つことになります。 --journal オプションで起動している場合、 fsync:true オプションはデータが物理的に journal に書き込まれた後に返します（全てのデータファイルの fsync が完了したときでは無いことに注意して下さい）。
group commit のインターバルも考慮に入れていることに注意して下さい。 fsync 無しに getLastError を call したいと思うかもしれません。また、レプリケーションでは w: パラメータと一緒に call したいかもしれません。後リリース予定の v1.8.0 では commit acknowledgement の遅延は少なくなるはずです。

FAQ

レプリケーションを行っている場合、全てのメンバーが --journal オプションを使えるのでしょうか？

はい、使えます。

性能はどのくらいでしょうか？

読込み性能は変わりません。ただし、書込み性能は nou-durable バージョンに比べて journal ファイルへの書込みが行われる分、若干悪くなります。--journal 有/無で長期実行した場合のの性能比較で大きな際が出た場合は知らせて下さい。チューニングを行います。加えて、いくらかの性能チューニングはすでに v.1.8.1+ で行われています。

journaling 機能を 安全な hot バックアップを行うために使えるのでしょうか？

いいえ、まだ使えません。journal ファイルはデータファイル内の全てのデータが安全になった後に削除されてしまうからです。

32 bit では問題がありますか？

--journal オプション下では、特別なメモリーマップファイルの活動がありますので、32 bit ビルド環境における制限されたデータベースサイズでは多くの制約を受けることになります。故に --journal は 64 bit システムで使用することを推奨します。

なぜ --journal をデフォルトにしないのですか？

新しいコード部分であるため、保守的な立場から現在はデフォルトにしていません。将来のある時点でデフォルトにすることを検討しています。

いつ --dur オプションから --journal オプションに替わったのでしょうか？

v.1.8 において --journal にリネームされました。現在も古い名前である --dur も同じ意味で認識されますが、新しい名前に変更するようにして下さい。

replication と journaling が両方機能していた場合、マスターサーバーには何回のディスク書き込みが発生するのですか？

v 1.8 の insert では4回の書き込みが発生します。オブジェクトがメインコレクションに書き込まれて1回、Replication のための oplog コレクションに書き込まれて1回、そしてこの2ステップが journal ファイル( /data/db/journal )内でシングルミニトランザクション として journaling されるので、合計4回になります。

There is an open item in to reduce this by having the journal be compressed. This will reduce from 4x to probably ~2.5x.

上述の例は最悪シナリオの場合になります。index アップデートは index コレクションと journal には書き込まれますが、oplog には書き込まれないので2回だけで済みます。同じように $set, $addToSet, $inc のようなアップデートはログは一定期間の一連の処理をまとめて記録されるために一般的に1回辺りの書き込み回数は小さくなります。

See Also

• Journaling Administration Notes
• Recorded Webinar on Journaling
• Durability Internals