[SERVER-67730] CSRS stepdown during rename may leave orphned entries in `config.chunks` Created: 01/Jul/22  Updated: 29/Oct/23  Resolved: 12/Jul/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Enrico Golfieri
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
is caused by SERVER-55115 Delete config.collections entry befor... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding EMEA 2022-07-11, Sharding EMEA 2022-07-25
Participants:
Linked BF Score: 17

 Description   

[DISCLAIMER] This is not a correctness bug, it only results in some garbage being left in the config.chunks collection.

SERVER-55115 changed the order to remove metadata for a specific collection from the config server: first the collection entry, then the chunks entries referring the dropped uuid. If a stepdown happens on the config server in between those steps, then it's possible to leave orphaned chunk entries around.

It has been observed this incriminated flow in a build failure:

The first command sent to the CSRS resulted in calling renameShardedMetadata that tried to remove collection and chunks entries, but only succeeded to remove the collection entry while the stepdown happened when trying to delete chunks.

As a consequence, the second command invocation on the CSRS followed the same flow but didn't try to remove chunk entries because the collection entry was not found.



 Comments   
Comment by Githook User [ 12/Jul/22 ]

Author:

{'name': 'Enrico Golfieri', 'email': 'enrico.golfieri@mongodb.com', 'username': 'enricogolfieri'}

Message: SERVER-67730 CSRS stepdown during rename must not leave orphned entries in `config.chunks`
Branch: master
https://github.com/mongodb/mongo/commit/b45994f9b363a24be2126dc628f6fd43213c438b

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