在牛皮纸第 5.4.2 节
如果领导者在提交条目之前崩溃，未来的领导者将尝试完成复制条目。但是，领导者不能立即断定上一任期的条目一旦存储在大多数服务器上就已提交。可能存在这样一种情况，即旧的日志条目存储在大多数服务器上，但仍可能被未来的领导者覆盖。
作者提到为了避免上述情况
为了消除图 8 中的问题，Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交；一旦以这种方式提交了当前术语中的条目，则由于日志匹配属性，所有先前的条目都将间接提交。
但是不会还是会出现同样的问题吗？
鉴于作者提供的以下情况
当S5被选为领导者时，它只查看其当前提交的日志，(term3, index1)这将覆盖term2所有追随者中的条目。
让领导者查看自己的提交日志如何解决问题？
阅读这张图片上的标题。(d) 和 (e) 都是对 (a)、(b) 和 (c) 生成的日志状态的可能解决方案。问题是，即使在 (c) 中条目 (2, 2) 被复制到集群的大多数成员，这说明当在 (d) 中选择 S5 时它仍然可能被覆盖。因此，解决方案是只允许节点提交他们自己任期内的条目。换句话说，在大多数节点上复制条目不等于承诺。在 (c) 中，条目 (2, 2) 被复制到集群的大多数成员，但是因为它不在领导者的任期内（至少 4 个），所以它没有被提交。但是在 (e) 中，在领导者从其当前任期 (4) 中复制了一个条目之后，这防止了 (d) 中的情况发生，因为 S5 不能再被选举为领导者。
如果我们允许提交上一个任期的条目，则在之后(c)，编号的条目2将被提交。之后，如果3被选为领导者，它将覆盖已提交的2. 因此，S5和S1将执行不同的命令。为了防止这种情况，我们将不允许2提交。因此，在所有状态机中执行的命令将变得一致。
我认为图 8 (d) 和 (e) 中的两种情况在 Raft 中都是合法的，因为论文说：
为了消除图 8 中的问题，Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交。
在图 8(d) 中，term 2 的条目不在领导者 S5 的本地日志中，并且它们没有提交到状态机。可以用 term 3 的条目覆盖它们。通过计算副本的数量，只有领导者当前日志中的条目才有资格被视为已提交。
在 S1 复制条目 4 后，其任期比 2 和 3 更高。 S5 将不再被选为领导者，因为 Raft 的领导者选举策略：
Raft 通过比较日志中最后一个条目的索引和期限来确定两个日志中哪个更新。如果日志具有不同术语的最后条目，则具有较晚术语的日志是最新的。如果日志以相同的期限结束，那么无论哪个日志较长，都是最新的。
因此，在我看来，(e) 中附加的日志条目 4 隐含地提升了它之前的所有条目的术语。因为我们只关心term或者最后一个entry，而不是entry 2。
这就像提议者在 Paxos 阶段 2 中所做的一样：
如果提议者从大多数接受者那里收到对其准备请求（编号为 n）的响应，那么它会向这些接受者中的每一个发送一个接受请求，以获取编号为 n 且值为 v 的提议，其中 v 是最高-响应中的编号提案，或者如果响应报告没有提案，则为任何值。
也就是说，建议学习值 2 具有更高的建议数。
我认为问题是领导者在少数追随者将日志应用到状态机后崩溃了。图中（c）中，Leader已经将term 2的日志复制到了一半以上的节点上，然后Leader更新commitIndex为2并发送心跳。而在leader crash之前，只有S2收到心跳并将term 2的日志应用到状态机。根据论文，S5可以通过S3和S4的投票成为新的leader，并尝试将term 3的日志附加到S2 〜S4。但是，这个操作不应该被允许，因为 S2 已经将索引 2 处的日志应用到状态机。似乎 Raft 没有涵盖这种情况