Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-48170

Multiversion tests assume primary stability when using upgradeCluster() with 2-node replica set shards

    • 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.

            Assignee:
            tommaso.tocci@mongodb.com Tommaso Tocci
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: