Take the 2-minute tour ×

I have been reading a few articles on MongoDB fault tolerance, and some people complain it can never really be achieved with MongoDB (like in this article: http://hackingdistributed.com/2013/01/29/mongo-ft/), and this got be confused.

Can someone confirm (and if possible show me the appropriate docs) that using the Write Concern "Journal + Majority" is enough to make sure that 100% of the writes that were reported as success by my driver are durably written and won't be lost even if any replica fails just after the write?

I'm talking about a 3 replica setup. I'm ok with the system no longer accepting writes in case of failure, but when a write is reported as successful by the driver, I need it to be durably committed (regardless of the number of replica failing after that).

share|improve this question
If at most one replica then at least one replica will always have the write as such it will always be durable even if you don't have journal. In fact having journal will do nothing to help you in the event of a failure in a distributed data setup and might encourage manual rollbacks –  Sammaye Apr 22 '13 at 13:31
Coming back to that article, I have just actually scim read it and there are so many flaws in its logic. It was written by a guy who, a. didn't understand why SQL is slow and b. didn't understand the concept of MongoDB and c. a guy who clearly didn't read up on many parts of the docmentation but instead decided to just moan about the default settings that came with MongoDB, no offence to the author but his article is just another bash by someone who doesn't really kow what they are on about. They expected one thing but in reality got another cos they didnt research –  Sammaye Apr 22 '13 at 13:41
Actually I changed my question. I can't have a write reported as succeeded and not durably written, in any situation (even with 2 replica failing). –  Flavien Apr 22 '13 at 13:52
Then you are using the wrong technology, if you require consistency and dirability (ACID) compliance over everything you should probably seek out SQL. –  Sammaye Apr 22 '13 at 14:28
@Flavien I wouldn't pay too much attention to this discussion, there is a lot of unrelated things being mixed up in these comments. If you receive acknowledgement to j:true and w:majority it means that the write occurred on majority of the replica set and flushed to disk on the primary. It's not 100ms loss to wait for journal acknowledgement, it's at most 33ms. fsync interval is irrelevant. The highest durability AND high availability of data is achieved with replication not disk durability, as there is no guarantee the disk will survive a crash but on secondary it'll still be available. –  Asya Kamsky Apr 23 '13 at 4:03

1 Answer 1

up vote 0 down vote accepted

Right so if you choose a journal write you are basically ensuring the write has made it to disk of a single node. If you choose to do a majority write, you are ensuring that the write has made it to memory of at least x number of nodes in your replica set.

By default, mongodb will flush from memory to journal every 100ms. By having your replica nodes on different machines (physical or virtual), ideally in different data centres, you are very unlikely to ever see ALL nodes in a geographically ditributed replica set go down within the same 100ms before one gets to disk.

Alternatively to guarantee that write made it to disk of a single node - use journal write.

share|improve this answer
Just FYI - that article is hideously inaccurate. He also works for another database start-up called and is likely trying to cause controversy by bashing other tech. –  sweaves Apr 22 '13 at 18:09

Your Answer


