[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:
Depends
Related
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:

  • don't use movePrimary if your application wants to use retryable writes on unsharded collection.

or

  • Before calling movePrimary, make sure that there are no ongoing retryable writes to unsharded collection and after calling movePrimary, make sure to start a new session before attempting to do a retryable write.


 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:

Avoid accessing an un-sharded collection during migration. movePrimary does not prevent reading and writing during its operation, and such actions yield undefined behavior.

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.

Generated at Thu Feb 08 04:29:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.