Once we started doing ugly MongoDB joins manually in the Diaspora code, we knew it was the first sign of trouble. It was a sign that our data was actually relational, that there was value to that structure, and that we were going against the basic concept of a document data store.
Jepsen: MongoDB (quote from the MongoDB 2.2 documentation)
In some failover situations primaries will have accepted write operations that have not replicated to the secondaries after a failover occurs. This case is rare and typically occurs as a result of a network partition with replication lag. When this member (the former primary) rejoins the replica set and attempts to continue replication as a secondary the former primary must revert these operations or “roll back” these operations to maintain database consistency across the replica set.
So, here’s the $1 billion dollar question: what does it mean when MongoDB says that a write (aka insert) is complete? The answer is none of the above. MongoDB v2.0 will consider a write to be complete, done, finito as soon as it has been buffered in the outgoing socket buffer of the client host. Read that sentence over again.
These quotes all refer to previous versions of MongoDB (as early as 2.0).
If the v2.6 documentation is to be believed, MongoDB now has strict consistency when and if all writes are directed to the primary node of the replication set.
However, that’s nothing new among relational databases. PostgreSQL is happy to oblige and even MySQL had replication years ago (altho with similar weak durability guarantees as MongoDB).