问题标签 [fault-tolerance]

我正在尝试一些容错和应用程序，有没有人知道使用默认 mysql 表的长时间执行查询？

想法是运行该查询，使 mysqld 崩溃以查看我的应用程序是否检测到错误并尝试连接到另一个 mysqld。

谢谢

我只是碰巧读了 Joe Armstrong 的论文，对 Erlang 没有太多的先验知识。我想知道如果某些消息的送达收据从未到达会发生什么。发送演员做什么？它会再次发送消息吗？当接收方再次收到相同的消息时，这可能会使接收方演员感到困惑。它必须能够告诉它没有收到它的收据，因此第二条消息是无效的。

这类问题总是让我远离消息传递不是事务性的解决方案。我想我知道答案：发送参与者告诉它的监督参与者，当它没有在合理的时间内获得收据时一定是出了问题，导致监督者采取了一些行动（比如重新启动参与的参与者或其他事情）。这个对吗？我认为没有其他解决方案不会导致理论上可能的无限消息发送。

感谢您的任何回答，奥利弗

处理异常时的最佳实践是什么？

我通常编写代码以避免不惜一切代价避免异常，我的代码通常有很多条件，如果我正在处理规范化的数据库，我通常会编写一堆查询来仔细检查值是否已经存在。

但是，我见过只监听异常的代码，如果发生异常，则会得到适当的处理。

在这种情况下，最佳实践是什么？

是避免错误并在它们发生之前处理它们更好，还是只捕获异常并将其引导到正确的位置？

在性能方面，我发现捕获异常更快；特别是如果涉及数据库。

但是，我觉得某些异常对于特定场景来说过于笼统，除非您看到堆栈跟踪，否则很难确定为什么会发生该异常。

也就是说，除非您有一个错误报告工具（滚动条、新遗物等）。如果您有面向客户的界面并且您收到的票证仅包含“500”字样，则特别难以在日志中找到堆栈跟踪X 页面中的错误”。

如果这个问题对于stackoverflow来说太宽泛了，请随意关闭它

Twilio 和其他 HTTP 驱动的 Web 服务具有后备 URL的概念，如果主 URL 超时或失败，Web 服务将 GET 或 POST 发送到您选择的 URL。对于 Twilio，如果后备 URL 也失败，他们将不会重试请求。我希望将后备 URL 托管在单独的机器上，这样如果主服务器关闭或无法访问，错误就不会丢失。

我想要一些次要的方法：

1. 将请求存储到后备 URL
2. 将请求重播到主服务器上稍有不同的 URL
3. 重试 #2 直到成功，然后从队列/数据库中删除请求

是否有一些现有的软件可以做到这一点？如果需要，我可以自己构建一些东西，我只是认为这将是某人已经做过的事情。我对 HTTP 和周围的工具（代理、反向代理等）不够熟悉，无法知道要搜索的正确流行语。

我有一堆长时间运行的进程连接到 Redis 服务器（使用 Jedis）。只要我不重新启动运行 Redis 的机器或重新启动 Redis 服务器，一切正常。一旦我重新启动或重新启动，连接就会丢失。在 Redis/Jedis 中是否有处理这个用例的标准方法，还是我需要自己把这个逻辑放在我所有的客户中？

我正在为 Ruby 中的实时数据分析任务开发一种算法。由于数据集相当大，瓶颈是 CPU。因此，为了达到所需的性能，我必须并行使用更多的内核，可能在不同的机器上。

我的问题是是否存在提供以下功能的现有 Ruby 库：

• 集群管理，理想情况下是无主的，具有动态重新配置（加入和离开节点）和一定程度的容错
• 将计算作业分配到（活动）节点，错误处理（作业重试等）
• 快速（直接？）通信以确保实时功能

我已经看过的东西：

• DRb：太低级，手动节点处理，没有容错？
• DCell：成熟？自动集群管理？
• Resque/Sidekiq：不错，但太慢了（轮询 Redis、休眠的工作人员，...）
• Riak Map/Reduce：不错，但不推荐用于实时查询
• Spark：复杂的东西，进取心？

最后的手段：也许对于 Ruby 没有解决方案，但对于其他平台？也许是 Java（是的，JRuby！）或 node.js。

我在 Amazon EC3 平台上进行计算，使用通过 OpenMPI 连接的多台机器。为了降低计算成本，使用了现场实例，当机器的成本超过最大预设价格时会自动关闭：http: //aws.amazon.com/ec2/spot-instances/。发生了一个奇怪的行为：当一台机器关闭时，MPI 通信器中的其他进程仍然继续运行。我认为在进程有时间向其他进程指示它已收到终止信号之前，网络接口已被静音。

我在多篇文章中读到 MPI 没有提供很多关于容错的高级资源。另一方面，我的程序的结构很简单：一个主进程被从进程查询，以获得执行部分代码的权限。主进程只跟踪它已回复的查询数量，并在达到上限时告诉从属进程停止。从站之间没有耦合。

如前所述，我希望能够检测到进程何时静默死亡。在那种情况下，我会将他所做的工作重新归因于一个还活着的奴隶。有没有简单的方法来检查是否死亡？我曾想过使用线程和套接字独立于 MPI 层的其余部分来执行此操作，但这似乎很麻烦。我还考虑在主进程（在非现场实例上启动）维护与每个进程的最后一次通信时间的列表，并指定超时，但这并不能保证我的从进程已经死了。还有一个问题是“barrier”和“finalize”函数不会看到所有的进程，并且可能会挂起。

那么我的问题是你会实施什么样的解决方案来检测进程是否静默死亡？您将如何修改其余代码以与减少的进程数兼容？

我想使用分布式容错系统存储数百万张图像。虽然从未推荐将图像存储在关系数据库中，但我想知道这是否是在 NoSQL 数据库中存储和管理图像文件的合适方法。

如果您能在这里详细分享您的经验，我将不胜感激。（即您使用了什么 NoSQL 数据库？在这种情况下它的优点和缺点等）

谢谢

背景：

在Lamport 的论文Paxos Made Simple的第 3 节，命名为实现状态机，描述了 Multi-Paxos。Google Paxos Made Live中使用了 Multi-Paxos 。（在Apache ZooKeeper中使用了 Multi-Paxos）。在 Multi-Paxos 中，可能会出现间隙：

一般来说，假设一个领导者可以α提前获得命令——也就是说，它可以在命令 1 到命令被选择之后i + 1通过命令提出命令。然后可能会出现最多命令的间隙。i + αiα - 1

现在考虑以下场景：

整个系统采用主从架构。只有 master 服务于客户端命令。Master 和 Slave 通过 Multi-Paxos 就命令的顺序达成共识。master 是 Multi-Paxos 实例中的领导者。假设现在 master 和它的两个 slave 的状态（命令已被选择）如下图所示：

.

请注意，在主状态中存在不止一个间隙。由于不同步，两个奴隶落后。这时候master就失败了。

问题：

1. slave检测到master故障后应该怎么做（比如通过心跳机制）？

2. 特别是与老主控的差距和缺失的命令如何处理？

关于 Zab 的更新：

正如@sbridges 所指出的，ZooKeeper使用Zab而不是 Paxos。去引用，

Zab 主要设计用于主备份（即主从）系统，如 ZooKeeper，而不是用于状态机复制。

Zab 似乎与我上面列出的问题密切相关。根据Zab 的简短概述论文，Zab 协议由两种模式组成：恢复和广播。在恢复模式下，有两个特定的保证：永远不会忘记已提交的消息和放弃已跳过的消息。我对 Zab 的困惑是：

3. 在恢复模式下，Zab 是否也会遇到间隙问题？如果是这样，Zab 做了什么？

JobDetail.requestsRecovery财产文件说明了以下内容

如果遇到“恢复”或“故障转移”情况，指示调度程序是否应重新执行作业。

现在，什么是“恢复”情况或“故障转移”情况？

它们有何不同？

仅当 JVM 在作业执行期间崩溃时才会发生恢复，还是如果作业执行因异常而失败也会发生？