在RAFT中，是否可以对日志条目达成多数共识，但该条目未提交? [英] In RAFT is it possible to have a majority consensus on a log entry but the entry is not committed?

问题描述

在官方筏网页

尽管S2 (leader)，S3和S4在日志上达成共识，为什么仍未提交term 2 index 1?我运行了几分钟，以确保所有通信都已完成.

Why is term 2 index 1 not committed despite S2 (leader) , S3 and S4 agreeing on the log? I run this multiple minutes to make sure all communication has taken place.

很奇怪，如果我再添加一个日志条目term 6 index 2，则将提交term 2 index 1.

Weirdly enough, if I add one more log entry term 6 index 2 then term 2 index 1 will be committed.

有人知道阻止term 2 index 1提交的规则是什么吗?

Does anyone know what is the rule that is preventing term 2 index 1 to be committed?

推荐答案

您的领导者在第6学期中，但没有任何日志条目来自第6学期；这会在Raft中调用一条特殊规则.领导者不会自动提交上一个学期的条目，因为在某些情况下这样做是不安全的. 5.3和5.4节详细讨论了这一点(另请参见图8).

Your leader is in term 6, but none of the log entries are from term 6; this invokes a special rule in Raft. The leader does not auto-commit an entry from a prior term because in some situations it is unsafe to do so. Sections 5.3 and 5.4 talk about this in length (See also Figure 8).

从5.4.2节开始:

为消除如图8所示的问题，筏 决不通过计数提交以前条款的日志条目 副本.仅来自领导者当前的日志条目 该期限是通过计算副本数来确定的；一旦进入 从当前任期开始就是这样 那么所有先前的条目都是间接提交的，因为 日志匹配属性.有一些情况 领导者可以安全地断定较旧的日志条目 已提交(例如，如果该条目存储在每个 服务器)，但Raft采用了更为保守的方法 为简单起见

To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas. Only log entries from the leader’s current term are committed by counting replicas; once an entry from the current term has been committed in this way, then all prior entries are committed indirectly because of the Log Matching Property. There are some situations where a leader could safely conclude that an older log entry is committed (for example, if that entry is stored on every server), but Raft takes a more conservative approach for simplicity

您的示例已完美设置，可以说明为什么这样做不安全.假设S2 确实提交了，然后通过将两个东西提交到同一插槽中来破坏它.

Your example is perfectly set up to show why this is unsafe. Let's assume that S2 does commit and then we'll break it by committing two things into the same slot.

1. S2提交插槽1(本地).
2. S2发送AppendEntries(commitIndex=1, []).
3. S3接收并应用AppendEntries(commitIndex=1).
   • 2现在已在两个主机上提交.
   • 其他主机未收到该消息.

1. S2 commits slot 1 (locally).
2. S2 sends AppendEntries(commitIndex=1, []).
3. S3 receives and applies AppendEntries(commitIndex=1).
   • 2 is now committed on two hosts.
   • The other hosts do not receive the message.

• S1是更先进的日期"比任何其他日志(§5.4.1)与易胜选举.

• 领导者要做的第一件事是使所有其他日志看起来像自己的日志.

• 这将覆盖插槽1中的值2.

• 我们已经破坏了它！两个已提交的值

• We've broken it!! Two committed values

• 我们已将其加倍破坏，丢失了已提交的数据！
• 一个好的工程师会在这里提出一个断言来捕捉这种覆盖.

发生了什么事?从本质上讲，我们为同一位置选择了两位不同的领导者. (当S1是最新的时，S2被选为领导人.)

What happened? In essence, we elected two different leaders for the same slot. (S2 was elected leader when S1 was more-to-date.)

那么，为什么领导者不用等待后续请求就提交自己的任期条目是安全的?因为不可能进入上述情况.让我们考虑以下情况:两个节点(S2，S1)分别在术语2和3中认为它们同时是领导者.如果S2准备好将2提交到插槽1中，则多数在此具有相同的值.这意味着，没有多数人在插槽1中本装置S1投票对于具有较高术语另一个什么，当选领导者术语3，必须具有在插槽1中.

Why then is it safe for a leader to commit an entry of its own term without waiting for a follow-up request? Because it is impossible to get into the above situation. Let's consider the case where two nodes (S2, S1) think they are the leader simultaneously in terms 2 and 3 respectively. If S2 is ready to commit 2 into slot 1 then a majority have the same value there. This means no majority had voted for another anything with a higher term in slot 1. This means S1, to be elected leader for term 3, must have 2 in slot 1.

(顺便说一句，我花了一分钟时间才弄清楚您是如何陷入这种情况的.)

(BTW, it took me a minute to figure out how you got into this situation in the first place.)

顺便说一句，Raft被推销为"Paxos的更易理解的版本".我不同意:似乎有很多(如果不是更多的话)类似的极端情况.但是，Raft的作者确实擅长使工程师易于正确实施某些实用程序.这与作者写Raft论文的方式有关.

As an aside, Raft is marketed as a "more understandable version of Paxos". I disagree: it seems to have just as many (if not more) corner cases such as these. But, the Raft author is really good at making it easy for an engineer to make a correct implementation of something practical. This has everything to do with how the author wrote the Raft paper.

这篇关于在RAFT中，是否可以对日志条目达成多数共识，但该条目未提交?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！