[SERVER-32518] Establish snapshot timestamp for readConcern snapshot Created: 02/Jan/18  Updated: 30/Oct/23  Resolved: 05/Feb/18

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage 2018-02-12
Participants:

 Description   

Establish a snapshot timestamp if not provided via "atClusterTime" / "afterClusterTime" or by a previously stashed snapshot. In waitForReadConcern(), if readConcernLevel is snapshot, check whether getArgsPointInTime() returns boost::none, which signifies a snapshot time has yet to be established. If this is the case then we need to establish a replica set snapshot time:

  • Wait for a majority committed snapshot to be available (in the same manner we do for majority read concern).
  • Retrieve majority committed snapshot time via call to ReplicationCoordinator::getLastCommittedOpTime()::getTimeStamp().
  • Register the snapshot timestamp with WiredTiger via call to opCtx->recoveryUnit()->selectSnapshot(), which is already in place for "atClusterTime".

Add handling for "atClusterTime" to waitForReadConcern():

  • If the requested time is greater than the lastApplied time, trigger a noop write on the primary. Then wait for the majority commit point to become greater than or equal to the requested time.
  • Begin the read transaction at the requested time.


 Comments   
Comment by Githook User [ 05/Feb/18 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-32518 Establish snapshot timestamp for readConcern snapshot
Branch: master
https://github.com/mongodb/mongo/commit/b696480400db1ad0485a8d0f41d0e7dd7e526335

Comment by James Wahlin [ 02/Jan/18 ]

I expect that we don't have to explicitly check whether atClusterTime is older than the oldest WiredTiger snapshot and that the storage engine will return an error on attempting to start a WT transaction. We should test for this and make sure that error is handled gracefully.

We should explicitly confirm that atClusterTime is not ahead of the majority commit timestamp.

Comment by Tess Avitabile (Inactive) [ 02/Jan/18 ]

james.wahlin, as part of this ticket, should we verify that the atClusterTime timestamp is not older than the oldest WiredTiger snapshot or ahead of the majority commit timestamp?

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