[SERVER-53436] Transition to primary writes minValid doc with timestamp lastApplied with readers on the same timestamp under lock free reads Created: 18/Dec/20  Updated: 29/Oct/23  Resolved: 08/Jan/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Samyukta Lanka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-52221 Enable feature flag for Lock free reads Closed
Related
related to SERVER-59721 Node may become unable to sync from o... Closed
is related to SERVER-53642 Cleanup writes to appliedThrough that... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2020-12-28, Repl 2021-01-25
Participants:

 Description   

The step up process is clearing appliedThrough by writing to the minValid document at timestamp lastApplied.
https://github.com/mongodb/mongo/blob/d5743ba8411a50534d33bc2e940377fb003dccea/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp#L503-L510

With lock free reads, holding the RSTL in exclusive mode is not blocking readers. So secondaries may have readers on timestamp lastApplied.

This is causing an assert in WiredTiger that we are writing to a timestamp that we have active readers on.

The problem is reproducible by running test jstests/replsets/read_operations_during_step_up.js with LockFreeReads enabled.



 Comments   
Comment by Githook User [ 08/Jan/21 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-53436 Make writes to appliedThrough untimestamped to make it work with Lock Free Reads.

This is safe because without EMRC=false we don't need this document for recovery and a clean shutdown would be required for a downgrade.
Branch: master
https://github.com/mongodb/mongo/commit/d3cf593292806464e145868c08698c4593fc848c

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