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.
Best Answer
Using a read concern of "majority" does not cause the read operation to be submitted to multiple nodes.
When
replication.enableMajorityReadConcernis 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.