[SERVER-28884] CollectionRangeDeleter track deletions more reliably Created: 20/Apr/17  Updated: 30/Oct/23  Resolved: 17/May/17

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

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

Issue Links:
Related
related to SERVER-24368 Write unit-tests which test the range... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-05-29
Participants:

 Description   

In current code, each metadata version has provisioned one range to delete when it is retired. Registering a second range would require copying the metadata to a new version (if there is no other event that required the copy), a potentially expensive operation. Keeping a list of ranges for each metadata version would simplify the code and avoid otherwise-unnecessary metadata copying.

Furthermore, the event-managing code has a race in which a deletion could fail while the requester is not waiting, resulting in the failure not being reported to the requester, and then, possibly, in-migration to a range currently occupied.

Solving this requires plumbing range deletion event notification through more levels of interface.



 Comments   
Comment by Githook User [ 17/May/17 ]

Author:

{u'username': u'ncm', u'name': u'Nathan Myers', u'email': u'ncm@cantrip.org'}

Message: SERVER-28884 Better range deletion event tracking
Branch: master
https://github.com/mongodb/mongo/commit/1ac2f9d964bc86a1b7ed5ec608a7d1c444b017bd

Comment by Nathan Myers [ 15/May/17 ]

See also comments on 133320002:
https://mongodbcr.appspot.com/133320002/#msg3
https://mongodbcr.appspot.com/133320002/#msg4

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