Introduce Follower Replication

[Fullstop000]

trafficstars

Relate to https://github.com/tikv/raft-rs/pull/249 Signed-off-by: Fullstop000 [email protected]

[siddontang]

can you paste your previous benchmark results here, so others can see the benefit intuitively.

[Fullstop000]

@siddontang I'll make a more concrete benchmark for this. Some previous results are hard to explain why. But I'm ok to post them here :).

[Fullstop000]

@abbccdda A node in a group will send its group_id in msg and the receiver will update the sender's group info based on it. The leader only picks a delegate when the group info is enough. In a rolling-upgrade/downgrade situation, This can introduce several cases:

Upgrade

• If only the leader uses follower replication, it can only know the group info until followers finish upgrading and send their group_id so that the leader uses origin log replication at this point
• If only a follower or part of them use follower replication, the leader will just ignore the group_id in the msg so no delegate will be picked and origin log replication keeps processing

Downgrade

• If only the leader use origin log replication, the case is just like common raft cluster and nothing special happens (pick a delegate, broadcast appends)
• If a follower is downgraded and stop informing the leader its group_id, the leader will remove it from the group system and send entries directly to it

By such a design, the compatibility can be guaranteed when nodes in the cluster use either origin log replication or follower replication

It seems this feature description is missing in the RFC. I'll add it soon.

[abbccdda]

@Fullstop000 Thanks for the reply. It would be good to add such details to RFC for sure :)