[SERVER-43690] Make RangeDeleter correctly handle epoch changes due to shard key refinement Created: 27/Sep/19  Updated: 29/Oct/23  Resolved: 25/Nov/19

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

Type: Bug Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Matthew Saltz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-44725 Audit usages of epoch in sharding code Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2019-10-07, Sharding 2019-12-02
Participants:

 Description   

Right now, the range deleter uses the epoch of a collection to uniquely identify it, and if the epoch changes, it will throw out the range deletion tasks for that collection. However, now that refining the shard key changes the epoch of a collection, this logic is no longer correct and will lead to permanently orphaned documents.



 Comments   
Comment by Githook User [ 25/Nov/19 ]

Author:

{'name': 'Matthew Saltz', 'username': 'saltzm', 'email': 'matthew.saltz@mongodb.com'}

Message: SERVER-43690 Change range deleter code to use collection UUID instead of epoch to detect collection drops/recreates
Branch: master
https://github.com/mongodb/mongo/commit/6b24eefb159443111f902f8a9f343493986d1802

Comment by Matthew Saltz (Inactive) [ 19/Nov/19 ]

This can also cause a segfault here if _orphans is cleared.

Comment by Matthew Saltz (Inactive) [ 18/Nov/19 ]

Created a separate ticket for the other cases, SERVER-44725. This one will only deal with the CollectionRangeDeleter.

Comment by Matthew Saltz (Inactive) [ 07/Nov/19 ]

Note to self: We probably need to handle this and the other case in the destination manager too.

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