当我在这种情况下采用 Raft 的 "never commits log entries from previous terms by counting replicas" 规则时，这会导致真正的问题吗？

Question

我目前正在自己​​实现Raft共识算法，遇到如下问题。 考虑有 4 个节点（A、B、C 和 D），因此可以提交超过 2 票的日志条目。现在我们启动集群并用 term = 0 选出 Leader A。然后会发生以下事情：

1. 关注者 B/D 断开连接。
2. 领导者 A 创建 LogEntry X.
3. Leader A 尝试复制到所有节点并最终失败，因为只有 2 个节点（A 和 C）。
4. Node B重连超时，开始新的选举term = 1。
5. 节点 A 失去了领导地位，因为它收到了节点 B 的 RequestVote RPC。
6. Node B can't win the election, because it has no LogEntry X. So there are no Leader in the cluster.
7. 节点超时并再次选举为领导者。
8. 领导者 A 成功复制 LogEntry X 给 B。

9. 现在节点A/B/C有完全相同的LogEntry X，即(index = 0, term = 0)。然而，根据 Raft 论文，Leader A 不能提交 X，尽管它是它自己生成的并且多数人同意 X。

   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;

10. 假设客户端不再有 LogEntry 需要复制，所以 LogEntry X 保持未提交状态。

我的问题是：

1. 这是一个真正的问题吗？
2. 有什么解决办法吗？ 事实上，已经有一些关于 SoF 的帖子强调了这条规则的重要性。在这个 post 中，似乎说我们可以创建 X 的副本 Y，并复制 Y。它是否有效或者是否存在通用解决方案？

Answer 1

1. 否

2. 是的。在第 13 页的 raft 纸中，您有以下内容：

The Leader Completeness Property guarantees that a leader has all committed entries, but at the start of its term, it may not know which those are. To find out, it needs to commit an entry from its term. Raft handles this by having each leader commit a blank no-op entry into the log at the start of its term

在您的情况下，在第 7 步之后，A 将创建一个 NoOp 日志条目，它将成功复制它，提交它，因此所有以前的条目都将被提交。