-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding 2021-03-08
-
1
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.
- is related to
-
SERVER-52921 Integrate config.transactions cloner for resharding into RecipientStateMachine
- Closed
- related to
-
SERVER-54681 Resharding recipient shards which are also donor may fail retryable writes with IncompleteTransactionHistory too early
- Closed
-
SERVER-55214 Resharding txn cloner can miss config.transactions entry when fetching
- Closed
-
SERVER-55305 Retryable write may execute more than once if primary had transitioned through rollback to stable
- Closed