Databases Reference
In-Depth Information
The preferable option is fastsyncing from a backup or resyncing from scratch. Remem-
ber that you must wipe the possibly corrupt data before resyncing; MongoDB's repli-
cation cannot “fix” corrupted data.
Tip #32: Understand getlasterror
By default, writes do not return any response from the database. If you send the data-
base an update, insert, or remove, it will process it and not return anything to the user.
Thus, drivers do not expect any response on either success or failure.
However, obviously there are a lot of situations where you'd like to have a response
from the database. To handle this, MongoDB has an “about that last operation...”
command, called
getlasterror
. Originally, it just described any errors that occurred in
the last operation, but has branched out into giving all sorts of information about the
write and providing a variety of safety-related options.
To avoid any inadvertent read-your-last-write mistakes (see
“Tip #50: Use a single
connection to read your own writes” on page 51
),
getlasterror
is stuck to the butt
of a write request, essentially forcing the database to treat the write and
getlasterror
as a single request. They are sent together and guaranteed to be processed one after the
other, with no other operations in between. The drivers bundle this functionality in so
you don't have to take care of it yourself, generally calling it a “safe” write.
Tip #33: Always use safe writes in development
In development, you want to make sure that your application is behaving as you expect
and safe writes can help you with that. What sort of things could go wrong with a write?
A write could try to push something onto a non-array field, cause a duplicate key ex-
ception (trying to store two documents with the same value in a uniquely indexed field),
remove an
_id
field, or a million other user errors. You'll want to know that the write
isn't valid before you deploy.
One insidious error is running out of disk space: all of a sudden queries are mysteriously
returning less data. This one is tricky if you are not using safe writes, as free disk space
isn't something that you usually check. I've often accidentally set
--dbpath
to the wrong
partition, causing MongoDB to run out of space much sooner than planned.
During development, there are lots of reasons that a write might not go through due
to developer error, and you'll want to know about them.
Tip #34: Use w with replication
For important operations, you should make sure that the writes have been replicated
to a majority of the set. A write is not “committed” until it is on a majority of the servers
in a set. If a write has not been committed and network partitions or server crashes
