[SERVER-53813] Avoid serving stale majority reads on new primary after election Created: 14/Jan/21  Updated: 19/Dec/23

Status: Open
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 1
Labels: former-quick-wins, needs-triage, phase2, pmr, repl-fy2023q2candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Initiative
Related
related to SERVER-63815 Add section on probable-read-you-writ... Backlog
related to SERVER-68514 Delay announcement of new primary unt... Backlog
is related to SERVER-78813 Commit point propagation fails indefi... Closed
Assigned Teams:
Replication
Participants:

 Description   

After an election, the majority commit point on the new primary may be stale. This can cause a client that performs majority writes and majority reads with readPreference:"primary" to fail to read its own write after an election.

Customers can work around this issue by using causally consistent sessions, but if the end user may interact with the database through multiple app servers, this requires passing the clusterTime token all the way back to the user's browser/app, which is impractical. It would be preferable if users can get read-your-writes by performing majority writes and majority reads with readPreference:"primary".

One way to solve this is by blocking majority reads on the new primary until it commits its first write in the new term. This might require shortening the time taken to commit the first write in the new term.

Note that even after this issue is addressed, clients that perform majority writes and majority reads with readPreference:"primary" may still fail to read their own writes after an unplanned election, if they are interacting with the database through multiple app servers or mongoses. However, this ticket describes the only known issue caused by planned maintenance, which accounts for the vast majority of elections.



 Comments   
Comment by Steven Vannelli [ 05/Oct/22 ]

The Serverless Init team doesn't see this as a burning issue that warrants a request for this ticket in the upcoming QP so we feel like this can be backlogged for now. However, if anyone feels differently and has a strong need/desire for it in the near term, please raise that.

Comment by Garaudy Etienne [ 16/Feb/22 ]

We just hit a customer use-case where this feature would have been useful btw!

Generated at Thu Feb 08 05:31:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.