[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: |
|
||||||||||||||||||||
| 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 ] |
It is unlikely for the generated opTime to be lagged behind the current oldest_timestamp due to minSnapshotHistoryWindowInSeconds defaulting to 5 minutes. |