1

I want to elect a leader from a number of identical processes. All the explanations of Paxos say that some processes are Proposers, some are Voters and some are Accepters. Do I need to assign these roles to my processes when I launch them?

What if all my proposers die? Can I switch existing learners/voters to proposers?

The way I thought about this is that all processes come up as voters and then wait with random timeout for messages. If they don't get any message until the timeout expires, they assume the role a proposer. If they receive a message, they kick of another timeout and then can become a proposer again if they don't receive any more messages until the timeout ends (or they have an agreement).

Is that a valid approach?

gruszczy
  • 40,948
  • 31
  • 128
  • 181

1 Answers1

0

I am a maintainer of several production paxos systems. I'll detail what I have seen in mine and other practical/production systems.

All the explanations of Paxos say that some processes are Proposers, some are Voters and some are Accepters. Do I need to assign these roles to my processes when I launch them?

In a practical system the proposers and accepters are the same set of nodes. That is, proposer and acceptor are two roles taken on by the same process.

What if all my proposers die?

Many Paxos systems (such as those used as kv stores) work on a sequence of paxos instances (like a transaction log). It is infeasible to assume that the same set of processes will live forever, so there must be mechanisms to change the set of nodes in the quorum.

In some of the systems I maintain there are two parts to the proposed/chosen value: the payload from the customer and the paxos membership. The paxos round is run by the quorum chosen in the prior value. Doing it this way does impede the ability of your system to pipeline the values chosen; you'll have to batch them instead if you want choose multiple values at once—or you can look at the way Raft chooses membership.

In Raft choosing quorum members is a two-phase process. First, the new quorum is proposed and committed; both quorums are used for a while; and then the new quorum takes over. Specifically, in the interim a majority of both the old and the new quorums is required to commit anything, including the take-over from the new quorum.

Michael Deardeuff
  • 10,386
  • 5
  • 51
  • 74
  • I have trouble understanding the second part of your answer. Are you describing a system where new instances can come/leave the system while it's operating? How will existing instances know to send messages to new instances, if they don't know they existed before? Would you be so kind and show an example of a system and a behavior? – gruszczy May 31 '18 at 17:04