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