Read Concern Majority when majority nodes are down

Question

I have a 6 node replica set (all of them data bearing) with 5 voting members. If I lose 3 voting members, I will not have a majority voting members and my replica set will become read-only. In this scenario, if the application has a read concern of "majority", will the reads fail? I have read that this majority read concern introduces a "cache pressure" but will the reads fail?? Or do I need to disable the RC by the below options for basic reads (with majority) to work?

--enableMajorityReadConcern command line option to false.

replication.enableMajorityReadConcern configuration file setting to false.

Answer 1

Using a read concern of "majority" does not cause the read operation to be submitted to multiple nodes.

When replication.enableMajorityReadConcern is true (default in MongoDB 3.6+) each node will note the most recent write operation that has been acknowledged by a majority of the voting nodes, and keep a snapshot of the data at that point in time.

A request using "majority" read concern instructs the mongod to read from that snapshot instead of the most recent write.

In your scenario, reads will continue normally with 3 nodes down.

In addition to keeping the snapshot at the latest majority commit, each node must also accept writes. Keeping track of the not-yet-majority writes in addition to the majority snapshot requires some additional usage of cache. If a cluster gets into a state where there is a primary and is able to accept writes, but is unable to replicate those writes to a majority of the voting nodes, this cache usage can increase to the point of causing system instability.

That can only occur when there is a voting member that does not contain data, i.e. an arbiter.

Since your scenario does not contain an arbiter, that cluster should not have the RCM-induced cache pressure issue.