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

Update OplogFetcher to go into SyncSource selection on CappedPositionLost error

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Replication
    • Replication
    • 0

      If we get it during secondary oplog fetching due to falling off the back of our sync source’s oplog, and retry the query (current behavior), we are guaranteed to go into rollback and fassert in rollback via refetch, or just fail to find a common point (which means reading the entire sync source oplog) in rollback to a stable timestamp. If we simply went back to sync source selection, we could skip all that and maybe find a better sync source that works, or log the “too stale” error like we expect.

            Assignee:
            backlog-server-repl [DO NOT USE] Backlog - Replication Team
            Reporter:
            judah.schvimer@mongodb.com Judah Schvimer
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: