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

    • Type: Task
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: 3.6.0
    • Fix Version/s: 3.6.1, 3.7.1
    • Component/s: Replication, Storage
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v3.6
    • Sprint:
      Repl 2017-12-18
    • Case:

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

          Issue Links

            Activity

              People

              Assignee:
              daniel.gottlieb Daniel Gottlieb
              Reporter:
              milkie Eric Milkie
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              17 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: