[SERVER-33496] Remove timestamping from second phase of collection drops Created: 26/Feb/18  Updated: 29/Oct/23  Resolved: 01/Mar/18

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Bug 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
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-03-12
Participants:
Linked BF Score: 0

 Description   

Collection drops happen in two-steps:

  1. Rename the collection to special name that encodes the optime of the drop. This phase is replicated.
  2. When the optime becomes majority committed, asynchronously notify the storage engine the collection can be removed.

This process gives a guarantee that the storage engine can safely throw away collection without fear of needing to get it back later.

Because the collection drop is "behind the replica set commit point" and we currently only plan to allow reads at the commit point, it is safe to not timestamp the write that removes the key/value pair from the storage engine's catalog. Doing so would be convenient to eliminate the risk of assigning a stale ghost timestamp.

Timestamps for this drop can be assigned in two code paths:

  1. When the reaper processes the final step of dropping a collection.
  2. When `KVStorageEngine::dropDatabase` drops the remaining collections that the reaper has yet to get to.

The latter is the more substantial change, particularly to the documentation.



 Comments   
Comment by Githook User [ 28/Feb/18 ]

Author:

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

Message: SERVER-33496: Stop timestamping collection drops.
Branch: master
https://github.com/mongodb/mongo/commit/0f8378ed44f4502cde21f3416772d93434e48255

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