A quorum check before becoming a candidate

[Alex Goltman]

Hi,

I would like to add a phase before becoming a candidate - pinging other members. Only if a quorum of them answer become a candidate and increase the term.

The problem I'm trying to solve is unnecessary leader changes. For example when a member gets disconnected, its election timeout will expire, it will become a candidate and increase its term as part of it:

• On conversion to candidate, start election:

  • Increment currentTerm 

Even though that while being disconnected it has not chance of becoming a leader. After some time it will become connected again, and once the leader will send it a heartbeat, the leader will receive in the reply the higher term and will be forced to step down according to the paper: 

• If RPC request or response contains term T > currentTerm: set currentTerm = T, convert to follower (§5.1) 
  

That can be considered a hiccup in raft, but in my case a leader change has consequences in the system level the raft is part of.

What do you think of this? Could it cause unavailability or other issues?

Thanks,

Alex

[patrick chan]

Hi,

there is a much discussed optimization for this issue called pre-voting:

https://groups.google.com/forum/#!searchin/raft-dev/pre-vote/raft-dev/Lny9nyjyokI/S-gbY6d6m-AJ

I think that's what you're looking for.

cheers,

pat

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Archie Cobbs]

Actually pre-vote and "majority ping" are slightly different.

Majority ping is a little simpler at the expense of not helping in certain edge cases.

This post describes my attempt at adding majority ping to JSimpleDB. This is implemented now and working well.

-Archie

[jordan.h...@gmail.com]

So, to be clear you're talking about merely contacting a majority of servers, but not necessarily verifying that the server that wants to become a candidate can be elected, right? Not to sound like a broken record, but doesn't the pre-vote protocol cover this? I mean, getting a majority of votes during the pre-vote phase also implies the server can reach a majority of members, and pre-vote will fail if either a majority can't be reached or if votes aren't received from a majority. So, if pre-vote covers this (since a majority must be contacted to receive a majority of votes) what's the reason for wanting to implement this but not pre-vote? You mentioned simplicity? Is it that much simpler than implementing the pre-vote protocol? Implementing the pre-vote protocol is pretty trivial. After all, presumably the logic for granting votes is already present in your implementation and should be reusable if it's designed well.

As for availability, I think if the pre-vote protocol implies "majority ping," and if the pre-vote protocol is assumed to be safe, you can assume "majority ping" is safe.

Jordan Halterman

--

[Alex Goltman]

The pre-vote looks like a sound solution. I'll implement it. Thanks everyone!