MongoDB v1.7.5+ supports write-ahead journaling of operations to facilitate fast crash recovery and durability in the storage engine. Disabling/EnablingIn version 1.9.2+, journaling is enabled by default for 64-bit platforms. You can disable journaling with the mongod --nojournal command line option. For versions < 1.9.2 or 32-bit platforms, you can enable journaling with the --journal command line option. It is OK to disable journaling after running with journaling by simply shutting down mongod cleanly and restarting with --nojournal. The reverse is also OK; shutdown cleanly and restart without --nojournal. MongoDB may determine that it is faster to preallocate journal files than to create them as needed. If MongoDB decides to preallocate the files, it will not start listening on port 27017 until this process completes, which can take a few minutes. This means that your applications and the shell will not be able to connect to the database immediately on initial startup. Check the logs to see if MongoDB is busy preallocating. It will print the standard "waiting for connections on port whatever" when it has finished. Journal FilesWith journaling enabled, journal files will be created in a journal/ subdirectory under your chosen db path. These files are write-ahead redo logs. In addition, a last sequence number file, journal/lsn, will be created. A clean shutdown removes all files under journal/. The Mongo data files (database.ns, database.0, database.1, ...) have the same format as in previous releases. Thus, the upgrade process is seamless, and a rollback would be seamless too. (If you roll back to a pre v1.7.5 release, try to shut down cleanly first. Regardless, remove the journal/ directory before starting the pre v1.7.5 version of mongod.) RecoveryOn a restart after a crash, journal files in journal/ will be replayed before the server goes online. This will be indicated in the log output. You do not need to run a repair. The journal SubdirectoryYou may wish, before starting mongod to symlink the journal/ directory to a dedicated hard drive to speed the frequent (fsynced) sequential writes which occur to the current journal file. Group CommitsMongoDB performs group commits (batch commits) when journaling. This means that a series of operations over many milliseconds are committed all at once. This is done to achieve high performance. Group commits are performed approximately every 100ms by default. In version 1.9.2+, you can set this interval yourself using the --journalCommitInterval command line option. The allowed range is 2 to 300 milliseconds. Commit AcknowledgementYou can wait for group commit acknowledgement with the getLastError Command. In versions before 1.9.0 using getLastError + fsync would do this, in newer versions the "j" option has been specifically created for this purpose. In version 1.9.2+ the group commit delay is shortened when a commit acknowledgement (getLastError + j) is pending; this can be as little as 1/3 of the normal group commit interval. FAQIf I am using replication, can some members use journaling and others not?Yes. How's performance?Read performance should be the same. Write performance should be very good but there is some overhead over the non-durable version as the journal files must be written. If you find a case where there is a large difference in performance between running with and without journaling, please let us know so we can tune it. Additionally, some performance tuning enhancements in this area are already queued for v1.8.1+. Can I use the journaling feature to perform safe hot backups?Yes, see Backups with Journaling Enabled. 32 bit nuances?There is extra memory mapped file activity with journaling. This will further constrain the limited db size of 32 bit builds. Thus, for now journaling by default is disabled on 32 bit systems. When did the --journal option change from --dur?In 1.8 the option was renamed to --journal, but the old name is still accepted for backwards compatibility; please change to --journal if you are using the old option. Will the journal replay have problems if entries are incomplete (like the failure happened in the middle of one)?Each journal (group) write is consistent and won't be replayed during recovery unless it is complete. How many times is data written to disk when replication and journaling are both on?In v1.8, for an insert, four times. The object is written to the main collection, and also the oplog collection (so that is twice). Both of those writes are journaled as a single mini-transaction in the journal file (the files in /data/db/journal). Thus 4 times total. There is an open item in to reduce this by having the journal be compressed. This will reduce from 4x to probably ~2.5x. The above applies to collection data and inserts which is the worst case scenario. Index updates are written to the index and the journal, but not the oplog, so they should be 2X today not 4X. Likewise updates with things like $set, $addToSet, $inc, etc. are compactly logged all around so those are generally small. See Also |
PLEASE POST QUESTIONS IN THE USER GROUPS FORUM. Post non-question comments and helpful hints here.
blog comments powered by Disqus