[SERVER-70235] Don't create range deletion documents upon v4.2-v4.4 upgrade in case of collection uuid mismatch Created: 05/Oct/22 Updated: 29/Oct/23 Resolved: 09/Nov/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.19 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Allison Easton |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Sharding EMEA 2022-10-17, Sharding EMEA 2022-10-31, Sharding EMEA 2022-11-14 | ||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| Story Points: | 7.5 | ||||
| Description |
|
The upgrade procedure creates range deletion task documents in the following way: for each local collection, refresh the routing table and - if sharded - create range deletion task documents for all non-owned ranges. This procedure does not take into account that no range deletion must happen if the local collection uuid is not matching with the uuid tracked by the config server. This may happen, for example, when a shard holds a stale incarnation of a collection due to Detailed flow Since v4.2 is not tracking orphans on disk, submitOrphanRangesForCleanup is invoked by every shard in order to create range deletion tasks in the following way:
The problem lies in how a range deletion task document is created: the uuid from the local catalog is persisted rather than the one known by the config server. |
| Comments |
| Comment by Githook User [ 09/Nov/22 ] |
|
Author: {'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'}Message: |
| Comment by Pierlauro Sciarelli [ 06/Oct/22 ] |
|
Done some local testing and realized that this prevents the range deletion from actually start. Still, it's erroneous to create range deletion tasks for a different collection, even though in case of catalog inconsistency there are way bigger problems. I guess we can flag this as "improvement" or close it as "won't do". |