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

oldest_timestamp should track the last applied time, during initial sync

    • Fully Compatible
    • v3.6
    • Repl 2017-12-18

      Currently, the oldest_timestamp only tracks the stable timestamp, which tracks applied optimes as they commit. However, applied optimes only become stable timestamp candidates if the consistency mode of the node is "Consistent". During initial sync, the consistency mode of the node is not "Consistent", and thus we do not add any new stable timestamp candidates while in the oplog replay phase. This results in the oldest_timestamp not moving, which can quickly fill up cache with timestamp data during the oplog replay phase of initial sync.

        1. comparison.png
          comparison.png
          277 kB
        2. PinnedMaster.png
          PinnedMaster.png
          81 kB
        3. PinnedPatch.png
          PinnedPatch.png
          80 kB
        4. server32226.tgz
          511 kB

            Assignee:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Reporter:
            milkie@mongodb.com Eric Milkie
            Votes:
            0 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: