mransan / raft Goto Github PK

Currently the LeaderState is a list of index. A subset of operations are querying this data structure by receiver id so it would make sense to use map. So far we only have a very limited number of servers so not worth it.

This is a duplicate of the data and therefore harder to maintain in the long run. Duplication means bugs.

Add unit test for #19

Raft_logic.Message.handle_message and Raft_logic.Message.handle_timeout should be able to return notification. For instance:

• New_leader (leader id)
• No_more_leader
• New_commit_index (from, to)

Right now we have 3 distinct piece of date per follower in the leader state:

• match index
• next index
• connection

They could all be consolidated.

• Ti commit_index = x , prev_log_index x + 10
• Ti+1 request with leader_commit = x + 20 , and 100 logs added
• Ti+2 commit_index = x + 20, prev_log_index x + 110
• Ti+3 duplicate of Ti+1 request

• We can see now that commit_index > prev_log_index

The data in the LogEntry is not enough. We should also add a client_id field to map the index (which is internal to the RAFT protocol) back to a client identifier. This is necessary for a RAFT application to know which data was appended to the log after it was commited.

Logs can be stored permanently by the client application. This is needed in order to be able to handle a very large number of logs.

One possible design which would keep this library pure computation is to modify the LogInterval type used in the global_cache.

Current version

message LogInterval {
  required int32    prev_index      = 1; 
  required int32    prev_term       = 2; 
  repeated LogEntry rev_log_entries = 3;  
  required int32    last_index      = 4;
}

Proposition

message LogInterval {
  required int32    prev_index      = 1; 
  required int32    prev_term       = 2; 
  required int32    last_index      = 4;
  message Compacted { } 
  message Expanded   {
    repeated LogEntry rev_log_entries = 1;  
  }
  oneof data {
    Compacted compacted = 5;
    Expanded   expanded   = 6;
  }
}

The client application would then be able to compact certain log interval. The major difficulty is in the recovery scenario (ie when a follower is lagging behind drastically). When computing the AppendEntries request the leader will find out tha the logs have been compacted. One possible solution is to augment the interface with the application to indicate that loading the data should happen.

• Leader.add_logs
• Merge log logic in Raft_logic.handle_append_entries_request

https://github.com/mransan/raft/blob/master/src/raft_role.ml#L179

It's likely that this iteration would need to go into the global cache to find the last_log_index. Right now it's only looking at the state.log