The following facts about replication and GetLastError are not explicitly documented anywhere:

When you do a default write to MongoDB, then the client program does not receive any validation that the write has made it into MongoDB. Assuming that the write succeeds, the data in the write will go through the following steps:

a) It will be validated: that is, the insert or update will be checked for validity. This includes things like making sure that an update refers to a document that exists, making sure that an insert doesn't violate a unique index constraint, etc.
b) The modified document will be written to an in-memory copy of the data files.
c) An oplog entry will be written to an in-memory copy of the oplog
d) The data will be written to the in-memory journal group
e) The journal will be flushed to disk. This flush will include the journal entries for both the modified document and the oplog entry.
f) At some (indeterminate) time later, the both the oplog entry and the modified document will be synced to disk, not necessarily at the same time.
g) At some time later, the oplog entry will be replicated to one or more secondary nodes, which will repeat all steps a-f on that node

2) When you follow-up that write with a getLastError command, you can validate that the write has made it to a certain state in the above sequence:

• A default getLastError (without options) will guarantee that the write has progressed to state (b)
• A getLastError command with {j:true}

  will guarantee that the write has progressed to state (e)

• A getLastError command with {w:2}

  will guarantee that the write has progressed to state (g) on the primary node, and has reached state (b) on at least one secondary

• A getLastError command with {w:N}

  , where N is greater than 2, will guarantee that the write has reached state (g) on the primary; has been replicated to at least (N-1) secondary nodes; and has reached state (b) on all of those nodes