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

Investigate where the oplog truncation happens during replication recovery

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Works as Designed
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Replication
    • None
    • ALL
    • v3.4
    • Repl 2017-10-02

    Description

      The comments for ReplicationRecovery::_truncateOplogTo indicate that it should truncate entries after and including 'truncateTimestamp'.

      The implementation, however, finds the first oplog entry less than the 'truncateTimestamp' then tells the storage engine to truncate the oplog starting at that entry, and passes true for the 'inclusive' flag. This means it will actually truncate the entry one before the 'truncateTimestamp' passed it.

      We need to audit exactly how and when the oplogTruncateAfterPoint is set and make sure we're truncating at the right points.

      Attachments

        Activity

          People

            judah.schvimer@mongodb.com Judah Schvimer
            spencer@mongodb.com Spencer Brody (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: