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
这样直接判断为零就填充,是否有问题, 想象一种情况,一个server从集群启动开始就挂了,然后再经历几个term之后恢复,其中还没有日志记录,但当前任期leader给他发的log默认是按照自身的log最大值发送的,而server接收到之后却直接写入了(因为没有log记录),这里应该会出现不一致吧,感觉逻辑不应该这样。这里我觉得可以直接吧m_logs为空的情况归类到preindex = m_logs.size()的情况中,即删除这段代码即可
The text was updated successfully, but these errors were encountered:
不好意思上班比较忙,晚上回去我详细看一下
Sorry, something went wrong.
不好意思上周忘记了,是没问题的兄弟,你看下第525行,leader为每个server维护的nextindex是不一样的,发出的rpc请求中的log是不一样长的,对于你说的宕机server会从0开始。
但是你在337行,每个新leader出现后,会把所有nextIndex设置为最新idx,这样在下一个appendEntry就会出现贴主说的问题。 按照原论文的实现,appendEntry应该是每次单步的情形从后向前试错的,只有在找到第一个idx和term都相同的节点才会进行append操作,所以这种一开始log.size()==0的情况我觉得好像得特化处理。
是这样的,后续论文里我记得给出了优化的方案,是快速回滚的一种方法,MIT的资料里应该也有这部分。所以我是按照那个逻辑来,具体的记不太清楚了,周末我再看一下
No branches or pull requests
这样直接判断为零就填充,是否有问题, 想象一种情况,一个server从集群启动开始就挂了,然后再经历几个term之后恢复,其中还没有日志记录,但当前任期leader给他发的log默认是按照自身的log最大值发送的,而server接收到之后却直接写入了(因为没有log记录),这里应该会出现不一致吧,感觉逻辑不应该这样。这里我觉得可以直接吧m_logs为空的情况归类到preindex = m_logs.size()的情况中,即删除这段代码即可
The text was updated successfully, but these errors were encountered: