[SERVER-48183] Mark sharding/remove2.js as requires_fcv_46 Created: 13/May/20 Updated: 06/Dec/22 Resolved: 14/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Linked BF Score: | 24 | ||||
| Description |
|
sharding/remove2.js is used to test the addition and removal of a shard to the cluster. By running it on the sharding_multiversion suite we could incur in possible downgrade of the replica set nodes. In fact on each replicaSet restart the sharding_multiversion suite choose a random version between latest and last-stable. Since we don't support downgrade we shouldn't run this test in the multiversion suite. |
| Comments |
| Comment by Tommaso Tocci [ 14/May/20 ] |
|
I found the definite cause of the BF-17247 I'll close this and open another SERVER ticket to fix the issue. Thanks max.hirschhorn for always double checking |
| Comment by Kaloian Manassiev [ 14/May/20 ] |
|
This was done on urge from me, based on my mistaken interpretation that this somehow results in an unplanned/unsupported order of downgrades. However I am just realising that this is actually not the case, because MongoS will be at 4.4 and so will be the Config server, so the downgrade is not an issue. |
| Comment by Max Hirschhorn [ 13/May/20 ] |
tommaso.tocci, why is the shard not allowed to be re-added after downgrading the binary version? The thought in |