我正计划使用 shared-nothing architecture 制作一个分布式数据库系统和 multiversion concurrency control .冗余将通过asynchronous replication实现(允许在发生故障时丢失一些最近的更改，只要系统中的数据保持一致)。对于每个数据库条目，一个节点具有主副本(只有该节点对其具有写访问权限)，此外，一个或多个节点还具有该条目的次要副本以用于可伸缩性和冗余目的(次要副本是只读的) .当条目的主副本更新时，它会被加上时间戳并异步发送到具有次要副本的节点，以便它们最终获得最新版本的条目。拥有主副本的节点可以随时更改——如果另一个节点需要写入该条目，它将请求主副本的当前所有者将该条目的主副本的所有权授予该节点，并在收到所有权后该节点可以写入条目(所有事务和写入都是本地的)。
最近我一直在思考当集群中的节点出现故障时该怎么办，即使用什么策略进行故障转移。这里有一些问题。我希望您至少知道其中一些的可用替代方案。
- 在分布式系统中进行故障转移的算法有哪些？
- 在分布式系统中有哪些算法可以达成共识？
- 集群中的节点应该如何判断一个节点宕机了？
- 节点应如何确定哪些数据库条目在发生故障时在故障节点上有其主副本，以便其他节点可以恢复这些条目？
- 如何确定哪个节点拥有某个条目的最新次要副本？
- 如何决定将哪个节点的副副本提升为新的主副本？
- 本以为宕机的节点突然恢复正常，若无其事怎么办？
- 如何避免脑裂场景，即网络暂时一分为二，双方都认为对方已经死了？
最佳答案
* 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?
视情况而定。心跳实际上是一个很好的方法来做到这一点。问题是您有误报，但这是不可避免的，并且在负载可管理的同一 LAN 上的集群中，它们是准确的。 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 中有一个专用的主节点，它跟踪哪些节点有哪些 block 。这个方案可能对你有用，但关键是尽量减少对这个 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 通过在完美 split 的情况下阻止进展来发挥作用。否则，和以前一样，你必须非常小心。
一般来说，解决知道哪个节点作为主节点获取哪个数据项的问题，您将在修复架构方面走很长一段路。请注意，您不能只让接收更新的节点成为主节点——如果两个更新同时发生怎么办？也不要依赖同步的全局时钟——疯狂就在于此。如果可以的话，您可能希望避免在每次写入时都达成共识，因此也许可以采用慢速主故障转移协议(protocol)和快速写入路径。
如果您想了解更多详情，请随时给我发邮件。我的博客http://the-paper-trail.org处理很多这样的事情。
干杯，
亨利
关于database - 分布式系统中故障转移有哪些算法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/620877/