| Donor 1 |
Donor 2 |
Coordinator |
| Donor 1 chooses minFetchTimestamp ts=10 |
|
|
| Donor 1 performs retryable write stmtId 1 at ts=20 |
|
|
| Donor 1 performs retryable write stmtId 2 at ts=30 |
|
|
| |
Donor 2 chooses minFetchTimestamp ts=25 |
|
| |
|
Coordinator chooses fetchTimestamp ts=25 |
leads to a sequence where the recipients won't have written an incomplete stmtId for the retryable write due to the timestamp for stmtId 2 being greater than the fetchTimestamp. This allows the statements from the retryable write to execute a second time on the recipients after the resharding operation has finished.
{
|
aggregate: "transactions",
|
pipeline: [
|
{$match: {_id: {$gt: <resume lsid>}}},
|
{$sort: {_id: 1}},
|
{$match: {"lastWriteOpTime.ts": {$lt: <fetchTimestamp>}}},
|
],
|
readConcern: {level: "majority", afterClusterTime: <fetchTimestamp>},
|
hint: "_id_",
|
cursor: {},
|
}
|
The {"lastWriteOpTime.ts": {$lt: <fetchTimestamp>}} clause is what causes stmtId 2 and therefore the entire retryable write to be skipped over by the recipients.
|