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

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

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v4.0, v3.6, v3.4
    • Epic Link:
    • Sprint:
      Repl 2018-11-05, Repl 2018-11-19, Repl 2018-12-03, Repl 2018-12-17
    • Case:

      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

              • Votes:
                2 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: