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

recoverFromOplogAsStandalone with takeUnstableCheckpointOnShutdown should succeed if retried after a successful attempt

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.2, 4.3.3
    • Affects Version/s: None
    • Component/s: Replication, Storage
    • Labels:
      None
    • Fully Compatible
    • v4.2
    • Repl 2019-12-02, Repl 2019-12-16

      If you retry recoverFromOplogAsStandalone with takeUnstableCheckpointOnShutdown after running the parameter combination successfully, it should do nothing and let you shut down the node cleanly, taking another unstable checkpoint on shutdown that should really be a noop since we haven't done any work and the node already has an up-to-date unstable checkpoint. Thus the proposal is:

      If a node starts up with both recoverFromOplogAsStandalone and takeUnstableCheckpointOnShutdown, and the storage engine does not have a stable checkpoint, we will check if all of the replication metadata indicates that the data files contain a fully up-to-date unstable checkpoint. If so we will go into read-only mode without doing any replication recovery (since it should not be needed) and allow automation to shutdown the node at its leisure like normal. Otherwise, if the replication metadata doesn't indicate that the unstable checkpoint is a safe one requiring no replication recovery, we will fassert as we do today. This would make it idempotent in the "success" case.

            Assignee:
            judah.schvimer@mongodb.com Judah Schvimer
            Reporter:
            judah.schvimer@mongodb.com Judah Schvimer
            Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: