Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-14446

Investigate changes in SERVER-55376: Reconfig can roll back committed writes in PSA sets

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 5.0.0-rc0
    • Component/s: manual, Server
    • Labels:
      None

      Description

      Description

      Downstream Change Summary

      This ticket added a check to the reconfig procedure that prevents a reconfig to a PSA set that might result in rolling back committed writes. Specifically, given a reconfig to a PSA set, if the user is trying to add a new node, or if the user is modifying an existing non-voting node to make it a voter, we check to make sure the node is not electable and has priority 0 in the new config. If it doesn't, we fail the reconfig.

      If the users' reconfig ends up failing because of this check, we should have a Docs page that will guide them in their next steps. The correct procedure involves two reconfigs:

      First, do a reconfig to give the added/modified node votes: 1 and priority: 0
      Second, do another reconfig to give the added/modified node votes: 1 and priority: 1

      Both reconfigs should succeed, and the user should end up in their desired PSA config after this procedure.

      Users may also use the new rs.reconfigForPSASet() function in the mongo shell, which will issue both reconfigs automatically. It takes in 3 parameters:

      memberIndex: the index of the node being added/modified
      cfg: the desired end config
      opts: any options to run with both reconfig commands

      It is important that users should only use this function if they encounter the check added in this ticket. We will link users to the Docs page in a follow-up ticket, after it has been created.

      Thank you, and let me know if I can answer any questions!

      In a follow-up ticket, we will link to the DOCS page

      Description of Linked Ticket

      1. Consider a PSA set in config C0.
      2. We then reconfig to C1 where the "S" node has votes:0.
      3. The "S" node goes down and falls behind as the Primary accepts and commits many writes.
      4. The "S" node restarts.
      5. Now the DBA reconfigures the "S" node to have votes:1 again in C2.
      6. The "S" node gets elected with the arbiter's vote, but without all of the writes the original primary committed while "S" was down.

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              naomi.pentrel Naomi Pentrel
              Reporter:
              backlog-server-pm Backlog - Core Eng Program Management Team
              Participants:
              Last commenter:
              Naomi Pentrel Naomi Pentrel
              Docs Reviewer:
              Andrew Feierabend Andrew Feierabend (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since reply:
                10 weeks, 1 day ago
                Date of 1st Reply: