这是我的看法，不知道是对是错:
日记日志是“重做”日志。它记录数据文件的修改。
例如我想将一条记录的字段值从'a'改为'b'，那么mongodb会找到如何修改dbfile(包括所有的命名空间、数据、索引等)，然后mongodb 将修改写入日志。
之后，mongodb 对 dbfile 进行所有真正的修改。如果这里出现问题，当 mongoDB 重新启动时，它将读取日志(如果存在)。然后它会改变 dbfile 以使数据集保持一致。
所以，在日志中，不记录要更改的数据，而是记录如何更改dbfile。
我说的对吗？我在哪里可以获得有关期刊格式的更多信息？
最佳答案
编辑:我在 2011 年由 Dwight 在 MongoSF 上发表的演讲的原始链接现已失效，但有一个 2012 presentation由 Ben Becker 撰写，内容相似。
以防万一它在某个时候也停止工作，我将简要概述原始 MMAP 存储引擎中的日志是如何工作的，但应该注意的是，随着 pluggable storage engine 的出现模型(MongoDB 3.0 及更高版本)，这现在完全取决于您使用的存储引擎(可能还有选项) - 所以请检查。
返回原始 (MMAP) 存储引擎日志。在非常基本的级别上，日志包含一系列排队操作，并且所有操作都在发生时写入其中 - 基本上是仅追加到磁盘的顺序写入。
一旦应用了这些操作并将其刷新到磁盘，日志中就不再需要它们并且可以过期。从这个意义上说，日志基本上就像一个用于写操作的循环缓冲区。
在内部，日志中的操作存储在“提交组”中——一组写操作的逻辑组。一旦一个操作在一个完整的提交组中，它可以被认为是作为日志的一部分同步到磁盘(例如，将满足 j:true 写入问题)。非正常关闭后，mongod 将尝试应用之前未刷新到磁盘的所有完整提交组，不完整的提交组将被丢弃。
日志中的操作与您将在 oplog 中看到的不同。 ，而是一组更简单的文件、偏移量(本质上是磁盘位置)和要在该位置写入的数据。这允许有效地重放数据，并为日志提供紧凑的格式，但会使内容看起来像大多数人的胡言乱语(与上述基本上可以作为 JSON 文档读取的 oplog 相反)。这基本上回答了提出的问题之一——它不知道数据库文件的内容和要对其进行的更改，它甚至更简单——它基本上只知道去磁盘位置 X 并写入数据 Y，就是这样。
日志的预写、顺序性质意味着它非常适合旋转磁盘，顺序访问模式通常与 MMAP 数据访问模式不一致(尽管不一定与其他引擎的访问模式)。因此，有时将日志放在自己的磁盘或分区上以减少 IO 争用是个好主意。
关于mongodb - MongoDB 日志是如何工作的，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10172188/