wojiaodoubao commented on PR #943:
URL: https://github.com/apache/ratis/pull/943#issuecomment-1777098313
> How about just restarting the crashed new peer, since the network
partition has recovered and there is little likelihood of the partition
happening again in such a short period of time? If the partition does happen
again and the restarted new peer crashes again, maybe we should give up to add
this unstable peer to the new conf?
Hi @Brokenice0415 , thanks your nice comments. I think this is a good
solution. Firstly it's very simple. We don't need to change any code. Providing
an example and doc should be enough. Secondly, it's flexible. Allowing any conf
updates as described in raft paper (JOINT consensus).
I'm new to ratis and I'm worried my view might be a bit narrow. Could
@szetszwo @SzyWilliam you kindly help giving more advices on this solution
(Starting new peer with conf {C_old, peer_itself}) ?
I also considered @szetszwo 's suggestion.
> We may:
> - Support only changing from 1 peer to 2 peers in a setConf (adding more
peers require another setConf).
> - When changing from 1 peer to 2 peers, the old peer can become the leader
even if the new peer not voted for it. The > new peer can become the leader
only if the old peer voted for it.
> For the other cases, we should somehow time out the in-progress setConf.
Based on the idea, I think we can set up 2 rules:
1. Constraining configuration change behaviors. Only adding one peer and
removing one peer are allowed.
2. When changing from 1 peer to 2 peers, the old peer can become the leader
even if the new peer not voted for it. The new peer can become the leader only
if the old peer voted for it.
By rule 1, we reject all cases that may lead to infinite leader election,
except 'adding 1 new peer to a 1 peer cluster'. By rule 2, we fix the 'adding 1
new peer to a 1 peer cluster' case.
We can prove the procedure won't cause split brain and infinite leader
election. The combination of new peer and old peer configurations are shown
below.
old peer | new peer | Split brain | Infinite leader election | Leader can win
-- | -- | -- | -- | --
C_old | empty | no | no | yes
C_old_and_C_new | empty | no | no | Yes, because of rule 2.
C_old_and_C_new | C_old_and_C_new | no | no | yes
C_new | C_old_and_C_new | no | no | yes
C_old_and_C_new | C_new | no | no | yes
C_new | C_new | no | no | yes
The advantages are:
1. Allowing new peer to start with empty conf which is simple.
2. Simplifying configuration change behaviors to only 'add 1 peer' and
'remove 1 peer'.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
