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)。也就是说如果一个服务器看起来永久故障了,我们期望能够尽可能快的根据剩下的副本,生成一个新的副本。

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

最后更新于