Extremely positive attitude. My website is beebo.org.
I’ve been reading and thinking a bit about MongoDB’s consistency model a bit over the last few weeks. I think what follows is an accurate model of how it behaves, and what the implications are, but I would be grateful for any corrections:
mongod
is running, you may as well imagine that all your
data is stored in memory, and that the files it creates on disk don’t
actually exist. This is because the files themselves are memory
mapped, and MongoDB makes no guarantees about whether they’re in a
consistent state. (They’re theoretically consistent immediately after
an fsync, and this can be forced in several ways, but I don’t think
there’s any easy way to snapshot the database files immediately after
the fsync.) [Update: Kristina pointed out that it is possible to fsync and then prevent the memory mapped file from being modified via the fsync and lock command. Once the lock (which blocks all write operations, though not reads) is in place, you can safely copy/snapshot the database file.]getLastError()
command. getLastError()
blocks until the write is either committed
to the in-memory data structure, fsynced to disk, or committed to n
replicas, depending on the arguments passed. (Note that many clients
abstract away the write plus getLastError()
call, so that the
arguments to getLastError()
become arguments to the write.
getLastError()
with no options.getLastError()
with fsync = true
.w = n
. (Note that there is currently no way to
block until the write has been
fsynced
on the replicas.)