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

Stable timestamp does not advance if lastApplied does not move forward, but all committed timestamp does, on single node RS

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.7, 4.0.0-rc0
    • Component/s: Replication
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v3.6
    • Sprint:
      Repl 2018-06-04
    • Linked BF Score:
      65

      Description

      SERVER-34895 made it so that the stable timestamp would never advance ahead of the all committed timestamp, so that single node primaries never storage-commit a wiredTiger transaction behind the stable timestamp.

      Consider 3 operations in flight on a single node replica set, at ts 1, 2, and 3. If 1 commits first, the all committed timestamp and lastApplied and stable timestamp will all be set to 1. If 3 commits next, then the lastApplied will be set to 3, but the all committed timestamp will still be at 1, keeping the stable timestamp at 1. When 2 commits, the all committed timestamp will advance to 3, but the lastApplied will not advance, and so the stable timestamp will not advance either.

      This will lead to majority writes not committing until another write comes in.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              judah.schvimer Judah Schvimer
              Reporter:
              judah.schvimer Judah Schvimer
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: