[SERVER-58720] DropDatabaseCoordinator must not re-execute destructive logic after removing CSRS metadata Created: 21/Jul/21  Updated: 29/Oct/23  Resolved: 28/Jul/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 5.0.2
Fix Version/s: 5.0.3, 5.1.0-rc0

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

Issue Links:
Backports
Depends
Problem/Incident
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Sharding EMEA 2021-07-26, Sharding EMEA 2021-08-09
Participants:
Linked BF Score: 171

 Description   

The removal of a database entry from the config server marks the logical end a drop database operation but not the end of the coordinator lifetime.

If a stepdown happens before releasing the coordinator, on the next step-up it will be resumed and re-execute all the dropDatabase logic even though - in the meantime - the database may have been recreated on a different primary shard.

As a result, a dropDatabase followed by a createCollection (re-creating the db) may result in data loss.

It can't be stated that the collection was recreated while dropDatabase was still running, because the following interleaving can happen:

  • The user issues dropDatabase
  • Stepdown happens right after removing CSRS metadata]
  • The user receives an error
  • The user retries dropDatabase that succeeds because the router doesn't find it on the CSRS
  • The user recreates a collection on the same database, with a different primary shard, and starts using it
  • Step-up happens, the coordinator is resumed and it removes legit data


 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 09/Aug/21 ]

Author:

{'name': 'Simon Graetzer', 'email': 'simon.gratzer@mongodb.com'}

Message: SERVER-58720 DropDatabaseCoordinator must not re-execute destructive logic after removing CSRS metadata
Branch: v5.0
https://github.com/mongodb/mongo/commit/280882d07752ea5c2a1c3056a6e25078acf34dfb

Comment by Githook User [ 26/Jul/21 ]

Author:

{'name': 'Simon Graetzer', 'email': 'simon.gratzer@mongodb.com'}

Message: SERVER-58720 DropDatabaseCoordinator must not re-execute destructive logic after removing CSRS metadata
Branch: master
https://github.com/mongodb/mongo/commit/21298b120e831a2aa2c834cc29043f32f2ccc0d9

Comment by Githook User [ 24/Jul/21 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: Revert "SERVER-58720 DropDatabaseCoordinator must not re-execute destructive logic after removing CSRS metadata"

This reverts commit 306a69a50245fb0787391c26597b02c04a156488.
Branch: master
https://github.com/mongodb/mongo/commit/d4aa8951600a04d6b4233fa56e52dfd9e85eafbd

Comment by Githook User [ 23/Jul/21 ]

Author:

{'name': 'Simon Graetzer', 'email': 'simon.gratzer@mongodb.com'}

Message: SERVER-58720 DropDatabaseCoordinator must not re-execute destructive logic after removing CSRS metadata
Branch: master
https://github.com/mongodb/mongo/commit/306a69a50245fb0787391c26597b02c04a156488

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