MongoDB durability with j= true and w:majority

[ASEEM GOYAL]

Hello,

I am evaluating using mongoDb for my application and have a question (regarding version 3.6) -

Assume there is a 11 member replica set, where each node is a voting member and no arbitrary node is present. For a write w1, Using j=true and w:majority would ensure that a write is written to the journal and let's assume to the disk also after the default time interval (although j:true implies that updates will be written to the journal and NOT on disk data files as per https://docs.mongodb.com/manual/reference/write-concern/#writeconcern.j).

If 5 nodes fail (all having the write w1 mentioned above) at the same time including the primary, only one of the remaining 6 nodes has the write w1. If this node does not get enough votes (say it's overloaded and will not be suitable for role of a primary), and some other node gets all 6 votes to become primary, we have basically lost the write w1.

I know this is a rare case, but it still can happen. So isn't it true that using j= true and w:majority also will not assure that the writes are durable?

Thanks,
Aseem

[Stephen Steneker]

On Wednesday, 3 January 2018 23:10:45 UTC+11, ASEEM GOYAL wrote:

I am evaluating using mongoDb for my application and have a question (regarding version 3.6) -

Assume there is a 11 member replica set, where each node is a voting member and no arbitrary node is present. For a write w1, Using j=true and w:majority would ensure that a write is written to the journal and let's assume to the disk also after the default time interval (although j:true implies that updates will be written to the journal and NOT on disk data files as per https://docs.mongodb.com/manual/reference/write-concern/#writeconcern.j).

Hi Aseem,

I see your question was also posted and discussed on DBA StackExchange so it is probably best to consolidate the discussion there: https://dba.stackexchange.com/q/194346/9345. With MongoDB 3.6 default settings (WiredTiger storage engine and replica set protocol v1) a write concern including j:true will cause an immediate sync of the journal (see: storage.journal.commitIntervalMs). The replica set member with the newest optime will be elected primary, so if all (but one) of the voting members that confirmed a majority write are unavailable, the surviving member is the only candidate to be primary.

There is an obvious performance tradeoff for increased levels of write concern and acknowledgement. In addition to majority write concern, you should also look into the new Retryable Writes feature in MongoDB 3.6. This server feature allows updated drivers to handle transient network errors or replica set elections.

Also note that while MongoDB 3.6 supports up to 50 members in a replica set there is a limit of 7 voting members.

Regards,

Stennie