[SERVER-51382] [causal consistency] Ensure tenant migration donor bumps the recipient's logical clock to at least blockTimestamp Created: 05/Oct/20  Updated: 29/Oct/23  Resolved: 08/Feb/21

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Jason Zhang
Resolution: Fixed Votes: 0
Labels: pm-1791_alpha2, pm-1791_milestone-F
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-53408 [causal consistency] Add variant of t... Closed
Problem/Incident
Backwards Compatibility: Minor Change
Sprint: Sharding 2020-11-16, Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25, Sharding 2021-02-08
Participants:
Linked BF Score: 0

 Description   

Before the recipient in a tenant migration can return success for a recipientSyncData command that includes a returnAfterReachingDonorTimestamp (set to the blockTimestamp by the tenant migration donor), it must guarantee its logical clock has durably advanced to at least that timestamp (i.e. written an oplog entry with a timestamp >= returnAfterReachingDonorTimestamp). This guarantee should apply across failovers.



 Comments   
Comment by Githook User [ 06/Feb/21 ]

Author:

{'name': 'Jason Zhang', 'email': 'jason.zhang@mongodb.com', 'username': 'jz1242'}

Message: SERVER-51382 Ensure tenant migration bumps the recipient's logical clock to at least blockTimestamp
Branch: master
https://github.com/mongodb/mongo/commit/7891065d45aea0a01a1bb11298ce58e5c2002da0

Comment by Jack Mulrow [ 22/Dec/20 ]

One possible implementation is: As part of TenantMigrationRecipientService::Instance::waitUntilTimestampIsMajorityCommitted(), after receiving the donor/recipient opTime pair for the requested timestamp, if the recipient opTime timestamp is less than the requested donor timestamp, advance the in-memory logical clock to at least the requested donor timestamp (like when committing a prepared transaction), force a noop write by locally running the appendOplogNote command (like when waiting for afterClusterTime read concern), and then wait for the recipient's lastAppliedOpTime to be majority committed, instead of the recipient opTime from the received pair.

Another idea is to send the recipientSyncData w/ returnAfterReachingDonorTimestamp command with {readConcern: "majority", afterClusterTime: <blockTimestamp>} to trigger a noop write if necessary through the normal read concern mechanism. This would require the donor gossip its latest cluster time to the recipient and that it has the advanceClusterTime privilege. I'm not sure what the consequences of running recipientSyncData with majority read concern are though, so manually forcing the noop may end up the simpler option.

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