[SERVER-73391] Use recoverable critical section for drop database Created: 27/Jan/23  Updated: 29/Oct/23  Resolved: 27/Mar/23

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

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Marcos José Grillo Ramirez
Resolution: Fixed Votes: 0
Labels: shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split from SERVER-70600 dropDatabase DDL operation might comp... Closed
Problem/Incident
causes SERVER-75642 Fixing condition to mitigate some iss... Closed
causes SERVER-75635 Pre 7.0 dropDatabase implementation r... Closed
Related
related to SERVER-70600 dropDatabase DDL operation might comp... Closed
related to SERVER-74880 movePrimary participant should drain ... Closed
Assigned Teams:
Sharding EMEA
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding EMEA 2023-03-06, Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03
Participants:
Story Points: 5

 Description   

SERVER-70600 is a mitigation that prevents a shard to believe it is the primary database even after the termination of a drop database coordinator. However, we could still allow a write to sneak in after a stepdown, but after the commit was sent to the CSRS, allowing the creation of an unsharded collection that will be never deleted.

The purpose of this task is to revisit the dropDatabase DDL operation and change its implementation to start using the Recoverable Critical Section and prevent leaving unsharded collections in the shards that had executed a drop database.



 Comments   
Comment by Githook User [ 27/Mar/23 ]

Author:

{'name': 'Marcos José Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}

Message: SERVER-73391 Add recoverable critical section to drop database command
Branch: master
https://github.com/mongodb/mongo/commit/5e9606da4202e02995e88d845294b06dc0b78ccc

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