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

Only advance oldest timestamp when setting lastApplied during initial sync instead of STARTUP2 state



    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.7.0
    • Replication
    • None
    • Fully Compatible
    • Repl 2020-06-29


      Currently we advance our oldest timestamp to lastApplied whenever we are in STARTUP2 state. This was originally intended to relieve cache pressure during initial sync oplog application, as described in SERVER-32226. The current logic, however, is not strictly scoped to initial sync oplog application, since we pass through STARTUP2 whenever we start up and go through recovery on our way to SECONDARY. This means that, after a normal startup recovery procedure, we will set our lastApplied and oldest timestamp to the top of the oplog when we load our optimes from disk here. This can lead to a case where we become SECONDARY and our oldest timestamp is ahead of our initialDataTimestamp before we have set a stable timestamp. Due to the changes inĀ SERVER-47844, this can cause an issue where we try to set our first stable timestamp behind the oldest timestamp, since we use the initialDataTimestamp as a barrier behind which we will not set the stable timestamp. To avoid this problem, we should move this logic into the setMyLastOpTime callback which is the specific location where we advance lastApplied during initial sync oplog application.


        Issue Links



              william.schultz@mongodb.com William Schultz (Inactive)
              william.schultz@mongodb.com William Schultz (Inactive)
              0 Vote for this issue
              4 Start watching this issue