Details
-
Bug
-
Resolution: Fixed
-
Critical - P2
-
7.0.0
-
None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v7.0
-
CAR Team 2024-01-22, CAR Team 2024-02-05
Description
Consider the following interleaving (repro1.js):
1. Initial state:
- collA: sharded collection with chunks both on shard0 and shard1.
- collB: unsharded collection on shard0.
- collC: does not exist.
2. Start txn with local or majority read concern, hit shard0 to read collB [shard0's txn snapshot has: ns1 and ns2]
3. Rename collA -> collC.
4. Read collC. On shard0, collC does not exist in the txn snapshot. On shard1 it will. Therefore the txn will see half the collection.
Moreover, if collectionC existed initially, the transaction would observe a mix of the original collection and the post-rename collection.
The example above involves rename, but a similar situation might be possible with reshardCollection.
Another anomaly is (repro2.js):
1. Initial state
- shard0 (dbPrimary): collA(sharded) and collB(unsharded)
- shard1: collA(sharded)
2. Start txn (local, majority or snapshot read concern), hit shard0 for collB
3. Drop collA
4. Read collA. Will target shard0, will read the sharded coll (but just half of it).
Attachments
Issue Links
- is related to
-
SERVER-84760 Violation of transaction snapshot isolation when collection concurrently dropped
-
- In Code Review
-
- related to
-
SERVER-77506 Sharded multi-document transactions can mismatch data and ShardVersion
-
- Closed
-