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

Pre-Vote相关问题 #154

Open
hnwyllmm opened this issue Aug 1, 2019 · 3 comments
Open

Pre-Vote相关问题 #154

hnwyllmm opened this issue Aug 1, 2019 · 3 comments

Comments

@hnwyllmm
Copy link

hnwyllmm commented Aug 1, 2019

在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

@PFZheng
Copy link
Collaborator

PFZheng commented Aug 2, 2019

pre vote 不是 vote,vote 才是真正的投票过程。不过你说的这个 case 有一定的概率会造成活锁

@PFZheng
Copy link
Collaborator

PFZheng commented Aug 2, 2019

一直在游离,又能追上日志的节点是比较危险的,其它的情况是相对可控。jraft 这里提到通过 lease 的手段来解决这个问题,目前 braft 内部版本也在测试 lease 的功能。但是,为了更好的兼容主动 vote、transfer leader 这些功能,和 jraft 的实现略有不同,对该 case 的防御不如 jraft。
个人认为,这是一种妥协。不是所有的问题都能完美解决,有时候可以有外围介入,譬如监控、报警这样的手段。

@hnwyllmm
Copy link
Author

hnwyllmm commented Aug 2, 2019

静待patch。可以先把修改的思路介绍一下吗?

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

2 participants