Databases Reference
In-Depth Information
isolate it from the majority of the set, the write can end up getting rolled back. (It's a
bit outside the scope of this tip, but if you're concerned about rollbacks, I wrote a
post
describing how to deal with it.)
w
controls the number of servers that a response should be written to before returning
success. The way this works is that you issue
getlasterror
to the server (usually just
by setting
w
for a given write operation). The server notes where it is in its oplog (“I'm
at operation 123”) and then waits for
w
-1 slaves to have applied operation 123 to their
data set. As each slave writes the given operation,
w
is decremented on the master. Once
w
is 0,
getlasterror
returns success.
Note that, because the replication always writes operations in order, various servers in
your set might be at different “points in history,” but they will never have an
inconsis-
tent
data set. They will be identical to the master a minute ago, a few seconds ago, a
week ago, etc. They will not be missing random operations.
This means that you can always make sure
num
-1
slaves are synced up to the master by
running:
> db.runCommand({"getlasterror" : 1, "w" :
num
})
So, the question from an application developer's point-of-view is: what do I set
w
to?
As mentioned above, you need a majority of the set for a write to truly be “safe.” How-
ever, writing to a minority of the set can also have its uses.
If
w
is set to a minority of servers, it's easier to accomplish and may be “good enough.”
If this minority is segregated from the set through network partition or server failure,
the majority of the set could elect a new primary and not see the operation that was
faithfully replicated to
w
servers. However, if even one of the members that received the
write was not segregated, the other members of the set would sync up to that write
before electing a new master.
If
w
is set to a majority of servers and some network partition occurs or some servers
go down, a new master will not be able to be elected without this write. This is a
powerful guarantee, but it comes at the cost of
w
being less likely to succeed: the more
servers needed for success, the less likely the success.
Tip #35: Always use wtimeout with w
Suppose you have a three-member replica set (one primary and two secondaries) and
want to make sure that your two slaves are up-to-date with the master, so you run:
> db.runCommand({"getlasterror" : 1, "w" : 2})
But what if one of your secondaries is down? MongoDB doesn't sanity-check the num-
ber of secondaries you put: it'll happily wait until it can replicate to 2, 20, or 200 slaves
(if that's what
w
was).
