[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:
Related
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:
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 SERVER-17397.

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: SERVER-70235 Don't create range deletion documents upon v4.2-v4.4 upgrade in case of collection uuid mismatch
Branch: v4.4
https://github.com/mongodb/mongo/commit/26cf04e6fbfd3c6f37f81028b6f96fa80731bf14

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".

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