database - 数据库中重新连接的节点如何与多数集群同步？

Question

假设一个数据库在 5 台机器上共有 5 个副本。写入数据库涉及在所有 5 台机器之间进行两阶段提交以保持一致性。

假设一台机器宕机了。然后对数据库的写入仍然可以在其他 4 个节点上运行两阶段提交，因为这仍然是大多数。

但是当宕机的机器重新启动并重新连接时，它如何同步并重新加入集群？

重新加入的机器需要获取它没有的提交日志条目。据推测，它在所有 5 台机器之间运行某种共识算法，以就它丢失的下一个日志条目达成一致。它会一直这样做，直到它 catch 丢失的提交日志条目。

但它是如何从追赶过渡到加入集群的呢？在它 catch 时，其他 4 台机器将提交大量新写入。所以它似乎永远无法真正捕捉到。

重新加入的节点是否请求集群停止处理新写入以使其 catch 。然后使用共识算法重新加入(重新加入是如何完成的？)。这似乎会导致写入处理出现严重的延迟。处理这个问题的惯用方法是什么？

Answer 1

这不是一个答案，我不知道。在评论中难以阅读。

但是。集群计算机节点有一些与分布式数据库相同的问题。数据完整性和谁做出“决定”是数据库的两个共同问题。

跨地理上不相交的集群成员(如 Solaris geocluster)进行复制在某种程度上类似于 SAN 的工作方式。如果节点 A 有数据集(例如 zfs 文件系统)，则源自节点 B 的任何更改都将存储为增量，就像快照的工作方式一样。不一定需要完全同步，因为 A 的数据集的基础加上增量 == B 的数据集。如果需要，这些工具可以在未来某个时间完全同步 A 和 B 的数据集。因此，如果 B 跟踪本地数据，然后使用来自 A 的增量更新“快照”，那么每个人都是同步的。世界是快乐的。

现在，决定。谁做三角洲的事情？ A 或 B.? A 是跟踪自己的数据集还是跟踪自己加上来自 B 的增量？在集群中，仲裁管理器决定。这是一个任意选择的负责决策的节点。实际上可能发生的情况是，每个“本地”节点都有一个唯一的数据集，然后是来自其他所有人的增量“快照”。集群需要奇数个节点才能正常运行。当节点数为偶数时，您不能拥有法定人数。 FWIW。

在地理集群中，如果阿尔伯克基的节点 A 发生故障，纽约的节点 B 几乎可以立即为节点 A 进行故障转移。那是因为 B 拥有一切。仲裁管理器决定谁在具有大量成员的集群中为谁进行故障转移，如果 C 被淹没，它还可以将应用程序负载从 C 重新分配到 D 和 E(并且其他一些条件为真，例如应用程序在 C，D 上获得许可, 和 E)

要点是:2 个节点没有相同的数据集，但它们的集体数据集的总和与等式中考虑的任何网络延迟一样大。