[SERVER-29569] Store the featureCompatibilityVersion server parameter before writing the document on downgrade Created: 12/Jun/17  Updated: 27/Oct/23  Resolved: 12/Jul/17

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Maria van Keulen
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-29370 add schema upgrade/downgrade phase to... Closed
Duplicate
is duplicated by SERVER-29280 Two Phase Drops: all drop-pending col... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2017-06-19, Storage 2017-07-31
Participants:

 Description   

2 phase drop is going to only do 2 phase drops when in featureCompatibilityVersion 3.6. The w:majority write during downgrade will make sure that all of those drops are committed before downgrading to 3.4 and prevent undropped collections from sticking around. There is currently a race between when the w:majority-write is written and when the featureCompatibilityVersion server parameter is set, such that we could start a new 2 phase drop in that window that would never get cleaned up because we downgrade before it's fully dropped.

It should be safe to set the server parameter first on downgrade and then write the w:majority document to ensure no new 2 phase drops are begun.



 Comments   
Comment by Maria van Keulen [ 12/Jul/17 ]

The work being done for both SERVER-29370 and SERVER-30117 addresses issues related to races between writing to the featureCompatibilityVersion document and the corresponding server parameter. I am closing this as works as designed since it is no longer an issue for 2-phase-drop.

Comment by Judah Schvimer [ 05/Jul/17 ]

2-phase-drop will no longer be gated by FCV, so I'm removing this from the epic. This may still be a bug in upgrade-downgrade, and so I'm moving it to the storage backlog.

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