We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
在PreVote的逻辑中,节点使用current_term+1发起投票,其它的节点判断如果PreVote的request.LogId >= this.LogId就投票。考虑这样的场景: 3个节点ABC,A leader, B和C是follower。某个时间段,C与AB网络隔离,C发起PreVote,当ABC网络恢复时,A和B会投票给C,那么C就会elect_self,进而成为主。
请参考修复PreVote流程的疑似bug
The text was updated successfully, but these errors were encountered:
pre vote 不是 vote,vote 才是真正的投票过程。不过你说的这个 case 有一定的概率会造成活锁
Sorry, something went wrong.
一直在游离,又能追上日志的节点是比较危险的,其它的情况是相对可控。jraft 这里提到通过 lease 的手段来解决这个问题,目前 braft 内部版本也在测试 lease 的功能。但是,为了更好的兼容主动 vote、transfer leader 这些功能,和 jraft 的实现略有不同,对该 case 的防御不如 jraft。 个人认为,这是一种妥协。不是所有的问题都能完美解决,有时候可以有外围介入,譬如监控、报警这样的手段。
静待patch。可以先把修改的思路介绍一下吗?
No branches or pull requests
在PreVote的逻辑中,节点使用current_term+1发起投票,其它的节点判断如果PreVote的request.LogId >= this.LogId就投票。考虑这样的场景:
3个节点ABC,A leader, B和C是follower。某个时间段,C与AB网络隔离,C发起PreVote,当ABC网络恢复时,A和B会投票给C,那么C就会elect_self,进而成为主。
请参考修复PreVote流程的疑似bug
The text was updated successfully, but these errors were encountered: