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

When EMRC=false we may set the stable timestamp ahead during rollback after forcing it back to the common point

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.2.0-rc3
    • Fix Version/s: 4.3.1, 4.2.2
    • Component/s: Replication
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2
    • Sprint:
      Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07
    • Linked BF Score:
      7

      Description

      When enableMajorityReadConcern is set to false, we set the stable timestamp to the allCommitted timestamp. During rollbackViaRefetch, which is the rollback algorithm used when EMRC=false, we will force the stable timestamp backwards to the rollback common point. After this, we will also set the initial data timestamp to an optime ahead of us so that we don't take a new stable checkpoint until we reach a suitable timestamp. It is possible, however, for us to receive a heartbeat while we are in the middle of rollback, after we have forced the stable timestamp back to the common point. If our current view of the commit point is empty (i.e. the null optime), and the commit point sent to us has a term that matches our lastApplied (which could happen, for example, if the commit point was equal to the common point), then we will advance our commit point. When we try to update the stable timestamp, we will set the stable timestamp to the allCommitted, even if we don't update our committed snapshot. This means that our stable timestamp may be set forward to the top of the oplog in the middle of rollback, causing a stable checkpoint to be taken too far in the future, which violates the expectations of rollbackViaRefetch. We may then try to commit writes with timestamps behind the stable timestamp. To address this, we should likely prevent the stable timestamp from being altered by components external to rollback if we are currently in the rollback state, similar to what we do when EMRC=true.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              william.schultz William Schultz (Inactive)
              Reporter:
              william.schultz William Schultz (Inactive)
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: