Journaling日记
On this page本页内容
To provide durability in the event of a failure, MongoDB uses write ahead logging to on-disk journal files.为了在发生故障时提供持久性，MongoDB使用写前日志记录磁盘上的日志文件。
Journaling and the WiredTiger Storage Engine日志和WiredTiger存储引擎
The log mentioned in this section refers to the WiredTiger write-ahead log (i.e. the journal) and not the MongoDB log file.本节中提到的日志指的是WiredTiger预写日志（即日志），而不是MongoDB日志文件。
WiredTiger uses checkpoints to provide a consistent view of data on disk and allow MongoDB to recover from the last checkpoint. 使用检查点来提供磁盘上数据的一致视图，并允许MongoDB从上一个检查点恢复。However, if MongoDB exits unexpectedly in between checkpoints, journaling is required to recover information that occurred after the last checkpoint.但是，如果MongoDB在检查点之间意外退出，则需要日志记录来恢复上一个检查点之后发生的信息。
Starting in MongoDB 6.1, journaling is always enabled. 从MongoDB 6.1开始，日志记录一直处于启用状态。As a result, MongoDB removes the 因此，MongoDB删除了storage.journal.enabled option and the corresponding --journal and --nojournal command-line options.storage.journal.enabled选项以及相应的--journal和--nojournal命令行选项。
With journaling, the recovery process:使用日志记录，恢复过程：
Looks in the data files to find the identifier of the last checkpoint.在数据文件中查找最后一个检查点的标识符。Searches in the journal files for the record that matches the identifier of the last checkpoint.在日志文件中搜索与上一个检查点的标识符匹配的记录。Apply the operations in the journal files since the last checkpoint.在日志文件中应用自上次检查点以来的操作。
Journaling Process日志记录过程
Changed in version 3.2.3.2版更改。
With journaling, WiredTiger creates one journal record for each client initiated write operation. 通过日志记录，WiredTiger为每个客户端启动的写入操作创建一个日志记录。The journal record includes any internal write operations caused by the initial write. 日记账记录包括由初始写入引起的任何内部写入操作。For example, an update to a document in a collection may result in modifications to the indexes; WiredTiger creates a single journal record that includes both the update operation and its associated index modifications.例如，对集合中文档的更新可能会导致对索引的修改；WiredTiger创建一个包含更新操作及其相关索引修改的日志记录。
MongoDB configures WiredTiger to use in-memory buffering for storing the journal records. Threads coordinate to allocate and copy into their portion of the buffer. All journal records up to 128 kB are buffered.MongoDB将WiredTiger配置为使用内存缓冲来存储日志记录。线程进行协调以分配并复制到缓冲区的相应部分中。缓冲所有高达128 kB的日志记录。
WiredTiger syncs the buffered journal records to disk upon any of the following conditions:WiredTiger在以下任何一种情况下都会将缓冲的日志记录同步到磁盘：
For replica set members (primary and secondary members),对于副本集成员（主要和次要成员），If there are operations waiting for oplog entries. Operations that can wait for oplog entries include:如果有操作正在等待oplog条目。可以等待oplog条目的操作包括：forward scanning queries against the oplog针对oplog的前向扫描查询read operations performed as part of causally consistent sessions作为因果一致会话的一部分执行的读取操作
Additionally for secondary members, after every batch application of the oplog entries.此外，对于辅助成员，在每次批量应用oplog条目之后。
If a write operation includes or implies a write concern of如果写入操作包含或暗示j: true.j: true的写入关注。NoteWrite concern如果"majority"impliesj: trueif thewriteConcernMajorityJournalDefaultis true.writeConcernMajorityJournalDefault为true，则写关注"majority"表示j:true。At every 100 milliseconds (See每100毫秒（请参阅storage.journal.commitIntervalMs).storage.journal.commitIntervalMs）。When WiredTiger creates a new journal file. Because MongoDB uses a journal file size limit of 100 MB, WiredTiger creates a new journal file approximately every 100 MB of data.WiredTiger创建新的日志文件时。由于MongoDB使用100MB的日志文件大小限制，WiredTiger大约每100MB的数据就会创建一个新的日志文件。
In between write operations, while the journal records remain in the WiredTiger buffers, updates can be lost following a hard shutdown of 在写入操作之间，当日志记录保留在WiredTiger缓冲区中时，mongod.mongod硬关闭后可能会丢失更新。
See also: 另请参阅：
The serverStatus command returns information on the WiredTiger journal statistics in the wiredTiger.log field.serverStatus命令在wiredTiger.log字段中返回有关WiredTiger日志统计信息。
Journal Files日志文件
For the journal files, MongoDB creates a subdirectory named 对于日志文件，MongoDB在journal under the dbPath directory. dbPath目录下创建了一个名为journal的子目录。WiredTiger journal files have names with the following format WiredTiger日志文件的名称采用以下格式WiredTigerLog.<sequence> where <sequence> is a zero-padded number starting from 0000000001.WiredTigerLog.<sequence>，其中<sequence>是一个从0000000001开始的零填充数字。
Journal Records日记账记录
Journal files contain a record per each client initiated write operation日志文件包含每个客户端启动的写入操作的记录
The journal record includes any internal write operations caused by the initial write.日记账记录包括由初始写入引起的任何内部写入操作。For example, an update to a document in a collection may result in modifications to the indexes; WiredTiger creates a single journal record that includes both the update operation and its associated index modifications.例如，对集合中文档的更新可能会导致对索引的修改；WiredTiger创建一个包含更新操作及其相关索引修改的日志记录。Each record has a unique identifier.每个记录都有一个唯一的标识符。The minimum journal record size for WiredTiger is 128 bytes.WiredTiger的最小日志记录大小为128字节。
Compression压缩
By default, MongoDB configures WiredTiger to use snappy compression for its journaling data. 默认情况下，MongoDB将WiredTiger配置为对其日志数据使用快速压缩。To specify a different compression algorithm or no compression, use the 要指定不同的压缩算法或不指定压缩，请使用storage.wiredTiger.engineConfig.journalCompressor setting. storage.wiredTiger.engineConfig.journalCompressor设置。For details, see Change WiredTiger Journal Compressor.有关详细信息，请参阅更改WiredTiger日志压缩器。
If a log record less than or equal to 128 bytes (the mininum log record size for WiredTiger), WiredTiger does not compress that record.如果日志记录小于或等于128字节（WiredTiger的最小日志记录大小），WiredTige不会压缩该记录。
Journal File Size Limit日志文件大小限制
WiredTiger journal files for MongoDB have a maximum size limit of approximately 100 MB.MongoDB的WiredTiger日志文件的最大大小限制约为100MB。
Once the file exceeds that limit, WiredTiger creates a new journal file.一旦文件超过该限制，WiredTiger就会创建一个新的日志文件。WiredTiger automatically removes old journal files to maintain only the files needed to recover from last checkpoint.WiredTiger会自动删除旧的日志文件，只保留从上一个检查点恢复所需的文件。
Pre-Allocation预分配
WiredTiger pre-allocates journal files.WiredTiger预先分配日志文件。
Journaling and the In-Memory Storage Engine日志和内存存储引擎
Starting in MongoDB Enterprise version 3.2.6, the In-Memory Storage Engine is part of general availability (GA). 从MongoDB Enterprise 3.2.6版本开始，内存存储引擎是通用性（GA）的一部分。Because its data is kept in memory, there is no separate journal. 因为它的数据保存在内存中，所以没有单独的日志。Write operations with a write concern of 写入关注为j: true are immediately acknowledged.j: true的写入操作会立即得到确认。
If any voting member of a replica set uses the in-memory storage engine, you must set 如果副本集的任何投票成员使用内存存储引擎，则必须将writeConcernMajorityJournalDefault to false.writeConcernMajorityJournalDefault设置为false。
Starting in version 4.2 (and 4.0.13 and 3.6.14 ), if a replica set member uses the in-memory storage engine (voting or non-voting) but the replica set has 从版本4.2（以及4.0.13和3.6.14）开始，如果副本集成员使用内存存储引擎（投票或非投票），但副本集的writeConcernMajorityJournalDefault set to true, the replica set member logs a startup warning.writeConcernMajorityJournalDefault设置为true，则副本集成员会记录启动警告。
With 在writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. writeConcernMajorityJournalDefault设置为false的情况下，MongoDB不会等待w: "majority"写入到磁盘日志中，然后再确认写入。As such, 因此，在给定副本集中的大多数节点发生瞬时丢失（例如崩溃和重新启动）的情况下，"majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set."majority"写入操作可能会回滚。