[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: |
|
||||||||||||
| 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: |
| 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. |