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

Discontinue writing to appliedThrough/minValid as part of secondary batch application

    • Fully Compatible
    • v5.0
    • Replication 2021-11-29, Replication 2021-12-13, Replication 2021-12-27, Replication 2022-01-10, Replication 2022-01-24
    • 170

      appliedThrough/minValid are for a crash recovery mechanism that allowed secondaries to apply oplog entries in parallel in back in a time when every write was journaled.

      Modern MongoDB with a standard configuration (WT + stable checkpoints) have no need for these values. appliedThrough has been replaced with the stable checkpoints timestamp (recoveryTimestamp). minValid is obsoleted as we only checkpoint at a timestamp where all previous writes have been committed.

      Writing to appliedThrough + minValid for each batch can have a noticeable performance cost in addition to breaking a WT contract (albeit in a benign way, it causes some maintainability problems with WT). We must(ish) choose a timestamp when writing to this document, and that timestamp is often the stable timestamp.

      But for clarity, I think the values should stay and still the server should maintain existing behavior when those values exist. I believe backup/restore relies on them as well as maybe initial sync and rollback via refetch?

      The complete ask:

      • Cease the writes before and after every batch of secondary oplog application
      • Never write to it with a timestamp. Or always? With more thoughtful consideration of the stable timestamp.
        • With care. I haven't combed through the more nuanced writes to this document myself to understand any possible complications.

            Assignee:
            lingzhi.deng@mongodb.com Lingzhi Deng
            Reporter:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: