[SERVER-67857] Manage last applied timestamp outside of the storage engine Created: 07/Jul/22  Updated: 05/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 1
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-66763 Reading on secondaries during repl st... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

The timestamp to read at when using the kLastApplied read source is maintained internally in the storage engine in the component called the snapshot manager. This timestamp doesn't really have anything to do with the storage engine and is rather a replication related construct about how we can safely read in the repl SECONDARY state concurrently with oplog batch application.

Logically, for the storage engine, this could be maintained outside and passed in similarly to how the kProvided read source works. This could make it easier to avoid bugs where a timestamp needs to be checked against some conditions before we open a storage snapshot with it.

Some special handling needs to occur as the query yield code needs to advance the timestamp for the kLastApplied read source, something that is not done for kProvided.


Generated at Thu Feb 08 06:09:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.