[SERVER-60491] Prevent FCV downgrade from 5.1 to 5.0 in the presence of sharded time-series collection Created: 06/Oct/21  Updated: 13/Oct/21  Resolved: 13/Oct/21

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

Type: New Feature Priority: Major - P3
Reporter: Arun Banala Assignee: Arun Banala
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backport Requested:
v5.1
Sprint: QE 2021-10-18
Participants:

 Comments   
Comment by David Storch [ 08/Oct/21 ]

bernard.gorman, that makes sense. You need to be able to get into the "downgrading" state so that new uses of the incompatible feature are blocked, at which point the user may need to take some action before completing the FCV downgrade.

Comment by Arun Banala [ 07/Oct/21 ]

david.storch If the downgrade may result in data corrupt/loss (which would be the case for sharded time-series), I believe we've made setFCV command to fail in the past. If we don't do this, there would be no way for us to check if the users did do the cleanup. I found this recent example on 5.0, which disallows downgrade to 4.4 if the cluster has a time-series collection.

Comment by David Storch [ 07/Oct/21 ]

Wait, is it ever acceptable to prevent the FCV from being downgraded until some action is taken? My understanding is that usually users are supposed to downgrade the FCV and only then perform any necessary cleanup before downgrading the binaries.

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