-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
SERVER-91109 introduced a way to reduce the performance impact of resharding by making the primary shard skip cloning documents and applying oplog entries if it is not a direct recipient for the collection being resharded. The design overlooked the fact that on a shard that is neither a donor nor a direct recipient, the transition to “strict-consistency” involves acquiring the critical section to prepare for collection renaming (SERVER-53653). So the performance optimization unexpectedly leads to early critical section on the primary shard, which can cause misrouted writes to get blocked long before the critical section is officially engaged by the coordinator when resharding is about to commit.
- is related to
-
SERVER-91109 Optimize resharding when primary shard owns zero chunks for resharded collection
-
- Closed
-
-
SERVER-37501 Version multi-updates and multi-deletes in sharded transactions
-
- Closed
-
-
SERVER-53653 [Resharding] Take the critical section when renaming on recipient shards
-
- Closed
-
-
SERVER-106725 Enable featureFlagReshardingSkipCloningAndApplyingIfApplicable
-
- Closed
-
- related to
-
SERVER-109323 Disable featureFlagReshardingSkipCloningAndApplyingIfApplicable
-
- Closed
-
-
SERVER-109962 Add liveness testing for CRUD operations during resharding
-
- Backlog
-
-
SERVER-110368 Add server-side or test-side check that the lengths of resharding critical section on all donors and recipients are less than the length of the "blocking-writes" state on the coordinator
-
- Backlog
-