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

oldest_timestamp should track the last applied time, during initial sync

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Critical - P2
    • Resolution: Fixed
    • 3.6.0
    • 3.6.1, 3.7.1
    • Replication, Storage
    • Fully Compatible
    • v3.6
    • Repl 2017-12-18

    Description

      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.

      Attachments

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

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: