これが私の見解であり、それが正しいか間違っているかはわかりません。
ジャーナリング ログは「やり直し」ログです。データファイルの変更を記録します。
たとえば、1 つのレコードのフィールド値を 'a' から 'b' に変更したい場合、mongodb は dbfile を変更する方法 (すべての名前空間、データ、インデックスなどを含む) を見つけてから、mongodb は次のように書き込みます。ジャーナルの修正。
その後、mongodb は dbfile に対するすべての実際の変更を行います。ここで何か問題が発生した場合、mongoDB の再起動時にジャーナルが読み取られます (存在する場合)。次に、dbfile を変更して、データ セットの一貫性を保ちます。
そのため、ジャーナルには、変更するデータは記録されませんが、代わりに dbfile を変更する方法が記録されます。
私は正しいですか？ジャーナルのフォーマットに関する詳しい情報はどこで入手できますか?
編集: Dwight による 2011 年の MongoSF でのプレゼンテーションへの元のリンクは現在無効になっていますが、同様の内容の Ben Becker による2012 年のプレゼンテーションがあります。
ある時点でそれが機能しなくなった場合に備えて、元の MMAP ストレージ エンジンのジャーナルがどのように機能したかを簡単に要約しますが、プラグ可能なストレージ エンジンモデル (MongoDB 3.0 以降)の出現に注意する必要があります。 、これは現在、使用しているストレージ エンジン (および場合によってはオプション) に完全に依存するため、確認してください。
元の (MMAP) ストレージ エンジン ジャーナルに戻ります。非常に初歩的なレベルでは、ジャーナルには一連のキュー操作が含まれており、すべての操作は発生時に書き込まれます。基本的には、ディスクへの追加のみの順次書き込みです。
これらの操作が適用されてディスクにフラッシュされると、それらはジャーナルで不要になり、エージング アウトできます。この意味で、ジャーナルは基本的に、書き込み操作用の循環バッファーのように機能します。
内部的には、ジャーナル内の操作は「コミット グループ」 (書き込み操作の論理グループ) に格納されます。操作が完全なコミット グループに含まれると、ジャーナルの一部としてディスクに同期されたと見なすことができます (j:trueたとえば、書き込みの問題を満たします)。クリーンでないシャットダウンの後、mongod以前にディスクにフラッシュされていないすべての完全なコミット グループを適用しようとし、不完全なコミット グループは破棄されます。
ジャーナル内の操作は、oplogに表示されるものではなく、より単純なファイル、オフセット (基本的にディスクの場所)、およびその場所に書き込まれるデータのセットです。これにより、データの効率的な再生が可能になり、ジャーナルのコンパクトなフォーマットが可能になりますが、ほとんどの場合、内容が意味不明に見えます (基本的に JSON ドキュメントとして読み取り可能な前述の oplog とは対照的に)。これは基本的に、提示された質問の 1 つに答えます。データベース ファイルの内容とそれに加えられる変更を認識していません。さらに単純です。基本的には、ディスクの場所 X に移動してデータ Y を書き込むことしか認識していません。それでおしまい。
ジャーナルの先行書き込みシーケンシャルな性質は、回転するディスクにうまく適合し、シーケンシャル アクセス パターンは通常、MMAP データ アクセス パターンと矛盾することを意味します (必ずしも他のエンジンのアクセス パターンとは限りません)。したがって、IO の競合を減らすために、ジャーナルを独自のディスクまたはパーティションに配置することをお勧めします。