[SERVER-52801] Implement a local drop on resharding donors Created: 11/Nov/20  Updated: 29/Oct/23  Resolved: 07/Dec/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Task Priority: Major - P3
Reporter: Blake Oler Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: PM-234-M2, PM-234-T-lifecycle
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
has to be done after SERVER-52802 [Resharding] Remove kDropping from th... Closed
Related
related to SERVER-53224 [Resharding] Verify, in the reshardin... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-12-14
Participants:
Story Points: 1

 Description   

Background

Since a drop from the DonorStateMachine can happen concurrently with a rename from a RecipientStateMachine on the same node, there's no inherent guarantee of ordering. Thus, there can be two scenarios that the drop functionality can find itself in:

  1. If the renameCollection with dropTarget=true happens first, then the drop would see <database>.<collection> has a UUID of reshardingUUID.
  2. If the drop happens first, the drop would see <database>.<collection> has a UUID of existingUUID.

Solution

  1. If the rename happens first and the collection has a UUID of reshardingUUID, this means that the rename already took care of the drop (via dropTarget=true) and the DonorStateMachine can successfully transition to kDone without taking any action.
  2. If the drop happens first and the collection has a UUID of existingUUID, the DonorStateMachine can drop the local collection. This is fine, because when the rename happens afterwards, the rename's dropTarget piece will end up being a no-op.


 Comments   
Comment by Githook User [ 05/Dec/20 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-52801 Implement local drop for the original collection on resharding donors
Branch: master
https://github.com/mongodb/mongo/commit/90150fccbac05d75e96b6874132dae71c3c0b31c

Comment by Blake Oler [ 21/Nov/20 ]

max.hirschhorn this makes a lot of sense. Changing the ticket.

Comment by Max Hirschhorn [ 21/Nov/20 ]

If the DonorStateMachine confirms the UUID of the sharded collection it is dropping to be existingUUID rather than reshardingUUID, then does there really need to be explicit synchronization between the two primary-only services? That is,

  • if the renameCollection with dropTarget=true happens first, then the drop would see <database>.<collection> has a UUID of reshardingUUID and doesn't drop it, and
  • if the renameCollection with dropTarget=true happens second, then the drop would see <database>.<collection> has a UUID of existingUUID, drops it, and the renameCollection's dropTarget piece ends up being a no-op.
Generated at Thu Feb 08 05:29:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.