Question

我打算使用shared-nothing architecture和multiversion concurrency control制作分布式数据库系统。冗余将通过asynchronous replication实现（只要系统中的数据保持一致，就可以在失败的情况下丢失一些最近的更改）。对于每个数据库条目，一个节点具有主副本（仅该节点具有对其的写访问权），此外，一个或多个节点具有该条目的辅助副本以用于可伸缩性和冗余目的（辅助副本是只读的）。更新条目的主副本时，它会加上时间戳并异步发送到具有辅助副本的节点，以便最终获得最新版本的条目。具有主副本的节点可以随时更改 - 如果另一个节点需要写入该条目，它将请求主副本的当前所有者为该节点提供该条目的主副本的所有权，并在接收到该节点的所有权之后可以写入条目（所有事务和写入都是本地的）。

最近我一直在考虑当群集中的节点发生故障时该怎么做，以及用于故障转移的策略。这是一些问题。我希望你能知道至少其中一些的可用替代品。

在分布式系统中进行故障转移的算法是什么？
在分布式系统中有哪些算法可以达成共识？
群集中的节点应如何确定节点已关闭？
节点如何确定故障时哪些数据库条目在故障节点上具有主副本，以便其他节点可以恢复这些条目？
如何确定哪个节点具有某个条目的最新辅助副本？
如何确定应将哪个节点的辅助副本提升为新的主副本？
如果那个虽然被关闭的节点突然回来，好像什么也没发生，怎么办呢？
如何避免裂脑情况，网络暂时分成两部分，双方都认为对方已经死亡？

Answer 1

* What algorithms there are for doing failover in a distributed system?

可能不是算法，而是系统。您需要围绕您提出的问题设计您的架构。

* What algorithms there are for consensus in a distributed system?

您可能想要实施Paxos。简单的Paxos不是很难做对。如果您正在努力使其成为防弹，请阅读Google的“Paxos Made Live”论文。如果您希望高性能，请查看Multi-Paxos。

* How should the nodes in the cluster determine that a node is down?

取决于。 Heartbeats实际上是一个非常好的方法。问题是你有误报，但这是不可避免的，并且在同一局域网上具有可管理负载的集群中，它们是准确的。 Paxos的好处是可以自动处理误报。但是，如果您确实需要将故障信息用于其他目的，那么您需要确保将节点检测为失败，但实际上它只是处于负载状态并且需要时间来响应心跳。

* How should the nodes determine that what database entries had their master copy on the failed node at the time of failure, so that other nodes may recover those entries?
* How to decide that which node(s) has the latest secondary copy of some entry?
* How to decide that which node's secondary copy should be promoted to be the new master copy?

我认为您可能会从阅读Google文件系统论文中获益。在GFS中，有一个专用的主节点，用于跟踪哪些节点具有哪些块。这个方案可能对你有用，但关键是要保持对这个master的访问最小化。

如果您不将此信息存储在专用节点上，则必须将其存储在任何位置。尝试使用主持有人的ID标记数据。

* How to handle it, if the node which was though to be down, suddenly comes back as if nothing happened?

见上文，但基本点是你必须要小心，因为一个不再是主人的节点可能会认为它是。有一点我认为你没有解决过：更新如何进入主服务器 - 即客户端如何知道将更新发送到哪个节点？

* How to avoid split-brain scenarios, where the network is temporarily split into two, and both sides think that the other side has died?

Paxos在这里通过阻止完美分裂的进展来工作。否则，和以前一样，你必须非常小心。

一般来说，解决了解哪个节点获取哪个数据项作为主节点的问题，您将在修复架构方面走得很远。请注意，您不能让接收更新的节点成为主节点 - 如果两个更新同时发生会怎样？不要依赖于同步的全球时钟 - 那种疯狂就是这样。如果可以提供帮助，您可能希望避免在每次写入时都达成共识，因此可能有一个慢的主 - 故障转移协议和快速写入路径。

如果您想了解更多详情，请随时给我发邮件。我的博客http://the-paper-trail.org处理了很多这样的事情。

欢呼声，

亨利

Answer 2

你问的是一个非常大的问题，你想知道的很多东西仍在积极研究中。

一些想法：

分布式系统很难，因为没有万无一失的系统来处理故障;在异步系统中，无法确定节点是否已关闭或是否存在网络延迟。这可能听起来微不足道，但实际上并非如此。
可以通过Paxos family of algorithms达成共识，其版本在Google的bigtable和其他地方使用。

您需要深入研究分布式系统教科书（或几个）。我喜欢Tannenbaum's Distributed Systems: Principles and Paradigms

Answer 3

一个很好的博客，谈论分布式系统和分布式算法 - 包括实施Paxos - 是http://the-paper-trail.org/

Answer 4

这个问题由DEC解决了Distributed Lock Manager的VMS问题。现代解决方案基于此设计。阅读Wikipedia文章了解一些当前的解决方案。您应该查看OCFS2，它现在是Linux内核的一部分。

Answer 5

解决问题的一小部分：在您描述的场景中，没有办法决定（在摘要中）哪个节点具有最新的辅助副本。最好的情况是，一些节点可以轮询并确定（在一些通信之后）他们知道/可以看到的节点中的哪些人，以及知道/可以看到它们的那些节点，并且看不到老主人有最新的副本。但是：

他们无法找到他们无法达到的节点的状态
他们无法找到无法联系到他们的节点的状态
他们不能确定他们认为他们所知道的节点的状态，当他们不能当前时可以看到旧主节点 - 主节点可以在邻居报告状态后更新共享邻居。

在更广泛的问题上，你可能想看看像memcached这样的东西如何处理问题，特别是阅读清单，看看他们在理论遇到实践时遇到了什么问题。

分布式系统中的故障转移有哪些算法？

5 个答案: