选举和日志复制不能保证每一个状态机会按照相同的顺序执行相同的指令。例如，一个Follower可能处于不可用状态，Leader提交了多个日志条目，Follower恢复（尚未与Leader达成一致）而Leader故障；如果该Follower被选举为Leader并且覆盖这些日志条目，就会出现问题，即不同的状态机执行不同的指令序列。
新增选举限制保证任何的Leader对于给定的任期号（Term），都拥有之前任期的所有被提交的日志条目（所谓Leader的完整特性）。

选举限制

在所有基于Leader机制的一致性算法中，Leader都必须存储所有已经提交的日志条目。
Raft日志条目的传送是单向的，只从Leader传给Follower，并且Leader从不会覆盖自身本地日志中已经存在的条目。
Raft使用投票的方式来阻止一个Candidate赢得选举，除非这个Candidate包含了所有已经提交的日志条目。Candidate为了赢得选举必须联系集群中的大部分节点。这意味着每一个已经提交的日志条目肯定存在于至少一个节点上。如果Candidate的日志至少和大多数节点一样新，那么它一定持有了所有已经提交的日志条目。投票请求的限制中请求中包含了Candidate的日志信息，然后投票人会拒绝那些日志没有自己新的投票请求。
Raft通过比较两份日志中最后一条日志条目的索引值和任期号，确定谁的日志比较新。如果两份日志最后条目的任期号不同，那么任期号大的日志更加新。如果两份日志最后的条目任期号相同，那么日志比较长的那个就更加新。

提交之前任期内的日志条目

如果一个Leader在提交日志条目之前崩溃了，继任的Leader会继续尝试复制这条日志记录。一个Leader不能断定被保存到大多数Follower上的一个之前任期里的日志条目就一定已经提交了。
只有Leader当前任期里的日志条目通过计算副本数目可以被提交；一旦当前任期的日志条目以这种方式被提交，那么由于日志匹配特性，之前的日志条目也都会被间接的提交。
当Leader复制之前任期里的日志时，Raft会为所有日志保留原始的任期号。随着时间和日志的变化，日志仍维护着同一个任期编号。该策略使得新Leader只需要发送较少日志条目。