为什么使用AWS Aurora的多AZ部署

Question

通常在使用AWS RDS时，实现高可用性的推荐实践是在不同的AZ中部署热副本（多AZ部署）。此外，还可以创建一些读取副本来提高读取性能。

我读过AWS Aurora文档，它使用公共虚拟存储层，在3个AZ上复制，每个AZ有两个副本。

我的问题是：如果Aurora本身能够自愈，并且存储分布在多个AZ，那么是否需要使用Aurora DB集群的Amazon MultiAZ部署？如果它在3个AZ中各保留2个存储副本，那么它就像使用多AZ副本设置进行故障转移一样可靠。此外，在故障转移期间。它会自动创建另一个实例（如果不存在读取副本）或切换主实例。我真的不明白任何需要创建额外的要求使用多AZ极光集群来‘提高’可用性。

在默认的Aurora部署下，是否有可能出现可用性受损的情况？在丢失包含主Aurora DB节点的整个AZ期间会发生什么？

Answer 1

RDS Multi-AZ特性对于Aurora部署比对于非Aurora部署要简单得多：Aurora副本除了读取缩放端点之外，还是一个Multi-AZ故障转移目标，因此创建Multi-AZ Aurora部署就像在与主实例不同的可用性区域中部署Aurora副本一样简单。

这种行为不同于标准的非Aurora多AZ部署，后者维护一个单独的同步复制的“备用实例”，该实例不能用作读缩放端点，反之亦然（标准RDS读副本不能用作多AZ故障转移目标）。

即使Aurora数据是跨AZs备份的，但已经运行的副本实例仍然可以显著减少从主实例故障中恢复所需的时间。Aurora从可用Aurora副本的故障转移中恢复所需的时间通常为1-2分钟,而没有副本的情况下为10分钟,如Aurora DB群集的容错：

如果DB集群中的主实例发生故障,Aurora会以以下两种方式之一自动故障转移到新的主实例：

• 通过将现有Aurora副本提升到新的主实例
• 通过创建新的主实例

如果DB集群具有一个或多个Aurora副本，则在故障事件期间将Aurora副本提升到主实例。[...]但是，通常在不到120秒的时间内恢复服务，通常不到60秒。[...]

如果DB集群不包含任何Aurora副本，则在失败事件期间重新创建主实例。[...]创建新的主实例时，将恢复服务，这通常需要不到10分钟的时间。

将Aurora副本提升到主实例比创建新的主实例要快得多。

Answer 2

如果您只对数据不丢失感兴趣，那么非多AZ可能会很好地工作，因为正如您所说的，数据是为您复制的。

但是Aurora的运行实例仍然存在于一台物理机器上，而该物理机器存在于一个AZ中，因此如果该AZ发生故障，尽管您可能不会丢失任何数据，但您不一定能够访问它。

多AZ部署有一台运行在多个AZ中的物理机器，因此如果一个AZ发生故障，另一个AZ中的数据库服务器仍然可以为您的请求提供服务。