Implementation of replicated state machine (raft) protocol.
Implemented:
- Leader election
- Log replication
- Cluster changes
- Log compaction (snapshotting)
Before starting a new raft server, you need to implement
raft_server
behavior.
init/0
: return with the new staring statehandle_command/2
: execute commands that can modify statehandle_query/2
: execute queries which cannot change state
{ok, Pid} = raft:start(callback_module).
raft:command(Pid, {do_stuff, Stuff}).
raft:query(Pid, {get_stuff, Stuff}).
raft:join(PidA, PidB).
raft:leave(PidA, PidB).
#{role => leader | follower | candidate,
term => 1,
leader => <0.261.0>,
cluster_members => [<0.261.0>, <0.253.0>, <0.243.0>],
log_last_index => 1923,
committed_index => 1922,
last_applied => 1922,
log => Last10LogEntry
} = raft:status(Pid)
How many times the followers wait for the heartbeat.
max_heartbeat_timeout
- rand(heartbeat_grace_time
) + heartbeat_grace_time
When electing a new leader candidates wait until this amount of time, and starts a new election.
max_heartbeat_timeout
- rand(heartbeat_grace_time
)
Leader sending heartbeats (empty append_entries_req) if nothing sent to the followers for a while.
min_heartbeat_timeout
for one heartbeat, than change to idle timeout until the next command
After one period of heartbeat leader change it's heartbeat time to this.
(max_heartbeat_timeout
-rand(heartbeat_grace_time
))
max_append_entries_chunk_size
If a follower wants to catch up, leader can send more than one command in one message.
This parameters configures the max amount of commands send in one message. default: 100
snapshot_chunk_size
After a certain amount of commands
every raft server does log compactions (create a snapshot). default: 100000
WARNING: Not yet prod ready
$ rebar3 compile