[SERVER-29692] Two Phase Drops: two phase drops is only allowed under features compatibility version 3.6 Created: 16/Jun/17  Updated: 29/Jan/18  Resolved: 05/Jul/17

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

Type: Task Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30082 Two Phase Drops: remove all drop-pend... Closed
is related to SERVER-29815 Turn on Collection UUIDs on by default Closed
is related to SERVER-27993 Implement schema upgrade/downgrade fo... Closed
is related to SERVER-27994 Implement full upgrade/downgrade FCV ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-07-10
Participants:

 Description   

We should not be doing any two phase drops unless the Features Compatibility Version is at least 3.6. This is because two phase drops are designed to support other 3.6-only features such as UUID and rollback to timestamp.



 Comments   
Comment by Benety Goh [ 05/Jul/17 ]

Closing as Won't Fix based on subsequent design discussion with spencer:

As soon as a 3.6 mongod binary is running it will start the two-phase drop behavior. This is important since wiredTiger will be enabling the recover to checkpoint based rollback implementation as soon as we are running 3.6, regardless of featureCompatibilityVersion. On clean shutdown, if the node is still in fCV 3.4 then we should fully drop any drop-pending collections before shutdown, that way a node can be downgraded to 3.4 without leaking drop-pending collections. This is in alignment with what the storage engine will do, where during clean shutdown in 3.4 fCV it will take a 3.4 style checkpoint and return the data to a format a 3.4 binary will understand.

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