Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could Low-Weight Nodes with Up-to-Date Logs Be Unfairly Disadvantaged? #569

Open
LordHumphrey opened this issue Feb 26, 2025 · 0 comments
Open

Comments

@LordHumphrey
Copy link

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant