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

Ensure that stable replication recovery begins at the timestamp of the stable checkpoint

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Gone away
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Replication
    • Replication

    Description

      Right now the stable checkpoint can reflect data at a timestamp after the checkpointTimestamp/lastStableCheckpointTimestamp. This means we must relax idempotency constraints at startup and have no idea what time the data actually reflects. It also means that we cannot set the initial data timestamp until replication recovery ends which limits the time where snapshot reads can occur and makes replication recovery a slightly longer process. We should make sure that whichever mechanism we use to keep track of the stable timestamp at startup is correct.

      Before 4.0 is released, we should ensure that whichever method we use, if not correct, has a path to correctness here to limit upgrade downgrade concerns in the future.

      Attachments

        Activity

          People

            backlog-server-repl Backlog - Replication Team
            judah.schvimer@mongodb.com Judah Schvimer
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: