[SERVER-30348] on a cluster, allow initiating downgrade (or continuing upgrade) after a failed upgrade and vice versa Created: 26/Jul/17  Updated: 04/Oct/17  Resolved: 04/Oct/17

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

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

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-07-31, Sharding 2017-10-23
Participants:

 Description   

This ticket only deals with the sharding part of upgrade/downgrade (that is, _configsvrSetFeatureCompatibilityVersion), not the upgrade/downgrade on a replica set or single mongod (done through setFeatureCompatibilityVersion).

The cluster upgrade behavior should already ensure UUIDs are persisted in config.collections for all sharded collections, and that shards' notion of a sharded collection's UUID matches what's in config.collections.

This ticket is to test this behavior by inducing a failed upgrade (or downgrade), resuming upgrade (or downgrade) or initiating downgrade (or upgrade) afterwards and ensuring the UUIDs across the cluster are consistent.



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

Instead, we are disallowing initiating downgrade if partway through upgrade and vice versa. See SERVER-30515.

Comment by Esha Maharishi (Inactive) [ 23/Aug/17 ]

See this existing jstest for asserting that setFCV succeeds/fails, and checking cluster consistency: https://github.com/mongodb/mongo/blob/master/jstests/sharding/uuid_propagated_to_shards_on_setFCV_3_6.js

Comment by Esha Maharishi (Inactive) [ 23/Aug/17 ]

This ticket should add a failpoint in the server that fails _configsvrSetFeatureCompatibilityVersion partway through sending setFeatureCompatibilityVersion to shards.

It should add a test that checks four scenarios:
1) starting with a fcv=3.4 cluster (but with 3.6 binaries), turn on the failpoint, send setFeatureCompatibilityVersion: 3.6 to a mongos, and assert that it fails. then, turn off the failpoint and "resume" upgrade by sending setFeatureCompatibilityVersion: 3.6 to a mongos and assert that it works.
2) the same as 1, but rather than "resuming" upgrade, "initiate" downgrade by sending setFeatureCompatibilityVersion: 3.4 in the second step
3) starting with a fcv=3.6 cluster (and 3.6 binaries), turn on the failpoint, send setFeatureCompatibilityVersion: 3.4 to a mongos, and assert that it fails. then, turn off the failpoint and "resume" downgrade by sending setFeatureCompatibilityVersion: 3.4 to a mongos and assert that it works.
4) the same as 3, but rather than "resuming" downgrade, "initiate" upgrade by sending setFeatureCompatibilityVersion: 3.6 in the second step

CC cristopher.stauffer

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