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

Invariant that term from lastAppliedOptime is never greater than our current term

    XMLWordPrintableJSON

Details

    • Fully Compatible
    • v4.0, v3.6, v3.4
    • Repl 2018-11-05, Repl 2018-11-19, Repl 2018-12-03, Repl 2018-12-17

    Description

      As a sanity check in case a user manually modifies their local database in a way that puts them into this state

      Attachments

        Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. SERVER-38366 Replica set nodes update the term without verifying the config version can lead to unnecessary stepdown.

          • Major - P3 - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. SERVER-38504 On Primary, to verify that our lastAppliedOpTime is lagged behind the TopologyCoordinator::_lastCommittedOpTime, we should compare both its term and timestamp for pv1.

          • Major - P3 - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. SERVER-38505 For pv1, to determine if the oplog entries are applied out of order, we should compare both the term and timestamp of firstOpTimeInBatch and lastAppliedOpTimeAtStartOfBatch

          • Major - P3 - Major loss of function.
          • Closed

          Activity

            People

              suganthi.mani@mongodb.com Suganthi Mani
              spencer@mongodb.com Spencer Brody (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: