-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding 2021-03-22, Sharding 2021-04-05, Sharding 2021-04-19
-
42
-
2
This is because we use readConcern snapshot + atClusterTime and readPref nearest.
The issue is that, in secondaries, we squash multiple updates to config.transactions into one and use the newest timestamp when calling setTimestamp. So if we have 3 writes from retryable that corresponds to ts1, ts2 & ts3, the secondary will only have ts3 set properly and you will not be able to see the config.transactions document when reading with atClusterTime ts1 or ts2.
- is related to
-
SERVER-54626 Retryable writes may execute more than once in resharding if statements straddle the fetchTimestamp
- Closed
-
SERVER-54681 Resharding recipient shards which are also donor may fail retryable writes with IncompleteTransactionHistory too early
- Closed
-
SERVER-56631 Retryable write pre-fetch phase could miss entry from config.transactions when reading from donor secondaries
- Closed
-
SERVER-52921 Integrate config.transactions cloner for resharding into RecipientStateMachine
- Closed
- related to
-
SERVER-55305 Retryable write may execute more than once if primary had transitioned through rollback to stable
- Closed
-
SERVER-55578 Disallow atClusterTime reads on the config.transactions collection
- Closed
-
SERVER-55873 Force secondaries to apply each write to config.localReshardingOperations.donor in its own batch
- Closed