-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
v5.0
-
Sharding 2021-08-09
-
26
-
1
A (albeit unlikely) crash could occur in the following scenario
- A resharding recipient is in kCreatingCollection, receives an abort after creating the collection
- The recipient cleans up the temporary collection (which means the collection gets renamed to a drop-pending collection, keeping the same UUID) but steps down before it can persist its transition to kDone
- The recipient steps back up, still in kCreatingCollection
- Before the coordinator re-sends _shardsvrAbortReshardCollection to the new primary, the recipient state machine begins to run again
- ensureTempReshardingCollectionExistsWithIndexes will then cause an invariant to be hit since the drop-pending renamed temporary collection with the ReshardingUUID is still in the catalog
- is duplicated by
-
SERVER-58298 Reconcile resharding collection drop behavior when running under storage engines that don't support readConcern majority
- Closed