> For the complete documentation index, see [llms.txt](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/lecture-10-cloud-replicated-db-aurora/10.5-quorum.md).

# 10.5 Aurora存储服务器的容错目标（Fault-Tolerant Goals）

从之前的描述可以看出，Aurora的Quorum系统管理了6个副本的容错系统。所以值得思考的是，Aurora的容错目标是什么？

* 首先是对于写操作，当只有一个AZ彻底挂了之后，写操作不受影响。
* 其次是对于读操作，当一个AZ和一个其他AZ的服务器挂了之后，读操作不受影响。这里的原因是，AZ的下线时间可能很长，比如说数据中心被水淹了。人们可能需要几天甚至几周的时间来修复洪水造成的故障，在AZ下线的这段时间，我们只能依赖其他AZ的服务器。如果其他AZ中的一个服务器挂了，我们不想让整个系统都瘫痪。所以当一个AZ彻底下线了之后，对于读操作，Aurora还能容忍一个额外服务器的故障，并且仍然可以返回正确的数据。至于为什么会定这样的目标，我们必须理所当然的认为Amazon知道他们自己的业务，并且认为这是实现容错的最佳目标。
* 此外，我之前也提过，Aurora期望能够容忍暂时的慢副本。如果你向EBS读写数据，你并不能得到稳定的性能，有时可能会有一些卡顿，或许网络中一部分已经过载了，或许某些服务器在执行软件升级，任何类似的原因会导致暂时的慢副本。所以Aurora期望能够在出现短暂的慢副本时，仍然能够继续执行操作。
* 最后一个需求是，如果一个副本挂了，在另一个副本挂之前，是争分夺秒的。统计数据或许没有你期望的那么好，因为通常来说服务器故障不是独立的。事实上，一个服务器挂了，通常意味着有很大的可能另一个服务器也会挂，因为它们有相同的硬件，或许从同一个公司购买，来自于同一个生产线。如果其中一个有缺陷，非常有可能会在另一个服务器中也会有相同的缺陷。所以，当出现一个故障时，人们总是非常紧张，因为第二个故障可能很快就会发生。对于Aurora的Quorum系统，有点类似于Raft，你只能从局部故障中恢复。所以这里需要快速生成新的副本（Fast Re-replication）。也就是说如果一个服务器看起来永久故障了，我们期望能够尽可能快的根据剩下的副本，生成一个新的副本。

![](/files/-MFecGJrtQlF_bOYYYoE)

所以，以上就是论文列出的Aurora的主要容错目标。顺便说一下，这里的讨论只针对存储服务器，所以这里讨论的是存储服务器的故障特性，以及如何从故障中恢复。如果数据库服务器本身挂了， 该如何恢复是一个完全不同的话题。Aurora有一个完全不同的机制，可以发现数据库服务器挂了之后，创建一个新的实例来运行新的数据库服务器。但是这不是我们现在讨论的话题，我们会在稍后再讨论。现在只是讨论存储服务器，以及存储服务器的容错。