[SERVER-54486] Clear filtering metadata on resharding donor and recipient shards during drain mode Created: 12/Feb/21  Updated: 29/Oct/23  Resolved: 01/Apr/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 5.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: PM-234-M3, PM-234-T-lifecycle
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes SERVER-55726 trivially fixed xcode warnings Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2021-03-22, Sharding 2021-04-05
Participants:
Story Points: 2

 Description   

It is possible for a secondary which becomes the new primary to already have the latest shard version for the collection being resharded due to already having refreshed the sharded collection as a secondary earlier. Failing to call onReshardingFieldsChanges() on the new primary is data loss (in the case of a new donor shard primary which fails to install the critical section) or stalls the resharding operation (in the case of a new shard primary which doesn't ever fulfill a mongo::Promise).

Chunk migration addresses this type of issue by clearing the filtering metadata and triggering a call to onShardVersionMismatch() while the new primary is still in drain mode. Resharding take the following steps, as taken from chunk migration.



 Comments   
Comment by Githook User [ 01/Apr/21 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-54486: Remove accidental file.
Branch: master
https://github.com/mongodb/mongo/commit/71101aab90b8d94b5c3d46f3c97928be9505fbb1

Comment by Githook User [ 31/Mar/21 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-54486: Clear resharding filtering metadata on primary stepUp.
Branch: master
https://github.com/mongodb/mongo/commit/9f857d7249b9dc5a8aa8032a2c55e533fc1e980a

Comment by Kaloian Manassiev [ 17/Mar/21 ]

Ah, so it is just for liveness, understood.

Comment by Max Hirschhorn [ 17/Mar/21 ]

kaloian.manassiev, I'm not sure what you mean. SERVER-54486 is required for liveness of the resharding operation independently of the states which acquire the critical section. It would otherwise be possible for a new primary to not realize that the resharding coordinator had already refreshed the old primary.

Comment by Kaloian Manassiev [ 17/Mar/21 ]

Isn't the work to make the CriticalSection persisted going to make this unnecessary? CC sergi.mateo-bellido.

Comment by Max Hirschhorn [ 12/Feb/21 ]

I think for simplicity that resharding should clear the filtering metadata for both the existing sharded collection and the temporary resharding collection without regard to whether the shard is acting as a donor or acting as a recipient. Disregarding the shard's role in the resharding operation would sidestep the case where the recipients must refresh using the existing sharded collection namespace rather than the temporary resharding collection when the resharding operation is succeeding.

Generated at Thu Feb 08 05:33:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.