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

recoverFromOplogAsStandalone with takeUnstableCheckpointOnShutdown should succeed if retried after a successful attempt

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.2, 4.3.3
    • Component/s: Replication, Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v4.2
    • Sprint:
      Repl 2019-12-02, Repl 2019-12-16
    • Case:

      Description

      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.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: