MongoDB uses an on-disk journal to guarantee write operations and provide crash resiliency. MongoDB also creates a journal for every write that includes the exact disk location and the bytes that changed in the write. Thus, if you have a crash in the server, the journal can be used to replay any writes that have not yet been written to the data files.
MongoDB uses memory mapped files to write your data to disk. By default, MongoDB data files are flushed to disk every 60 seconds. They also uses memory mapped files for the journal, and by default, the journal is flushed to disk every 100ms. Since the final data files are flushed to disk every 60 seconds, the journal does not need to track writes for more than one minute. For more details on the mechanics of the journaling, refer to the official documentation. To understand how the view mapping works in more detail, you can check out Kristina’s blog.
Journaling Write Concern
>db.data.insert({"name":"testentry"});
>db.runCommand({"getLastError":1, "j":true});
When you turn on MongoDB journaling, you also have the ability to specify a write concern in MongoDB of ‘Journaled’ for your MongoDB operations. This implies that MongoDB confirms the write operation only after committing to the journal. However, this has a drawback – when you specify “j”:true with getLastError, MongoDB will wait for about 1/3 of the journal commit internal before committing the journal data. The default journal commit interval is 100ms – so MongoDB will wait 30ms and commit the data. This essentially means that on a single thread, you can only get about 33.3 writes/second, and the recommended best practice is to batch your writes. For example, if you have 50 writes, use the “j”:true setting only on the last write – this will acknowledge that all the previous 50 writes are done.
Summary
Every production MongoDB instance should run with journaling enabled. If you don’t have journaling enabled and your server or MongoDB process crashes, MongoDB will not be able to ensure data integrity. You’ll need to run a “repair” operation on the database, which, depending on the amount of data, could take a few hours to complete. Turn it off only if you really know what you’re doing. At ScaleGrid, all our instances follow the MongoDB best practice configuration and have journaling turned on by default.
