这是我的观点，我不确定是对还是错：
日志日志是"重做"日志。它记录数据文件的修改。
例如，我想将一条记录的字段值从"a"更改为"b"，然后mongodb将找到如何修改dbfile（包括所有命名空间，数据，索引等），然后mongodb将修改写入日志。
之后，mongodb 对 dbfile 进行所有真正的修改。如果这里出现问题，当mongoDB重新启动时，它将读取日志（如果存在）。然后，它将更改更改数据库文件以使数据集保持一致。
因此，在日志中，不记录要更改的数据，而是记录如何更改数据库文件。
我说得对吗？我在哪里可以获得有关期刊格式的更多信息？
编辑：我2011年由德怀特在MongoSF上的演讲的原始链接现在已经死了，但本·贝克尔（Ben Becker）在2012年的演讲中也有类似的内容。
以防万一在某个时候也停止工作，我将快速总结原始 MMAP 存储引擎中的日志是如何工作的，但应该注意的是，随着可插拔存储引擎模型（MongoDB 3.0 及更高版本）的出现，这现在完全取决于您正在使用的存储引擎（以及潜在的选项） - 所以请检查。
返回到原始 （MMAP） 存储引擎日志。 在非常基本的层面上，日志包含一系列排队操作，并且所有操作都在发生时写入其中 - 基本上是仅追加顺序写入磁盘。
一旦应用了这些操作并将其刷新到磁盘，日志中就不再需要它们，并且可以老化。 从这个意义上说，日志基本上就像是写入操作的循环缓冲区。
在内部，日志中的操作存储在"提交组"中 - 写入操作的逻辑组。 一旦操作位于完整的提交组中，就可以将其视为作为日志的一部分同步到磁盘（例如，将满足j:true写入问题）。 在不干净关闭后，mongod将尝试应用以前未刷新到磁盘的所有完整提交组，不完整的提交组将被丢弃。
日志中的操作不是您将在oplog中看到的，而是一组更简单的文件，偏移量（本质上是磁盘位置）和要在该位置写入的数据。 这允许有效地重放数据，并为日志提供紧凑的格式，但会使内容对大多数人来说看起来像胡言乱语（与前面提到的oplog相反，它基本上可以作为JSON文档读取）。 这基本上回答了提出的问题之一 - 它对数据库文件的内容和要对其进行的更改没有任何意识，它更简单 - 它基本上只知道去磁盘位置 X 并写入数据 Y，仅此而已。
日志的预写顺序性质意味着它非常适合旋转磁盘，并且顺序访问模式通常与 MMAP 数据访问模式不一致（尽管不一定是其他引擎的访问模式）。 因此，有时最好将日志放在其自己的磁盘或分区上以减少 IO 争用。