[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: |
|
||||
| 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. |