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.



    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 4.0.10
    • 4.0.13
    • Replication
    • None
    • Fully Compatible
    • ALL
    • Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07


      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()).


        Issue Links



              vesselina.ratcheva@mongodb.com Vesselina Ratcheva (Inactive)
              suganthi.mani@mongodb.com Suganthi Mani
              0 Vote for this issue
              8 Start watching this issue