Read Concern Majority when majority nodes are down 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 &quot;majority&quot;, will the reads fail? I have read that this majority read concern introduces a &quot;cache pressure&quot; 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.
Using a read concern of &quot;majority&quot; 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 &quot;majority&quot; 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.