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