Raft priorities in elections

[Charlie Page]

Hi Diego,

I have been working on priorities in Raft as I don't see that it the formal proof.

My idea is to use an additional timeout that is required to become a candidate (max_Raft_timeout * priority + normal_Raft_timeout).  Such that priority zero is the most likely node to be elected.  The normal Raft timeout would still work for being able to accept votes("servers disregard RequestVoteRPCs when they believe a current leader exists. Specifically, if a server receives a RequestVote RPC within the minimum election timeout of hearing from a current leader").

The candidate time out may have to be empirically adjusted to get to a point where the lowest priority server is always elected as a trade off vs election times.  If a lower priority server sees one with a higher priority is the leader it would ask the leader to step down.  As a safety check a non-leader would only ask for stepdown if it believes it can make forward process (i.e. sees a majority).

If I recall correctly though, you said somewhere that you tried but couldn't get them to work out.  Regrettably the power of google of failing me to find that (so perhaps my memory is faulty).  Have you looked at anything like this?

Is there a record of your work on priorities anywhere?  I would like to know the pitfalls of other schemes (or this one).

Thanks!

[Diego Ongaro]

Hi Charlie,

It's a bit hard to handle preferences in who becomes leader in Raft,
since only a server with an up-to-date log is eligible. That puts two
orderings on the elections at once: log up-to-dateness and priority,
and sometimes these are in conflict. You might be able to get it to
elect a leader quickly in most cases, but it seems subtle and/or
fragile. I think the text you're referring to is the last paragraph of
Section 5.2 "Leader Election" in the paper or Section 3.4 in my
thesis.

My current thoughts on this are to leave elecctions alone but, if
there are preferences on who becomes leader, to do "transfer
leadership'' from one server to another. I describe what I think would
be a good approach to this in my thesis (
http://ramcloud.stanford.edu/~ongaro/thesis.pdf ):
- Section 3.10 "Leadership transfer extension" describes the idea.
- The last paragraph of Section 5.3.3 "Disruptive servers" adds a small tweak.
- Section 11.2.2 "Selecting a new leader and ensuring it has all
committed entries" discusses it again in the context of related work.

I like this approach because it doesn't mess with normal elections at
all, but it still leverages the safety of normal elections and falls
back to a normal election in case something goes wrong.

Best,
Diego

> --
> 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.