Page History

...

• operation reconfig(M’)
  1. If no quorum of M’ is connected or the connected quorum is too far behind M return failure
  2. If leader(M) is in M’, designate leader(M) to be leader(M’)
  3. Otherwise, designate the most up-to-date server in connected quorum of M' to be leader(M’)
  4. Schedule the reconfiguration last in the queue of operations
     Phase 1:
  5. New operations (received by leader(M) during phase-1) will be sent to both M and M', s.t.:
     1. No commits are sent by leader(M) to members(M')
     2. Client submitting the operation can be acked as soon as either one of the following happens:
        • a quorum of members(M) acks the operation
        • phase-2 completes
  6. send <reconfig-start, version(M), M’> to members(M)
  7. wait for <reconfig-start-ack> from quorum of members(M)
     Phase 2:
  8. Stop processing new operations, return failure for any further ops received
  9. send <activate-config, M’, leader(M’) > to members (M’)
  10. wait for <activate-config-ack> from quorum of members (M’)
      Phase 3:
  11. send <retire M> to members(M)

...

• upon receipt of <activate-config, M’, leader(M’)> in configuration M’
  • start serving operations in M’
    • the first operation should clean up any incomplete reconfig request from M’
  • send <activate-config-ack< to leader(M)ack> to leader(M) and to leader(M')

• upon receipt of <activate-config-ack> from quorum of members(M'), leader(M') does the following:
  • commit all operations sent by leader(M) to members(M') during phase-1.

• upon receipt of <retire, version(M)>
  • garbage-collect M

...