がどのようにここでのMongoDBジャーナリング作業

Question

が私の見解ではない、と私はそれが正しいか間違っているかどうかわからないです：

ジャーナリングログは、ログ「やり直し」です。データファイルの変更を記録します。

たとえば、あるレコードのフィールド値を 'a'から 'b'に変更したい場合、mongodbはdbfileの変更方法（すべての名前空間、データ、インデックスなどを含む）を探します。 mongodbはその変更をジャーナルに書き出します。

その後、mongodbはdbfileのすべての実際の変更を行います。ここで何か問題が起きた場合、mongoDBが再起動するとジャーナル（存在する場合）を読み込みます。次に、dbfileを変更して、データセットを一貫性のあるものにします。

したがって、ジャーナルでは、変更するデータは記録されず、代わりにdbfileの変更方法が示されます。

私は正しいですか？ジャーナルのフォーマットについての詳しい情報はどこで入手できますか？

Answer 1

EDIT：DwightのMongoSFでの2011プレゼンテーションへの私のオリジナルのリンクは、現在死んでいますが、同様の内容のBen Beckerの2012 presentationがあります。

元のMMAPストレージエンジンのジャーナルがどのように機能したかを簡単にまとめておきますが、pluggable storage engineモデル（MongoDB 3.0と後で）、これは完全にあなたが使用しているストレージエンジン（および潜在的にオプション）に依存するので、確認してください。

元の（MMAP）ストレージエンジンジャーナルに戻る。非常に初歩的なレベルでは、ジャーナルは一連のキューに入れられた操作を含み、すべての操作が発生したときにそれに書き込まれます。

これらの操作が適用され、ディスクにフラッシュされると、それらはジャーナルに必要なくなり、エージングアウトされる可能性があります。この意味で、ジャーナルは基本的に書き込み操作用の循環バッファーのように機能します。

内部的には、ジャーナルの操作は、書き込み操作の論理グループである「コミットグループ」に格納されます。操作が完全コミットグループに入ると、その操作はジャーナルの一部としてディスクに同期されているとみなされます（たとえば、書き込みの問題はj:trueとなります）。汚れたシャットダウン後に、mongodは、以前にフラッシュされていない完全なコミットグループをディスクに適用しようとします。コミットされていないコミットグループは破棄されます。

oplogで表示される操作ではなく、より単純なファイル、オフセット（ディスクの場所）、およびその場所に書き込まれるデータです。これにより、データの効率的な再生とジャーナルのコンパクトなフォーマットが可能になりますが、コンテンツはほとんどがぎこちないように見えます（上記のoplogは基本的にJSON文書として読み込み可能です）。これは、基本的に、データベースファイルの内容とそれに対する変更を意識することなく、より簡単です。基本的には、ディスクの場所Xに移動してデータYを書き込むことだけを知っています。それでおしまい。

ジャーナルの先行順性は、回転ディスク上にうまく収まることを意味し、シーケンシャルアクセスパターンは、通常、MMAPデータアクセスパターン（他のエンジンのアクセスパターンである必要はない） 。したがって、IOの競合を減らすために、ジャーナルを独自のディスクまたはパーティションに配置することをお勧めします。