-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
26
-
1
Resharding is not supported with storage engines that don't support readConcern majority. This manifests in this ticket with dropCollection behavior. In storage engines that don't support readConcern majority, the two-phase dropCollection is run in separate storage transactions. This allows readers to see resharding collections in a quasi-renamed-but-not-yet-dropped state.
These are potential solutions:
- Fix behavior in resharding server code to tighten constraints around dropCollection. Should have no behavior change on storage engines that support the post-4.0 drop behavior (aka WiredTiger).
- Add constraints around dropCollection just in resharding unit tests in order to prevent this race from happening.
- Remove resharding unit tests that rely on dropCollection behavior and rely solely on integration tests to test this.
- duplicates
-
SERVER-58603 ensureTempReshardingCollectionExistsWithIndexes may hit an invariant if collection was previously dropped
- Closed