You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, I want to say that NuRaft is an excellent and inspiring implementation of the Raft consensus algorithm! It's a fantastic project that has greatly informed my own work.
I am currently experimenting with the leader election mechanism in NuRaft, specifically with the recent improvements that involve priority-based leader selection. I’ve come across a scenario that I would like to get some clarification on, as it may pose a challenge under certain conditions.
Scenario:
We have a five-node Raft cluster with nodes A, B, C, D, and E.
Node A is the current leader, and nodes B, C, and D all have a priority of 0, while node E has the highest priority at 0.9.
Node A fails, and it had previously synchronized logs with B, C, and D but not with E.
At this point, node E, with the highest priority, attempts to initiate a leader election. However, E’s logs are not up-to-date with the Raft safety guarantees (as it didn’t receive logs from A).
Nodes B, C, and D, having priority 0, are not able to initiate an election. Thus, they cannot vote for node E since their priorities are lower than E’s target priority.
The Question:
Given this situation, the key issue seems to be that although node E has the highest priority, it might not be able to get elected due to its logs not being consistent with Raft’s safety rules.
The mechanism for reducing the target_priority over time seems to be crucial here. Specifically, I wonder if there’s a risk that the target_priority might eventually reach 0, which would prevent further election attempts.
However, as per my understanding of the proposed mechanism, the target_priority should not drop below 1. Could you please confirm if this is the intended behavior, or if there are any edge cases where target_priority might inadvertently drop to 0?
Conclusion:
I would greatly appreciate any insights or clarification on this issue. It would be helpful to understand how the priority-based leader election mechanism ensures progress in such scenarios, especially when some nodes are not eligible for elections due to their low priority.
Thank you for your time and for the amazing work on NuRaft. Looking forward to your guidance.
Best regards.
(I am not a native English speaker, so my expression may have confused you. I am very sorry for this)
The text was updated successfully, but these errors were encountered:
First of all, I want to say that NuRaft is an excellent and inspiring implementation of the Raft consensus algorithm! It's a fantastic project that has greatly informed my own work.
I am currently experimenting with the leader election mechanism in NuRaft, specifically with the recent improvements that involve priority-based leader selection. I’ve come across a scenario that I would like to get some clarification on, as it may pose a challenge under certain conditions.
Scenario:
The Question:
target_priority
over time seems to be crucial here. Specifically, I wonder if there’s a risk that thetarget_priority
might eventually reach 0, which would prevent further election attempts.target_priority
should not drop below 1. Could you please confirm if this is the intended behavior, or if there are any edge cases wheretarget_priority
might inadvertently drop to 0?Conclusion:
I would greatly appreciate any insights or clarification on this issue. It would be helpful to understand how the priority-based leader election mechanism ensures progress in such scenarios, especially when some nodes are not eligible for elections due to their low priority.
Thank you for your time and for the amazing work on NuRaft. Looking forward to your guidance.
Best regards.
(I am not a native English speaker, so my expression may have confused you. I am very sorry for this)
The text was updated successfully, but these errors were encountered: