一般在使用 AWS RDS 时，推荐的实现高可用的做法是在不同的 AZ 部署热副本（多 AZ 部署）。此外，可以调出一些只读副本来提高读取性能。
我已阅读 AWS Aurora 文档，它使用通用虚拟存储层，在 3 个 AZ 上复制，每个 AZ 有两个副本。
我的问题是：如果 Aurora 本身能够自我修复并且其存储分布在多个 AZ 上，是否需要使用 Aurora 数据库集群的 Amazon 多可用区部署？如果它在 3 个 AZ 中的每一个中保留 2 个存储副本，那么它与使用多 AZ 副本设置进行故障转移一样可靠。此外，在故障转移期间。它会自动创建另一个实例（如果不存在只读副本）或切换主实例。我真的不明白任何需要创建使用多可用区极光集群来“提高”可用性的额外要求。
是否有可能在默认 Aurora 部署下可用性会受到影响？在包含主 Aurora DB 节点的整个 AZ 丢失期间会发生什么？
如果您只对不丢失数据感兴趣，那么非多可用区可能会正常工作，因为正如您所说，数据会为您复制。
但是 Aurora 的运行实例仍然存在于物理机上，并且该物理机存在于单个 AZ 中，因此如果该 AZ 出现故障，虽然您可能不会丢失任何数据，但您不一定可以访问它。
多 AZ 部署有一台物理机在多个 AZ 中运行，因此如果一个 AZ 出现故障，另一个 AZ 中的数据库服务器仍然可以为您的请求提供服务。
Aurora 部署的 RDS多可用区功能比非 Aurora 部署简单得多：Aurora 副本是一个多可用区故障转移目标以及一个读取扩展端点，因此创建多可用区 Aurora 部署就像就像在与主实例不同的可用区中部署 Aurora 副本一样简单。
此行为不同于标准的非 Aurora 多可用区部署，后者维护一个单独的同步复制“备用实例”，该实例不能用作读取扩展端点，反之亦然（标准 RDS 只读副本不能用作 Multi- AZ 故障转移目标）。
即使 Aurora 数据是跨 AZ 备份的，拥有已经运行的副本实例仍然可以显着减少从主实例故障中恢复所需的时间。Aurora 从具有可用 Aurora 副本的故障转移中恢复所需的典型时间为1-2 分钟，而没有副本的情况下则需要10 分钟，如Aurora 数据库集群的容错中所述：
如果数据库集群中的主实例发生故障，Aurora 会通过以下两种方式之一自动故障转移到新的主实例：
- 通过将现有的 Aurora 副本提升到新的主实例
- 通过创建一个新的主实例
如果数据库集群有一个或多个 Aurora 副本，那么在发生故障事件期间，一个 Aurora 副本会提升为主实例。[...] 但是，服务通常会在120 秒内恢复，并且通常会在 60 秒内恢复。[...]
如果数据库集群不包含任何 Aurora 副本，则会在故障事件期间重新创建主实例。[...] 在创建新的主实例时恢复服务，这通常需要不到 10 分钟。
将 Aurora 副本提升到主实例比创建新的主实例要快得多。