[SERVER-49792] Implement a snapshot manager for ephemeralForTest Created: 22/Jul/20  Updated: 06/Dec/22  Resolved: 04/Apr/22

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

Type: New Feature Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: EFT, execution_intern
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-49553 Allow point-in-time read transactions... Closed
is depended on by SERVER-48312 Remove support for supportsDocLocking... Closed
is depended on by SERVER-48314 ephemeralForTest should support times... Closed
Duplicate
is duplicated by SERVER-53616 ephemeralForTest storage engine does ... Closed
Related
is related to SERVER-49793 Keep track of active transactions in ... Closed
is related to SERVER-53247 Disable enableMajorityReadConcern:false Closed
is related to SERVER-50970 Support secondary reads in ephemeralF... Closed
Assigned Teams:
Storage Execution
Sprint: Execution Team 2020-08-10
Participants:

 Description   

To allow the RecoveryUnit to open a snapshot on the kMajorityCommitted and kLastApplied ReadSource's, we need to implement a snapshot manager for ephemeralForTest.

The replication subsystem hooks into the snapshot manager of the storage engine to update the majority committed and last applied timestamps on the fly.

This should end up looking similar to WiredTiger's snapshot manager implementation.

 

This ticket should also implement the kNoOverlap ReadSource in ephemeralForTest's RecoveryUnit. The no overlap timestamp is the minimum of the 'all durable' and 'last applied' timestamps.

Enable SnapshotManagerTests for ephemeralForTest



 Comments   
Comment by Louis Williams [ 28/Oct/20 ]

Moving back to backlog because we encountered some bugs in EFT that mean certain tests don't pass. Specifically, EFT mocks commit timestamps, and it is not possible to commit multiple transactions at the same commit timestamp. This has the consequence that reading at a timestamp has incorrect behavior.

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