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

Starting replica set member standalone with recoverFromOplogAsStandalone as true should replay entries from oplog based on the checkpoint we start from.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.0.10
    • Fix Version/s: 4.0.13
    • Component/s: Replication
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07

      Description

      This work came out of SERVER-38356. On 4.0, we replay entries from oplog on standalone nodes during startup only if the below conditions are satisfied.

      • Cond#1 : recoverFromOplogAsStandalone paramset to true.
      • Cond#2 : supportsRecoverToStableTimestamp() returns true.
      • Cond#3 : getRecoveryTimestamp() returns a non-empty timestamp.

      When enableMajorityReadConcern(EMRC) is false, supportsRecoverToStableTimestamp() returns false. If it's true, then supportsRecoverToStableTimestamp returns true. So, incase if the node was originally started with EMRC true and restarted as standalone with EMRC false + recoverFromOplogAsStandalone set to true, then the wiredTiger storage engine starts from the stable checkpoint(/recovery timestamp). This means, we should replay the oplog entries from stable checkpoint to top of the oplog. But, because cond#2 returns false for EMRC false, we don't replay oplog entries.

      On 4.2, its not a problem, as cond#2 is replaced by supportsRecoveryTimestamp() which always return true for wiredTiger regardless of EMRC value. Basically cond#3 is the one which determines what checkpoint we started from. If we started from a stable checkpoint, then getRecoveryTimestamp() returns a non-empty timestamp value. Else, for unstable checkpoint, the recovery timestamp is empty. So, we should implement the similar thing on 4.0 (i.e, cond#2 should be replaced by supportsRecoveryTimestamp()).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              vesselina.ratcheva Vesselina Ratcheva
              Reporter:
              suganthi.mani Suganthi Mani
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: