project2B

project2B中peer storage内提到, “simply save all log entries at raft.Ready.Entries to raftdb and delete any previously appended log entries which will never be committed” 这里如何判断哪些entries是需要删除的呢?

已经append的log应该都是stable的,如果是删除所有 index > last index of raft.Ready.Entries , 为什么不等到下一次ready来了直接对已有的index进行覆盖呢?

1 个赞
  1. 需要删除的日志项是之前已经持久化到了 storage 中,但是后来可能由于新的 Leader 产生,造成了之前已经持久化的日志项实际并没有提交,因此就需要删除。举个例子:加粗是已经持久化的。S1是term=5的Leader。假如现在S2需要写日志项(index=5,term=5),那么它就需要先删除index=5及之后的日志项,然后写入新的。
    S1: 1 2 3 4 5
    S2: 1 2 3 4 4 4 4
    S3: 1 2 3 4 5
  2. 如上图S2所示,如果是直接覆盖,而不是删除,情况如下。那么这个 peer storage 就不会知道哪个是最新的结果,但到现在是没有问题的。主要问题在于,如果S2宕机后重启,那么它从 peer storage中恢复出来的日志项就存在逻辑问题,不符合Raft的日志项规则。后面还要进行日志项匹配、删除、再次(覆盖而不是删除的)写入,就比较麻烦了。
    S2:1 2 3 4 5 4 4 4

个人感觉是这个样子的。

1 个赞

因为后面写入的可能比前面的短,例如网络分区后旧leader日志过长,或者一个掉线的节点出现过长的日志。所以必须要对更长的部分进行修剪。否则节点重启的日志就不对了