[SERVER-55680] Generate, pin, and replicate minFetchTimestamp on donor shards in resharding atomically Created: 31/Mar/21  Updated: 06/Dec/22  Resolved: 26/Oct/21

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

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Do Votes: 0
Labels: PM-234
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-54610 Resharding writes to donor documents ... Closed
Related
related to SERVER-55873 Force secondaries to apply each write... Closed
is related to SERVER-55679 Remove wait for w:majority from donor... Closed
Assigned Teams:
Sharding NYC
Participants:
Linked BF Score: 125
Story Points: 1

 Description   

Donor shards currently do two writes to generate, pin, and replicate the minFetchTimestamp value. First, donor shards write a no-op oplog entry and use its opTime as the minFetchTimestamp. Second, donor shards update the config.localReshardingOperations.donor document to set the minFetchTimestamp field. This two-step process can lead to cases where the generated opTime has already lagged behind the current oldest_timestamp value and has therefore become ineligible for pinning.

repl::getNextOpTime() can be called within the WriteUnitOfWork to reserve an oplog slot. This oplog slot that can be used as the timestamp for the update to set the minFetchTimestamp field.



 Comments   
Comment by Max Hirschhorn [ 26/Oct/21 ]

This two-step process can lead to cases where the generated opTime has already lagged behind the current oldest_timestamp value and has therefore become ineligible for pinning.

It is unlikely for the generated opTime to be lagged behind the current oldest_timestamp due to minSnapshotHistoryWindowInSeconds defaulting to 5 minutes.

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