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

When enableMajorityReadConcern is false, oplog is truncated before it is majority committed

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Works as Designed
    • 4.0.20, 4.2.9, 4.4.1
    • None
    • Replication
    • None
    • ALL
    • Repl 2020-09-21

    Description

      Oplog is pinned as it is need for backup, crash recovery, and rollback (see getPinnedOplog()). When enableMajorityReadConcern is false, no oplog is needed for rollback, so oplog is only pinned for backup and crash recovery. For crash recovery, we only require oplog back to the last stable checkpoint, which can advance beyond the majority commit point. This means oplog can be truncated before it is majority committed.

      A result is that in a PSA set, it's easy for the secondary to fall off the back of the primary's oplog, particularly if secondary is down for a long period of time. However, an advantage is that the primary's disk doesn't fill up with oplog, so this could also be considered a feature.

      Attachments

        Activity

          People

            evin.roesle@mongodb.com Evin Roesle
            tess.avitabile@mongodb.com Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            16 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: