MongoDB uses write ahead logging to an on-disk journal to guarantee write operation durability and to provide crash resiliency. Before applying a change to the data files, MongoDB writes the change operation to the journal. If MongoDB should terminate or encounter an error before it can write the changes from the journal to the data files, MongoDB can re-apply the write operation and maintain a consistent state.
Disk has mongo data files and mongo journal files. When we start up mongod, it maps your data files to a shared view. Operating system map the mongo data files to memory address.
This memory is still backed by the file. If we make changes in memory, the operating system will flush these changes to the underlying file. This is basically how mongod works without journaling.
It asks the operating system to flush in-memory changes after fixed interval of time. However, with journaling, mongod creates a second mapping, called private view. This also increases the amount of memory mongodb uses. This private view is not connected to the mongo data file, so the operating system cannot flush any changes from the private view to disk. During write operations mongod writes to the private view.
mongod will then write this change to the journal file, creating a little description of which bytes in which file changed.
At this point if mongodb crashes, the journal can replay the changes to the shared view, which is connected to the mongo data files.
Finally the shared view data will be flushed to disk. The last step is that mongod remaps the shared view to the private view.
This way journaling of mongodb works.