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

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.4
    • Sprint:
      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
    • Linked BF Score:
      29

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: