选择正确的 Amazon RDS 部署选项：单可用区实例、多可用区实例或多可用区数据库集群

除了为您提供七个知名引擎的选择外， 亚马逊关系数据库服务 (Amazon RDS) 还提供多种部署选项，以帮助您选择最适合您的工作负载的选项。您可以评估您的需求，然后选择正确的服务组合。在最新的一组创新中，亚马逊发布了 Amazon RDS 多可用区数据库集群 ，该集群 提供了更快的提交延迟、更快的故障转移、可读的备用实例和复制优化。这些实例由 亚马逊云科技 Graviton2 处理器 提供支持， 与基于 x86 的同类实例相比，性价比最高可提高 40%，每个 vCPU 的本地存储 GB 增加了 50%。

在以下部分中，我们将根据自动故障转移时间、读取可扩展性、可用引擎选项、交易提交延迟、可用区 ( AZ) 中断弹性和恢复目标 (RTO/RPO) 等因素，深入探讨单可用区部署、 多可用区数据库实例部署 和多 可用区 数据库集群部署 的不同 Amazon RDS 部署选项。恢复时间目标 (RTO) 和恢复点目标 (RPO) 是开发弹性架构时需要考虑的两个关键指标。RTO 表示灾难发生后你需要多少时间才能恢复工作状态。RPO 表示灾难发生时您可能会丢失多少数据。例如，1 小时的 RPO 意味着灾难发生时您可能会丢失多达 1 小时的数据。

单可用区实例

单可用区实例运行在由 亚马逊 弹性区块存储 (Amaz on EBS ) 卷支持的单个亚马逊 RDS 托管实例上。应用程序读取或写入请求被路由到单可用区实例。下图说明了适用于所有 Amazon RDS 引擎的单可用区实例的高级架构。

由于缺少备用实例，单可用区实例在可用区中断期间无法进行故障转移。Amazon RDS 单可用区实例的 RPO 通常为 5 分钟，这取决于将交易日志复制到 Amazon S3 的超时间隔。由于未完成的交易、引擎特定的设置、与 Amazon S3 的网络连接中断以及实例类别（网络/磁盘/繁重工作负载）限制，此时间可能会有所不同。你可以通过调用 rds: describe-db-Instances: LatestorableTime API 来找到它。RTO 可以持续几分钟到几个小时。但是，您可以在同一区域或跨区域内创建只读副本以支持读取工作负载，并且可以在主实例出现故障时手动升级只读副本。

单可用区实例不适合需要高可用性的生产工作负载。但是，它可能非常适合应用程序不需要高可用性、自动故障转移或低 RTO/RPO 的开发或测试目的。

有关更多信息，请访问 Amazon RDS 幕后：单可用区实例恢复 。

多可用区实例

多可用区实例由位于两个不同可用区的两个 Amazon RDS 托管实例组成。多可用区实例部署中的两个实例被称为主实例和备用实例。主实例负责提供读取和写入流量。在此部署选项中，备用实例不提供任何读取或写入流量。存储复制是从主实例同步进行的。

下图说明了适用于 Amazon RDS For PostgreSQL 的多可用区部署的高级架构，它也适用于 Amazon RDS 支持的其他引擎 。 带有一个备用服务器的多可用区部署适用于所有 Amazon RDS 产品。

发生故障时，Amazon RDS 会启动自动故障转移到备用实例。在此期间，实例在多可用区实例部署中的角色互换，并进行 DNS 传播。自动故障转移过程无需任何手动干预即可将备用实例提升为主实例的新角色。出现以下任何一种情况时，Amazon RDS 会自动执行故障转移：

  • 主可用区失去可用性
  • 与主服务器的网络连接中断
  • 主计算机上的计算单元故障
  • 主服务器上的存储故障

由于同步复制到备用数据库实例，使用 Amazon RDS 多可用区实例故障转移的 RPO 为零。故障转移所需的时间通常为 1—2 分钟。由于回滚未提交的事务或向前滚动内存中已提交的交易、对实例类的 IO 吞吐量的限制、 从 Amazon S3 延迟加载到 Amazon EBS 卷 以及必须复制的交易日志量而导致的恢复时间过长，这些都可能延长故障转移时间。

在自动故障转移期间，交易或机上查询会终止。因此，最佳做法是建立自己的机制来检测查询取消。有关如何响应故障转移、缩短恢复时间以及 Amazon RDS 的其他最佳实践的信息，请参阅 Amazon RD S 最佳实践 。

使用 Amazon RDS 多可用区实例时，快照和备份是从备用实例中获取的。这样可以防止在备份过程中暂停主实例上的 I/O，从而避免主实例的读/写流量中断并降低延迟。但是，如上所述，备用实例是被动的，不提供读取流量。为了提供只读流量，我们可以向多可用区实例添加只读副本，并使用读取终端节点提供只读流量。如果主数据库实例出现故障，您也可以使用只读副本提升作为数据恢复方案。有关只读副本的更多信息，请参阅 使用只读副本 。

多可用区实例适用于需要高可用性、低 RTO/RPO 和可用区中断弹性的业务/任务关键型应用程序。但是，这种高可用性选项不是只读场景的扩展解决方案。您不能使用备用副本来提供读取流量。要提供只读流量，请改用多可用区数据库集群或只读副本。

如需更多信息，请访问 亚马逊 RDS 幕后：多可用区 。

多可用区数据库集群

多可用区数据库集群是 Amazon RDS 中的最新部署产品，可用于 MySQL 和 PostgreSQL 引擎。多可用区数据库集群将自动故障转移与两个可读备用实例相结合，提交延迟和自动故障转移速度最多可提高 2 倍，通常低于 35 秒。Amazon RDS 托管实例在三个独立的可用区中创建，并配备用于本地存储的快速 NVMe SSD，非常适合高速和低延迟存储。与无法访问辅助实例进行读取或写入的多可用区实例部署不同，多可用区数据库集群部署包括在一个可用区中运行的主实例提供读写流量，另外两个在两个不同可用区运行的备用实例提供读取流量。

多可用区数据库集群通过拆分流量，分别分配到集群终端节点的写入流量和读取流量的读取器终端节点的流量，帮助最大限度地提高应用程序的性能和可扩展性。下图说明了高级架构。

与取消了崩溃恢复步骤的多可用区实例部署相比，此部署选项还缩短了故障转移时间，通常低于 35 秒。但是，总恢复时间取决于 复制延迟 。

在以下部分中，我们将更深入地探讨多可用区数据库集群处理读写流量与单可用区实例或多可用区实例产品相比的差异。

基础架构

多可用区数据库集群中有三个实例：一个主写入器实例和两个位于不同可用区的可读备用实例。这些实例中的每一个都包含一个带有本地 SSD 存储的 亚马逊弹性计算云 实例（可提高性能）和附加的 Amazon EBS 卷以实现持久存储。此外，多可用区数据库集群实例使用实例类，EBS 卷的存储是在集群级别定义的。Amazon RDS 计算实例的本地存储没有弹性，其大小与所选实例类挂钩。

复制的复杂性

尽管多可用区实例部署选项使用同步复制，但多可用区数据库集群部署复制是半同步的。半同步复制可保证，如果主服务器崩溃，所有已提交的事务都已传输到至少一个可读的备用实例。与异步复制相比，这被称为 “法定人数”，半同步复制可以提高数据的完整性和耐久性，因为当提交成功返回时，我们知道数据至少存在于两个地方。这可确保在主实例出现故障时，可通过 Amazon RDS 编排的自动故障转移将其中一个备用读取器实例提升为主实例。故障转移所花费的时间通常约为 25—75 秒，但可能会因为副本延迟而增加，因为在读取器被提升为新写入器之前，需要更多时间将本地 SSD 中的中继日志）从本地 SSD 应用到 Amazon EBS 卷。

更快的写入操作

与多可用区实例部署相比，多可用区数据库集群部署可降低写入提交的延迟。主数据库实例复制到各自独立的可用区中的两个备用读取器实例，并且由于数据在另一个可用区中可用，因此具有更好的耐久性。为了更好地理解这一点，让我们看看如何在多可用区数据库集群中进行写入：

  • 只有在其中一个备用实例确认交易已写入备用实例的本地 SSD 之后，才会在主实例上提交和应用事务。多可用区数据库集群使用 法定机制 来确认至少有一个备用数据库已确认更改。
  • 数据 从本地 SSD 异步 复制到连接的 EBS 卷。

下图说明了这个过程。

尽管多可用区数据库集群使用半同步复制模型提供弹性，但如果法定集合中的一个实例未应用所有交易，它们仍可能出现复制延迟。如果您的应用程序需要读取所有最新数据，这被称为 “强读取一致性”，则必须使用写入器端点进行读取。对于为处理复制延迟而构建的应用程序，您可以使用读取器终端节点。

在多可用区数据库集群中观察到的可读备用实例在副本延迟方面的行为与我们在具有一个或多个只读副本的单可用区或多可用区实例中观察到的行为类似，其中每个只读副本的滞后值可能不同。但是，与单可用区实例和多可用区实例的独立只读副本（异步复制）不同，多可用区数据库集群中从主实例到可读备用实例的复制是半同步的。

由于写入过程中的这些改进，RDS 多可用区数据库集群提供了以下好处：

  • 写入本地存储时，延迟更低，吞吐量更高，与 Amazon EBS 相比，本地存储速度更快。与多可用区或单可用区部署相比，Amazon RDS 多可用区数据库集群支持的交易提交延迟最多快 2 倍。
  • 使用两个可以提供读取流量的备用实例，提高了对可用区中断的弹性。
  • 多可用区数据库集群使用三分之二的法定人数，这意味着写入需要得到其中一个备用数据库的确认。这使集群在写入路径受损时更具弹性，从而在出现故障的情况下提高整体性能。

多可用区数据库集群适用于需要高可用性、低 RTO/RPO、改进的提交延迟、更快的故障转移、可读备用实例以及具有高可用性、自动故障转移和读取可扩展性的优化复制的业务/任务关键型应用程序。

摘要

在这篇文章中，我们向您介绍了不同的 Amazon RDS 产品、新的多可用区数据库集群以及为您的工作负载选择合适的产品时需要考虑的关键因素。下表总结了选择部署选项时的关键注意事项。

Considerations Single-AZ Multi-AZ (with one standby) Multi-AZ (with two readable standby instances)
Standby instance can accept reads No No Yes
Commit latency Low Higher than Single-AZ Up to two-times faster commits for writes compared to Multi-AZ instance
Automatic failover No, because there is no standby Yes Yes
Failover time Not possible Can take up to 120 seconds, based on crash recovery Typically 25–75 seconds, but depends replica lag
AZ outage resiliency In the event of Availability Zone failure, you risk data loss; RPO can be up to 5 minutes In the event of Availability Zone failure, your workload automatically fails over to standby instances Two standby instances serve as failover targets
Storage jitter No optimization for jitter Sensitive to impairments on the write path Uses two of three quorum: insensitive to up to one impaired write path
Replication mode None Synchronous replication Semi-synchronous engine-native replication
Performance impact of snapshots Brief I/O suspension Taken from secondary instance, no I/O suspension Amazon EBS crash consistent snapshot feature to take backup from primary, which doesn’t result in I/O suspension

当您的工作负载需要更低的写入延迟、自动故障转移和额外的读取容量时，多可用区数据库集群选项是理想的选择。您可以使用 只读副本或快照和还原方法将单可用区 或多可用区实例 迁移到多可用区数据库集群 。

有后续问题或反馈吗？通过创建 技术支持票 、在 亚马逊云科技 论坛 上发布您的问题或发表评论来告知我们。我们很想听听你的想法和建议。

作者简介

Ankush Agarwal 是 AW S 的解决方案架构师。他是一名 亚马逊云科技 认证架构师，帮助客户在 亚马逊云科技 上设计弹性工作负载。他还具有在 亚马逊云科技 云上设计、部署和优化数据分析工作负载的经验。工作之余，你会发现他在城市森林或运动场上徘徊。

Pranshu Mishra 是 亚马逊云科技 的解决方案架构师。他是八个领域的 亚马逊云科技 认证专业人士，专门研究数据库和无服务器技术。他在在 亚马逊云科技 云上设计、部署和优化工作负载方面拥有经验。除工作外，他还喜欢花时间探索户外活动并沉浸在大自然中

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。