[SERVER-32251] dropCollection/dropDatabase must be timestamped Created: 11/Dec/17  Updated: 30/Oct/23  Resolved: 24/Jan/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.7.2

Type: Task Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: rollback-functional
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-32284 awaitReplication can hang when the op... Closed
is depended on by SERVER-30809 Investigating remaining writes to the... Closed
Problem/Incident
Related
is related to SERVER-32532 Two-phase dropDatabase may not replic... Closed
is related to SERVER-32893 Relax replicated collection dropping ... Closed
is related to SERVER-32534 Have UnorderedFastKeyTable iterators ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-01-01, Repl 2018-01-15, Repl 2018-01-29
Participants:
Linked BF Score: 0

 Description   

I apologize for merging the problems of dropCollection and dropDatabase needing timestamps into the same ticket. They're highly related and how one problem is solved likely influences how the other is solved.

In 3.6, dropping a collection does the following:

  1. Rename the collection to a special name in the same database
  2. Replicate the collection drop to the oplog with OpTime T. The write that represents the rename to the catalog is assigned this timestamp.
  3. Asynchronously, a reaper task will be scheduled to physically drop the collection when T is majority committed. This write that represents dropping the collection from the catalog is not timestamped.

In 3.6, dropping a database works as follows:

  1. Loop through all collections in the database:
    1. Drop (rename) the collection.
    2. Replicate this drop command.
  2. Wait for all collection drops to become majority committed.
  3. Finish dropping the database which includes calling StorageEngine::dropDatabase

This is where dropDatabase gets fun. After the command thread wakes up after waiting for the collection drops to become majority committed, it actually races the reaper in dropping the collections. The drops in the linked block are also not performed with a timestamp. As documented by the KVStorageEngine, this dropDatabase method is not called from within the same WriteUnitOfWork as the logOp.



 Comments   
Comment by Githook User [ 24/Jan/18 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-32251: Timestamp drop collection/database
Branch: master
https://github.com/mongodb/mongo/commit/fbf03e93dad1d2d081944c05436e777380873eb2

Generated at Thu Feb 08 04:29:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.