[DOCS-15348] [Server] Unclear reference to lagging majority commit point in PSA Created: 19/May/22  Updated: 22/Jan/24

Status: Backlog
Project: Documentation
Component/s: manual, Server
Affects Version/s: 5.0.0
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Kevin Adistambha Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: backlog, proactive, replication
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 1 year, 38 weeks ago
Epic Link: DOCSP-11702

 Description   

The page Mitigate Performance Issues with PSA Replica Set stated:

If one data-bearing node goes down, the other node becomes the primary. Writes with w:1 continue to succeed in this state but writes with write concern "majority" cannot succeed and the commit point starts to lag. If your PSA replica set contains a lagged secondary and your replica set requires two nodes to majority commit a change, your commit point also lags.

It's unclear to what situation "and the commit point starts to lag" refers to. Does it mean BOTH: "If one data-bearing node goes down", AND "writes with write concern "majority" cannot succeed"? Or does it ONLY refer to "writes with write concern "majority""?

In other words, does the lagging majority commit point in a degraded PSA can be mitigated by not using w:majority, or is it unavoidable as long as the secondary is down?

This is specific to MongoDB 5.0, where we cannot disable read majority anymore.


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