-
Type: Task
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding
-
Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25
-
3
The changes from 6508f5d as part of SERVER-49825 reused the WouldChangeOwningShard error response handling in mongos. This comes with the following limitations:
- the update must be performed in a batch of size 1
- the update must be performed as a retryable write or in a multi-document transaction
- the update must not be performed as a multi=true update (this restriction was omitted from
SERVER-49825and maybe needs to be added)
One thought would be to have the donor shard handle the WouldChangeOwningShard exception locally without bubbling it up to mongos.
- is related to
-
SERVER-49825 Replicate updates changing value under new shard key pattern as delete + insert in a transaction
- Closed
- related to
-
SERVER-54040 Resharding may fail to throw WouldChangeOwningShard despite destined recipient having changed
- Closed
-
SERVER-54067 Enforce identical restrictions to the new shard key during resharding as to the original shard key
- Closed
-
SERVER-54096 Complete TODO listed in SERVER-52683
- Closed