Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.9.0
Affects Version/s: None
Component/s: Replication, Sharding, Write Ops
Labels:
- PM-234-M2
- PM-234-T-oplog-fetch

Backwards Compatibility:
Fully Compatible
Sprint:
Sharding 2020-10-19, Sharding 2020-11-02, Sharding 2020-11-16
Linked BF Score:
0

This is analogous to updates changing the value under the current shard key pattern. Taking inspiration from WouldChangeOwningShard, one option is to introduce a new WouldChangeOwningRecipientShard error code. update_stage.cpp would throw a WouldChangeOwningRecipientShard exception to have the operation be retried as a delete + insert in a transaction. The exception could be handled in service_entry_point_common.cpp rather than bubbling all the way back to mongos. This is because the document being modified is still owned by the donor shard. Note that the case for WouldChangeOwningShard should therefore be checked before the case for WouldChangeOwningRecipientShard.

causes

SERVER-52974 Checking if destined recipient has changed for resharding creates another full copy of the updated document

Closed

related to

SERVER-54040 Resharding may fail to throw WouldChangeOwningShard despite destined recipient having changed

Closed

SERVER-52620 Update resharding_replicate_updates_as_insert_delete.js to use reshardCollection command

Closed

SERVER-52683 Relax restrictions for updates to new shard key fields during resharding

Closed

Assignee:: Alexander Taskov (Inactive)

Reporter:: Max Hirschhorn

Participants:: Alexander Taskov, Githook User, Max Hirschhorn

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Created:: Jul 23 2020 02:57:18 AM UTC

Updated:: Oct 29 2023 10:05:22 PM UTC

Resolved:: Nov 06 2020 04:03:21 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates