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

Question

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

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

我的问题是：如果Aurora本身能够自我修复并且其存储分布在多个AZ上，是否需要使用Aurora数据库集群的Amazon多AZ部署？如果它在3个AZ中的每个AZ中保留2个存储副本，那么它与使用多AZ副本设置进行故障转移一样可靠。此外，在故障转移期间。它会自动创建另一个实例（如果不存在只读副本）或切换主要实例。我真的不明白是否需要创建额外的使用多AZ极光集群的要求来改善＆＃39;可用性。

在默认的Aurora部署下，是否有可能出现可用性的情况？丢失包含主要Aurora数据库节点的整个AZ时会发生什么？

Answer 1

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

但是Aurora的运行实例仍然存在于物理机器上，并且该物理机器存在于单个AZ中，因此如果AZ发生故障，您可能不会丢失任何数据，而您可能无法访问它

多可用区部署的物理计算机在多个AZ中运行，因此如果一个AZ出现故障，其他AZ中的数据库服务器仍可以为您的请求提供服务。

Answer 2

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

此行为与标准的非Aurora多可用区部署不同，后者维护一个单独的同步复制的备用实例＆＃39;不能用作读取扩展端点，反之亦然（标准RDS只读副本不能用作多可用区故障转移目标）。

即使跨AZ备份Aurora数据，已经运行的副本实例仍可以显着减少从主实例的故障中恢复所需的时间。 Aurora使用Aurora副本进行故障转移恢复所需的典型时间是 1-2分钟，而 10分钟没有副本，如{{ 3}}：

  

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

     

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

     

如果数据库群集包含一个或多个Aurora副本，则会在失败事件期间将Aurora副本提升为主实例。 [...]但是，服务通常会在少于120秒中恢复，通常少于60秒。 [...]

     

如果数据库集群不包含任何Aurora副本，则在故障事件期间重新创建主实例。 [...]创建新主要实例时会恢复服务，通常需要少于10分钟。

     

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