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

Increment the number of oplog entries applied by one when recipient completely catches up to donor

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Sharding 2021-05-17
    • Story Points:
      1

      Description

      The ReshardingDonorOplogIterator intentionally doesn't return the op='n' final resharding oplog entry. Not returning the final resharding oplog entry ensures the recipient, when resuming, would be guaranteed to come across the oplog entry again in its local oplog buffer and realize it had already finished applying all of the oplog entries.

      However, the current behavior leads the number of oplog entries fetched to always be greater than the number of oplog entries applied, even when resharding completes successfully. This is due to how the op='n' final resharding oplog entries are accounted for in the number of oplog entries fetched, but are not accounted for in the number of oplog entries applied. Incrementing the in-memory counter by 1 for the number of oplog entries applied when ReshardingOplogApplier::_currentBatchToApply is empty would correct this discrepancy. The on-disk value for 'numEntriesApplied' in the progress_applier collection must not be incremented by 1.

        Attachments

          Activity

            People

            Assignee:
            janna.golden Janna Golden
            Reporter:
            max.hirschhorn Max Hirschhorn
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: