ELECTION: start / stop elections based on view changes

jgroups-extras / jgroups-raft

Implementation of the RAFT consensus protocol in JGroups

https://jgroups-extras.github.io/jgroups-raft/

Apache License 2.0

261 stars 83 forks source link

ELECTION: start / stop elections based on view changes #20

Closed belaban closed 2 years ago

belaban commented 9 years ago

Raft [1] duplicates some of the JGroups functionality: the goal of this issue is to remove that duplication and use JGroups wherever possible, e.g. for heartbeats and election kickoffs. Also, cluster membership changes as described in ch. 4 of [1] should be simple to implement with this change. Examples:

When a view size drops under majority, the leader steps down
When a view size reaches majority members, start the election process. When a leader has been chosen, stop the election timer
When a leader is not in the next view, start an election

Advantages:

No constant heartbeating, this is done by JGroups anyway
Easy addition of members which would change majority
No need to mark views as special entries in the log

Details are in [2].

[1] https://github.com/ongardie/dissertation [2] https://github.com/belaban/jgroups-raft/blob/master/doc/design/Election.txt

ongardie commented 9 years ago

No need to mark views as special entries in the log

Can you explain? I think you still need this for dynamic membership changes. Or does JGroups provide some persistent storage that makes it unnecessary?

https://github.com/belaban/jgroups-raft/blob/master/doc/design/Election.txt

That link's broken.

belaban commented 9 years ago

Give me a few days to complete the design document (it's on a separate branch), and I'd be happy to get your feedback. Once I have the full algorithm down, I'll try to model this in PlusCal/TLA+ to see if the model check reveals issues with this.

ongardie commented 9 years ago

@belaban sounds good, looking forward to seeing it.

belaban commented 9 years ago

Need to rethink this; as https://github.com/belaban/jgroups-raft/issues/21 changed things slightly.

bwzhang2011 commented 7 years ago

@belaban, any update with such issue ? we're looking forward to some raft implementation, hope 0.4 released not long in the future with those issues fixed and completed.

belaban commented 7 years ago

Sorry, but jgroups-raft has been dormant for a while now, and I don't expect to be able to spend much time on it in the near future.

valdar commented 5 years ago

Hi @belaban, this is pretty much what we discussed over IRC, were you able to finish the PlusCal/TLA+ modelling?

belaban commented 5 years ago

Hi @valdar Andrea: nope

belaban commented 2 years ago

OK, I finally changed this to take advantage of JGroups views:

An election is started only on a view change, by the coordinator
When the majority is reached, the coord solicits votes from all members
The member with the highest term (longest log) wins and becomes leader
If all logs are equal, then the leader is the oldest member (the coord)
Details are in [1]

This has a few advantages:

No election / heartbeat timers -> no concurrent elections and no constant traffic to prevent followers from becoming candidates
As a matter of fact, Candidate has been removed: we only have Leaders and Followers

The outcome should be the same as the original Raft election algorithm.

[1] https://github.com/belaban/jgroups-raft/blob/master/doc/design/Election.txt