[SERVER-32113] movePrimary can cause retryable writes to the collection moved applied twice Created: 29/Nov/17 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.0-rc6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | max-triage, pm-1051-legacy-tickets | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Unlike moveChunk, movePrimary does not transfer the transaction history when cloning the unsharded collection to the new destination. This means that if a retryable write is applied on the original shard, the record of it being written will not be transferred to the new shard it is being moved to. To get around this bug, either:
or
|
| Comments |
| Comment by Kaloian Manassiev [ 29/Nov/17 ] |
|
Agreed. If movePrimary was using the regular chunk migration protocol, the transactions information would be transferred properly. Because of this I am moving this ticket under the general 'Collection Lifecycle' improvements project. |
| Comment by Daniel Pasette (Inactive) [ 29/Nov/17 ] |
|
Agreed. The documentation states:
|
| Comment by Andy Schwerin [ 29/Nov/17 ] |
|
I think we're better off considering this a bug with "move primary". It's already not safe to move a primary while writes are happening. |