[SERVER-38598] Write upgrade test for two phase drop Created: 13/Dec/18  Updated: 29/Oct/23  Resolved: 23/Jan/19

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

Type: Task Priority: Major - P3
Reporter: Benety Goh Assignee: Xiangyu Yao (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2019-01-28
Participants:

 Description   

We need to verify that an unfinished 4.0-style two phase drop (by-renaming way) could be handled nicely on startup of 4.2 binary.

If an 4.0-style two phase drop is unfinished on the shutdown of 4.0 binary, it means the first phase (renaming the collection to db.system.drop.xxxx) is completed (committed but not checkpointed yet - there is no db.system.drop.xxx on disk) but the second phase (the drop of db.system.drop.xxx) is not. And a "dropCollection" oplog entry is written (committed and persistent on disk in the form of WT journal).

On the startup of 4.2 binary, MongoDB will start with the last checkpoint which has the original collection and replay the oplog entries including that "dropCollection". The collection will be dropped with 4.2-style (new way) two phase drop mechanism. There will be no dangling "db.system.drop.xxxx" after startup and 4.2 binary does not need to do anything related to the 4.0-style two phase drop in this case.

This applies to both primary and secondary nodes. This ticket is to write a upgrade test to verify the theory.



 Comments   
Comment by Githook User [ 23/Jan/19 ]

Author:

{'email': 'xiangyu.yao@mongodb.com', 'name': 'Xiangyu Yao', 'username': 'xy24'}

Message: SERVER-38598 Write upgrade test for two phase drop
Branch: master
https://github.com/mongodb/mongo/commit/8ab7fe8a562b55b824b130734764a207f26e592d

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