[DOCS-13451] Disable Read Concern Majority references only a 3-Member Primary-Secondary-Arbiter Architecture Created: 25/Feb/20  Updated: 30/Oct/23

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Charles Merrill Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: docs-replication
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769

 Description   

Description

Disable Read Concern Majority references only a 3-Member Primary-Secondary-Arbiter Architecture

https://docs.mongodb.com/manual/reference/read-concern-majority/#disable-read-concern-majority
references only a 3-Member Primary-Secondary-Arbiter Architecture
It can actually apply to almost any Arbiter scenario.
Example:
For any replica set that contains arbiters it is possible for there to be a voting majority without having the ability to complete a majority read. There are 5 voting nodes in this replica set, so majority is 3. If 2 data bearing nodes were unavailable, there would still be 3 votes from the primary, secondary, and arbiter, so the replica set would be able to elect a primary and *accept* reads. However, in that situation reads using a read concern of r:majority or stronger could not be *completed, and no reads could be **processed* by a majority of the replica set in order to meet read concern majority. This means the primary and surviving secondary must retain a snapshot at the most recent majority commit point while processing incoming reads. This increases cache pressure and memory usage, and if the situation persists, can lead to increased disk usage, and in extreme cases can cause nodes to crash.

Examples:

  • DC1-P,S,A DC2-S,S. If DC1 goes offline you would have issues with both read concern "majority" and elections. If DC2 went offline you would lose read concern "majority".
  • Even if all PSSSA Replica Set members were in a single DC the loss of 2 Secondaries would still cause the loss of read concern "majority".

This warning is posted for any Replica Set containing an Arbiter:

2020-01-24T21:39:45.071-0500 I REPL     [replexec-0] 
2020-01-24T21:39:45.071-0500 I REPL     [replexec-0] ** WARNING: This replica set uses arbiters, but readConcern:majority is enabled 
2020-01-24T21:39:45.071-0500 I REPL     [replexec-0] **          for this node. This is not a recommended configuration. Please see 
2020-01-24T21:39:45.071-0500 I REPL     [replexec-0] **          https://dochub.mongodb.org/core/psa-disable-rc-majority-4.0

so customers get confused when they have something like a PSSSA

See https://support.mongodb.com/case/00638046?c__ccId=CC-2074608

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Generated at Thu Feb 08 08:07:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.