[SERVER-76873] Range deletions should never wait on metadata objects that have no usages Created: 05/May/23  Updated: 29/Oct/23  Resolved: 08/May/23

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 7.1.0-rc0, 7.0.0-rc1

Type: Bug Priority: Major - P3
Reporter: Allison Easton Assignee: Allison Easton
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File repro.js    
Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0, v6.3
Sprint: Sharding EMEA 2023-05-15
Participants:
Linked BF Score: 14

 Description   

With the flow outlineed below and in the attached repro, it is possible for a range deletion to be scheduled to wait on a stale metadata object that no queries are referencing. This is because for the most recent metadata object, we do not check the usage counter when returning the completion future. Since this function is only used by range deletions and range deletions should never wait for metadata that has no active queries, we should change this to check the usage counter always.

The scenario to hit the issue:

A chunk is being migrated back to a shard that previously owned this chunk. After the migration begins and range deletion task is persisted on the recipient, the primary of the recipient shard steps down. The migration is aborted because of the stepdown, and the donor marks the range deletion task as non-pending on the new primary of the recipient.

However, the new primary has not yet run onCollectionPlacementVersionMismatch and so the only metadata in the metadata manager is stale information from when the chunk was previously owned by the shard. This is not a huge problem because the CSR has metadata unknown, and so this will not cause issues in queries. But for the range deleter, this means that the only metadata in the metadata manager overlaps with the range but isn't actually being used by any queries. Because it is the only metadata, we still have the range deleter wait on this metadata being destroyed even though there are no queries waiting on the metadata.

The test ends right after this migration fails, and so there are no later queries to cause onCollectionPlacementVersionMismatch. If onCollectionPlacementVersionMismatch was called, the new metadata would be recovered and set as the filtering information. This would allow the previous unused metadata to be cleaned up, thus releasing the range deletion. But in this test, there happens to be nothing else happening after this migration and so the metadata exists forever and the range deletion cannot proceed.



 Comments   
Comment by Githook User [ 10/May/23 ]

Author:

{'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'}

Message: SERVER-76873 Range deletions should never wait on metadata objects that have no usages

(cherry picked from commit 20f0868213dda0091691ae19e19f2f832f6d7e79)
Branch: v7.0
https://github.com/mongodb/mongo/commit/6130d6c22c8c7c6d28f40a37d10eb06034d41c1d

Comment by Githook User [ 08/May/23 ]

Author:

{'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'}

Message: SERVER-76873 Range deletions should never wait on metadata objects that have no usages
Branch: master
https://github.com/mongodb/mongo/commit/20f0868213dda0091691ae19e19f2f832f6d7e79

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