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