问题标签 [raft]

如果 TiDB 中的一个 leader 节点宕机了，我的数据会丢失或者服务会受到影响吗？服务恢复需要多长时间（即重新选举新的领导者）？

当我在 docker 上运行 ipfs-cluster 时，它不起作用。

我使用了 docker-compose。

上面是我执行它时的 docker-compose 文件。

码头工人撰写文件

日志

ipfspeerconfig_ peer-1_1 以代码 0 退出

当我看到日志时，raft 发生了错误。有什么问题？

假设 5 个节点的网络使用 RAFT 共识协议。每个节点维护一个事务日志，该日志由日志条目列表组成。每个日志条目再次由索引和术语组成。他们都被标记为领导候选人并发送请求投票（任期，索引）。所有领导候选节点的当前日志条目（即术语和索引值列表）如下 -

那么谁会是领导者呢？

我一直在https://youtu.be/vYp4LYbnnW8?t=3244观看 Raft 算法视频，但不清楚一种情况。

在任期 4 的领导者选举中，如果节点 s1 在 s3 之前广播 RequestVote，那么节点 s2、s4 和 s5 会投票给它，而 s3 不会。然后节点s3向其他人广播RequestVote，它如何获得其他人的投票？

我能弄清楚的处理这种情况的一种可能方法是：

1. 如果节点 s1 收到 s3 的拒绝，发现 s3 的日志比自己更新，即使获得多数票也不将自己设置为领导者
2. 至于其他节点，他们会记住他们投票的leader信息，如果有新的投票请求（更大<lastTerm, lastIndex>），他们会投票给更大的节点<lastTerm, lastIndex>。

在这两种情况下，最终节点 s3 都会获得所有其他人的投票，并将自己设置为领导者。我不确定我的猜测是否正确。

Raft 将时间划分为任意长度的项，如图 5 所示。项用连续的整数编号。每个任期都以选举开始，其中一个或多个候选人尝试成为第 5.2 节所述的领导者。If a candidate wins the election, then it serves as leader for the rest of the term. 在某些情况下，选举会导致分裂投票。在这种情况下，任期将在没有领导者的情况下结束；一个新的任期（新的选举）将很快开始。Raft 确保在给定的任期内最多有一个领导者。

术语在 Raft 中充当逻辑时钟 [14]，它们允许服务器检测过时的信息，例如过时的领导者。Each server stores a current term number, which increases monotonically over time.

从这篇论文中，我们了解到任期以选举开始并单调递增。

我的问题是什么时候会增加任期？

1. 超过物理时间会增加吗？例如每分钟或每小时。

2. 它与逻辑时间有关吗？

3. 只有在新选举发生时才会增加吗？

4. 术语更改频率如何？

5. 一个任期内会产生多少个日志条目？

5.6 时间和可用性

领导者选举是 Raft 中时机最关键的方面。只要系统满足以下时序要求，Raft 就能够选举并维持一个稳定的领导者：

broadcastTime ≪ electionTimeout ≪ MTBF

作者在这篇论文In Search of an Understanding Consensus Algorithm中引用了一个概念“MTBF” 。

MTBF 代表什么？

根据 RAFT 论文，它提到除了领导服务器之外的每个服务器都有自己的日志条目及其状态机，每个状态机处理来自日志的相同命令序列。

我对这种情况很少有疑问。

[1] 如果 1 个客户端向领导服务器发出一些请求，这意味着所有跟随服务器都处理请求并产生输出？但是谁用输出与客户端进行通信呢？

[2] 如果第一个问题的答案是只有领导者将输出传回给客户端，那么多个追随者在其状态机中从日志条目计算/处理相同输入的用途是什么。因为已知 RAFT 确保所有日志条目必须包含相同顺序的相同命令。仅领导者在其状态机中处理来自日志的条目并将其返回给客户端就足够了吗？

[3] 此外，如果有多个客户端向服务器发出相同的请求，是只有领导者将输出传达给所有客户端还是跟随者在这里出现？

在 raft 论文中提到集群配置是使用复制日志中的特殊条目存储和通信的。

[1] 这里的特殊条目是什么意思？每台服务器的条目中是否都有关于集群中其他服务器总数的信息？如果不是，那么候选人如何确定它收到了多数票？

[2] 还有谁通知领导者配置变化？集群中添加的新服务器是否通过这些特殊条目进行通信？如果新服务器这样做，我的理解是正确的：“当新服务器添加为非投票成员时，它会了解当前配置并增加其日志条目中的服务器计数并向领导者发送请求以更改其配置？”

对于实现木筏的系统，如果领导者节点下降到领导者下降的时间和新的领导者的选举，则日志写作请求到达，那么它是否成功还是在此期间无法使用系统？

正如论文中介绍的，我们使用空的 AppendEntries RPC 进行心跳。那么 RequestVote RPC 呢？当 FOLLOWER 或 CANDIDATE 收到 RequestVote RPC 调用时，是否也要重置选举超时？为什么或为什么不这样做？
我认为的一个好处是，当 RequestVote RPC 调用也被视为心跳时，我们可以潜在地防止多个候选条件。由于多个候选人可能会分裂选票并在选举阶段花费更长的时间。通过将其用作心跳，来自一个候选人的 RequestVote RPC 调用将重置选举计时器，以便其他实时对等方不太可能超时并成为候选人。