[SERVER-30515] disallow initiating cluster FCV downgrade in the middle of upgrade (and vice versa) Created: 03/Aug/17  Updated: 02/Oct/17  Resolved: 02/Oct/17

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31209 need to store upgrade/downgrade in pr... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-10-02, Sharding 2017-10-23
Participants:

 Description   

we can do this by checking the targetVersion on the config server at the beginning of configsvrSetFCV

if push comes to shove, you will be able to manually change the version and targetVersion fields in the featureCompatibilityVersion document to allow initiating downgrade in the middle of upgrade (and vice versa)

---------

this is to prevent the following case:

the config server's configsvrSetFCV sends setFCV to all shards.

if multiple configsvrSetFCV's were allowed to run concurrently (and were trying to set different versions), their setFCV's to shards could be interleaved, leaving shards with inconsistent FCVs, though both configsvrSetFCV calls return success. to protect against this, we can allow only one configsvrSetFCV to run at a time.

however, if the config server fails over during a configsvrSetFCV, its setFCV calls to shards may still be in flight. a follow-up configsvrSetFCV's setFCV calls to shards can then still race with the in-flight setFCV calls from the first configsvrSetFCV.



 Comments   
Comment by Esha Maharishi (Inactive) [ 02/Oct/17 ]

Will be fixed as part of SERVER-30793.

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