-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.3.0, 3.6.0, 4.0.0, 4.2.0, 4.4.0, 5.0.0, 5.2.0, 5.1.0, 6.0.0, 6.1.0, 6.2.0-rc0, 6.3.0, 7.0.0, 7.1.0, 7.3.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0, v7.3, v7.0, v6.0, v5.0
-
CAR Team 2024-02-05, CAR Team 2024-03-18, CAR Team 2024-04-01, CAR Team 2024-04-15, CAR Team 2024-04-29
-
2
The scenario may be reproduced through the following sequence:
1. A migration with "nss: collName, from: shardId1, to: shardId2" starts; the MigrationSourceManager gets instantiated on shardId1, and placement information gets retrieved; at the time of the retrieval, shardId2 owns 1 collection chunk
2. A concurrent migration with "nss: collName, from: shardId2, to: anotherShardId" gets concurrently committed; shardId2 loses its last chunk (and the related op entry gets emitted)
3. The migration started on step 1 is resumed; since shardId2 reacquires its first collection chunk, a migrateChunkToNewShard should be emitted - but the placement information is stale at the time it gets evaluated
- is related to
-
SERVER-85914 Inspect all usages of CollectionMetadata::getChunkManager() and hide it from the public API
- Closed
- related to
-
SERVER-74032 MigrationSource manager should emit op entries on the committed request while still blocking user writes
- Blocked