-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Testing Infrastructure
-
Fully Compatible
-
ALL
-
v4.4
-
Sharding 2020-07-13, Sharding 2020-06-01, Sharding 2020-06-15, Sharding 2020-06-29, Sharding 2020-07-27, Sharding 2020-08-10, Sharding 2020-08-24, Sharding 2020-09-21
-
29
Sharding.prototype.upgradeCluster() and the related ReplSetTest.prototype.upgradeSet() functions assert the node which was originally primary before the replica set was being upgrading is still the current primary when trying to step it down. In a 2-node replica set where both members have a vote, the voting-majority is defined as both members. This means while the secondary is being restarted, the primary may end up stepping down (due to heartbeats not being received) and for the restarted node to run for and win the election. (Configuring a high election timeout or adding a third member to the replica sets are other ways to avoid this issue.)
The ReplSetTest.prototype.upgradePrimary() function already has a concept of "no downtime possible"
const noDowntimePossible = this.nodes.length > 2;
We should plumb noDowntimePossible into ReplSetTest.prototype.stepdown() to have it skip this assertion when noDowntimePossible === false.
- is related to
-
SERVER-46300 Set high election timeout in map_reduce_multiversion_cluster.js
- Closed
-
SERVER-47899 Configure ShardingTest used in merge_out_upgrade_downgrade.js to have a high election timeout
- Closed