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

cappedTruncateAfter must not set oldest timestamp during startup recovery when enableMajorityReadConcern=false

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.7, 4.1.7
    • Component/s: Replication, Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Steps To Reproduce:
      Hide

      Start up mongod with enableMajorityReadConcern:false and --replSet on the attached data files: repro.zip

      Show
      Start up mongod with enableMajorityReadConcern:false and --replSet on the attached data files:  repro.zip
    • Sprint:
      Repl 2018-12-17
    • Linked BF Score:
      33

      Description

      In cappedTruncateAfter, when majority read concern is disabled, we set the oldest timestamp to the truncate timestamp. This is incorrect when recovering from a stable timestamp at startup, since the truncate timestamp is the end of the oplog, and we will apply (and timestamp) writes from the recovery timestamp through the end of the oplog. This causes us to attempt to commit behind the oldest timestamp. We must not set the oldest timestamp to the truncate timestamp when recovering from a stable timestamp at startup.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: