cmu440(11) Fault Tolerance, Logging and recovery 2

容错 - 使用检查点恢复

在DS中实现容错

1. 进程弹性（当进程失败时）
   • 有多个进程（冗余）
   • 将它们分组（平面，分层），投票
2. 可靠的RPC（通信失败）
   • 需要考虑的几个案例（丢失的答复，客户端崩溃......）
   • 每种情况的几种可能的解决方案
3. 分布式提交协议
   • 由所有小组成员执行操作，或根本不执行
   • 2阶段提交，...（上次讲座）
4. 今天：发生故障，我们能恢复吗？

恢复策略

• 发生故障时，我们需要使系统进入无错状态（恢复）。 这是容错的基础。

1. 后向恢复：将系统返回到先前的某个正确状态（使用检查点），然后继续执行。
   检查点：定时记录系统系统的状态，以便当发生错误时恢复到记录的状态。每次记录系统的当前状态时，就称为一个检查点。
   例？
   • 在丢包的情况下重传分组（之前的状态是当丢包正要被发送时）
2. 前向恢复：使系统进入正确的新状态，然后可以继续执行。 例？

前向恢复关键在于它必须预知先知道会发生什么错误，只有在这样的情况下才有可能纠正错误并转到新的状态。

3. 后向恢复的主要缺点：

   • 检查点可能非常昂贵，需要额外开销（特别是当错误非常罕见时）。
   • [尽管付出了代价，倒退恢复的执行更为频繁。 信息的“记录”可以被认为是一种检查点。]。恢复了之后也许仍然会发生错误。

4. 前向恢复的主要缺点：

   • 为了工作，所有潜在的错误都需要预先考虑。
   • 发生错误 时，恢复机制会知道如何处理系统以使系统处于正确状态。

在实践中往往使用后向恢复。
另外，在实践中，具有较少检查点和具有消息记录的组合优于具有多个检查点。

检查点

恢复线路

在分布式系统中的恢复很复杂，因为进程需要合作确定从哪里恢复的一致状态。
如果检查点不协调，这变得具有挑战性
在向后恢复中，每个进程将不时地将其状态保存到本地持久存储中。
分布式快照：记录一致的全局状态。在分布式快照中，有一个进程P记录了一条消息的接收，那么就应该有一个进程Q发送
恢复线路：从局部的状态建立起一致的全局状态。特别是恢复到最近的分布式快照。

独立协调点

独立协调点

P2崩溃后，回退到最近的检查点，P1也随之后退。但是此时p2的检查点显示收到了m消息，p1的检查点并不能表示自己是m的发送方进程，所以需要继续往后面回退一个检查点。但是后继的一个状态检查点依旧不可以，p1检查点此时记录了收到了m’，但是没有此消息被发送的记录事件（p2此时并没有记录，检查点在m’之前）。可以看出需要回退到初始状态。

缺点：进程独立地设置本地检查点，协调需要全局同步，会浪费一些性能；而且每个本地存储都需要按时清理。不过主要的缺点还是恢复线的计算。

协调检查点

1. 主要思想：每个过程在全球协调行动后采取检查点。 （为什么这很好？）
2. 简单的解决方案：2阶段阻塞协议
   • 协调器多播checkpoint_REQUEST 消息
   • 参与者接收消息，获取检查点，停止发送（应用程序）消息，并发回checkpoint_ACK
   • 一旦所有参与者确认，协调员发送checkpoint_DONE以允许阻止的进程继续

要点：在设置了检查点后，将传递给应用程序的之后的消息进行排队，这样就可以使全局状态一致，因为没有即将进来的消息注册为检查点的一部分。
优点：所有进程将其检查点同步写入稳定存储，因此保存的状态自动全局一致。 级联回滚可以避免。

恢复 - 稳定的存储

image.png