Database Reference
In-Depth Information
each data file to virtual memory. This means that when MongoDB writes, it writes to a
virtual memory address and not directly to disk. The
OS
kernel periodically syncs
these writes from virtual memory to disk, but the frequency and completeness of these
kernel syncs are indeterminate. So MongoDB forcibly syncs all data files every 60 sec-
onds using the
fsync
system call. The problem here is that if the MongoDB process is
killed with unsynced writes, there's no way of knowing what state the data files are in.
They may be corrupted.
In the event of an unclean shutdown of a nonjournaled
mongod
process, restoring
the data files to a consistent state requires running a repair. The repair process
rewrites the data files, discarding anything it can't understand (corrupted data).
Because downtime and data loss are generally frowned upon, repairing in this way is
usually part of a last-ditch recovery effort. Resyncing from an existing replica is almost
always easier and more reliable. Being able to recover in this way is one of the reasons
why it's so important to run with replication.
Journaling obviates the need for database repairs because MongoDB can use the
journal to restore the data files to a consistent state. In MongoDB v2.0, journaling is
enabled by default, but you can disable it with the
--nojournal
flag:
$ mongod --nojournal
When enabled, the journal files will be kept in a directory called
journal
located just
below the main data path.
If you run your MongoDB server with journaling enabled, keep a of couple points
in mind. First, journaling impairs write performance. Users wanting the highest write
performance and the assurance of a journal have a couple of options. One is to
enable journaling only on passive replicas. As long as these replicas can keep up with
the primary, there'll be no sacrifice in performance. Another, perhaps complemen-
tary, solution is to mount a separate disk just for the journal. Then create a symlink
between the journal directory and the auxiliary volume. The auxiliary volume need
not be large; a 120
GB
disk is more than sufficient, and a solid state drive (
SSD
) of this
size is affordable. Mounting a separate
SSD
for the journal files will ensure that jour-
naling runs with the smallest possible performance penalty.
The second point is that journaling, by itself, does
not
guarantee that no write will
be lost. It guarantees only that MongoDB will always come back online in a consistent
state. Journaling works by syncing a write buffer to disk every 100 ms. So an unclean
shutdown can result in the loss of up to the last 100 ms of writes. If this isn't acceptable
for any part of your application, you can use the
j
option on the
getlasterror
com-
mand to instruct the server to wait until the journal is synced before returning:
db.runCommand({getlasterror: 1, j: true})
On the application level, you'd run this as a safe mode option (just like
w
and
wtime-
out
). In Ruby, you might use the
j
option like this:
@collection.insert(doc, :safe => {:j => true})
