

# Aurora serverless 的工作原理
<a name="aurora-serverless-v2.how-it-works"></a>

以下内容概述了 Aurora serverless 的工作原理。

**Topics**
+ [概述](#aurora-serverless-v2.architecture)
+ [集群配置](#aurora-serverless-v2.how-it-works.cluster_topology)
+ [容量](#aurora-serverless-v2.how-it-works.capacity)
+ [扩缩](#aurora-serverless-v2.how-it-works.scaling)
+ [高可用性](#aurora-serverless.ha)
+ [仓储服务](#aurora-serverless.storage)
+ [配置参数](#aurora-serverless-v2.parameters)

## Aurora serverless 概览
<a name="aurora-serverless-v2.architecture"></a>

*Amazon Aurora serverless* 适用于要求严苛、变化很大的工作负载。例如，您的数据库使用量在短时间内可能很大，紧接着就是长时间的少量活动或完全没有活动。其中一些例子是定期举办促销活动的零售、游戏或体育网站，以及根据需要生成报告的数据库。其他一些例子包括开发和测试环境，以及使用量可能会迅速增加的新应用程序。对于类似这些情况和许多其他情况，使用预置模型并不总是能提前正确地配置容量。如果您过度预置并且保留不使用的容量，也可能导致更高的成本。

相比之下，*Aurora 预置集群*适合稳定的工作负载。使用预置集群，您可以选择具有预定义内存量、CPU 处理能力、I/O 带宽等的数据库实例类。如果您的工作负载发生变化，可以手动修改写入器和读取器的实例类。如果您可以在预期的消费模式之前调整容量，并且在更改集群中写入器和读取器的实例类时，出现短暂的中断是可以接受的，则预置模式很适合。

Aurora serverless 专为支持可即时扩展的无服务器数据库集群而从头开始构建。Aurora serverless 旨在提供与预置写入器和读取器相同程度的安全性和隔离度。这些方面在多租户无服务器云环境中至关重要。动态扩缩机制的开销非常小，因此它可以快速响应数据库工作负载的变化。它还足够强大，可以满足处理需求的急剧增长。

通过使用 Aurora serverless，您可以创建 Aurora 数据库集群，而无需将每个写入器和读取器限制在特定的数据库容量。您指定最小和最大容量范围。Aurora 会在该容量范围内扩缩集群中的每个 Aurora serverless 写入器或读取器。通过使用每个写入器或读取器都可以动态扩缩的多可用区集群，您可以获得动态扩缩和高可用性。

Aurora serverless 根据您的最小和最大容量规格自动扩缩数据库资源。扩缩速度很快，因为大多数扩缩事件操作将写入器或读取器保持在同一主机上。在极少数情况下，Aurora serverless 写入器或读取器从一个主机移动到另一个主机，Aurora serverless 自动管理连接。您无需更改数据库客户端应用程序代码或数据库连接字符串。

与预置集群一样，使用 Aurora serverless 时，存储容量和计算容量是分开的。当我们提到 Aurora serverless 容量和扩缩时，增加或减少的总是计算容量。因此，即使 CPU 和内存容量缩减至低水平，您的集群仍会包含许多 TB 的数据。

您可以指定数据库容量，而不是调配和管理数据库服务器。有关 Aurora serverless 容量的详细信息，请参阅 [Aurora serverless 容量](#aurora-serverless-v2.how-it-works.capacity)。每个 Aurora serverless 写入器或读取器的实际容量会随着时间的推移而发生变化，具体取决于您的工作负载。有关该机制的详细信息，请参阅 [Aurora serverless 扩缩](#aurora-serverless-v2.how-it-works.scaling)。

**重要**  
使用 Aurora serverless 时，除了写入器之外，您的集群还可以包含读取器。每个 Aurora serverless 写入器和读取器可以在最小容量和最大容量值之间扩缩。因此，Aurora serverless 集群的总容量取决于为数据库集群定义的容量范围以及集群中的写入器和读取器数量。在任何给定时间，您都只需为您的 Aurora 数据库集群中正在主动使用的 Aurora serverless 容量付费。

## Aurora 数据库集群的配置
<a name="aurora-serverless-v2.how-it-works.cluster_topology"></a>

对于每个 Aurora 数据库集群，您可以选择 Aurora serverless 容量、预置容量或两者的任意组合。

您可以设置一个同时包含 Aurora serverless 和预置容量的集群，称为*混合配置集群*。例如，假设您需要比 Aurora serverless 写入器所提供容量更多的读/写容量。在这种情况下，您可以使用非常大的预置写入器来设置集群。在这种情况下，您仍然可为读取器使用 Aurora serverless。或者假设集群的写入工作负载会变化，但读取工作负载保持稳定。在这种情况下，您可以使用 Aurora serverless 写入器和一个或多个预置读取器设置集群。

您还可以设置由 Aurora serverless 管理所有容量的数据库集群。为此，您可以创建新的集群并从头开始使用 Aurora serverless。或者，您可以将现有集群中的所有预置容量替换为 Aurora serverless。例如，来自旧引擎版本的一些升级路径需要从预置写入器开始，然后用 Aurora serverless 写入器来替换它。对于使用 Aurora serverless 创建新数据库集群或者将现有数据库集群切换到 Aurora serverless 的过程，请参阅[创建 Aurora serverless 数据库集群](aurora-serverless-v2.create.md#aurora-serverless-v2.create-cluster)和[将预置写入器或读取器转换为 Aurora serverless](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned)。

如果您在数据库集群中根本不使用 Aurora serverless，则数据库集群中的所有写入器和读取器都为*预置*。这是大多数用户都熟悉的最古老、最常见的数据库集群类型。事实上，在 Aurora Serverless 之前，这种 Aurora 数据库集群没有特殊名称。预置容量是恒定的。费用相对更容易预测。但是，您必须提前预测所需的容量。在某些情况下，您的预测可能不准确，或者容量需求可能会发生变化。在这些情况下，您的数据库集群可能会变得配置不足（比您期望的更慢）或过度配置（比您期望的更昂贵）。

## Aurora serverless 容量
<a name="aurora-serverless-v2.how-it-works.capacity"></a>

Aurora serverless 的计量单位是 *Aurora 容量单位（ACU）*。Aurora serverless 容量与您用于预置集群的数据库实例类无关。

每个 ACU 是约 2 GiB 的内存、相应的 CPU 和网络的组合。您可以使用此计量单位指定数据库容量范围（最小值和最大值）。Aurora serverless 提供的容量范围为 0 ACU 到 256 ACU。在最小容量为 0 ACU 的情况下，当没有工作负载正在运行时，集群将扩展到 0。`ServerlessDatabaseCapacity` 和 `ACUUtilization` 指标有助于您确定数据库实际使用了多少容量，以及该容量在指定范围内所处的位置。

在任何时候，每个 Aurora serverless 数据库写入器或读取器有一个*容量*。该容量用代表 ACU 的浮点数表示。每当写入器或读取器扩缩时，容量会增加或减少。此值每秒测量一次。对于您打算使用 Aurora serverless 的每个数据库集群，定义一个*容量范围*：每个 Aurora serverless 写入器或读取器可以在之间进行扩缩的最小容量和最大容量值。数据库集群中的每个 Aurora serverless 写入器或读取器的容量范围都相同。每个 Aurora serverless 写入器或读取器有自己的容量，该容量处于该范围内的某个位置。

下表显示了 Aurora serverless 容量范围以及 Aurora MySQL 和 Aurora PostgreSQL 的引擎版本支持。


| 容量范围（ACU） | Aurora MySQL 支持的版本 | Aurora PostgreSQL 支持的版本 | 
| --- | --- | --- | 
| 0.5–128 | 3.02.0 及更高版本 | 13.6 及更高版本、14.3 及更高版本、15.2 及更高版本、16.1 及更高版本 | 
| 0.5–256 | 3.06.0 及更高版本 | 13.13 及更高版本、14.10 及更高版本、15.5 及更高版本、16.1 及更高版本 | 
| 0–256 | 3.08.0 及更高版本 | 13.15 及更高版本、14.12 及更高版本、15.7 及更高版本、16.3 及更高版本 | 

Aurora serverless 中的平台版本代表性能、扩展能力或功能的改进。Amazon Aurora 在集群级别自动管理平台版本分配。所有新集群、数据库还原和新克隆都使用您的 AWS 区域中的最新平台版本启动。当新的平台版本变为可用时，可以通过停止并重新启动集群或使用蓝绿部署，将先前平台版本上的现有集群直接升级到最新的平台版本。Amazon Aurora 建议升级到最新的平台版本，以便从所有最新改进中受益。

下表显示了 Aurora serverless 平台版本及其 ACU 范围和性能特征。


| Aurora serverless 平台版本 | ACU 范围 | 性能 | 
| --- | --- | --- | 
| 1 | 0–128 | 基准性能 | 
| 2 | 0–256 | 基准性能 | 
| 3 | 0–256 | 与平台版本 2 相比，性能提高了多达 30% | 
| 4 | 0-256 | 与平台版本 3 相比，性能提高了多达 30% | 

**注意**  
给定集群的可用扩展范围由引擎版本和平台版本共同决定。可以在功能较弱的平台版本上运行功能较强的引擎版本，反之亦然。扩展范围由功能最弱的引擎或平台版本决定。不应将平台版本与 Aurora Serverless v1 混淆，后者是具有不同架构的已弃用产品。

平台版本 1、2 和 3 在支持 Aurora serverless 的所有区域均可用。平台版本 4 在以下区域中可用：美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）、美国西部（北加利福尼亚）、美国西部（俄勒冈州）、亚太地区（香港）、亚太地区（海得拉巴）、亚太地区（雅加达）、亚太地区（马来西亚）、亚太地区（墨尔本）、亚太地区（孟买）、亚太地区（大阪）、亚太地区（首尔）、亚太地区（新加坡）、亚太地区（悉尼）、亚太地区（东京）、加拿大（中部）、欧洲地区（法兰克福）、欧洲地区（爱尔兰）、欧洲地区（伦敦）、欧洲地区（巴黎）、欧洲（西班牙）、欧洲地区（斯德哥尔摩）、欧洲（苏黎世）、南美洲（圣保罗）、AWS GovCloud（美国东部）和 AWS GovCloud（美国西部）。

可以在 AWS 管理控制台的“实例配置”部分中或通过 API 查看 [DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBCluster.html) 的 `ServerlessV2PlatformVersion` 来确定运行集群的平台版本。

对于支持自动暂停功能的 Aurora serverless 版本，您可以定义的最小 Aurora serverless 容量为 0 ACU。如果它小于或等于最大容量值，您可以指定一个较高的数值。将最小容量设置为一个很小的数字，可以让负载较轻的数据库集群消耗最少的计算资源。同时，他们随时准备立即接受连接，并在变得忙碌时进行扩展。

我们建议将最小值设置为让每个数据库写入器或读取器可以在缓冲池中保持应用程序工作集的值。这样，在空闲期间，缓冲池的内容不会被丢弃。有关选择最小容量值时的所有注意事项，请参阅[选择集群的最小 Aurora serverless 容量设置](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations)。有关选择最大容量值时的所有注意事项，请参阅[选择集群的最大 Aurora serverless 容量设置](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max_capacity_considerations)。

根据您在多可用区部署中配置读取器的方式，读取器的容量可以与写入器的容量绑定，也可以独立设置。有关如何执行此操作的详细信息，请参阅 [Aurora serverless 扩缩](#aurora-serverless-v2.how-it-works.scaling)。

监控 Aurora serverless 涉及随时间推移测量数据库集群中的写入器和读取器的容量值。如果数据库没有缩减至最小容量，则可以采取行动，例如调整最小值和优化数据库应用程序。如果数据库持续达到最大容量，则可以采用行动，例如增大最大容量。您还可以优化数据库应用程序，并将查询负载分散到更多读取器中。

Aurora serverless 容量的费用按 ACU 小时数来衡量。有关如何计算 Aurora serverless 费用的信息，请参阅 [Aurora 定价页面](https://aws.amazon.com/rds/aurora/pricing/)。

假设集群中写入器和读取器的总数为 {{n}}。在这种情况下，当您未运行任何数据库操作时，集群会消耗大约 `n x {{minimum ACUs}}`。Aurora 本身可能会运行监控或维护操作，从而产生少量负载。当数据库以全部容量运行时，该集群消耗不超过 `n x {{maximum ACUs}}`。

有关选择适当的最小和最大 ACU 值的更多详细信息，请参阅[选择 Aurora 集群的 Aurora serverless 容量范围](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)。您指定的最小和最大 ACU 值也会影响 Aurora serverless 的某些 Aurora 配置参数的工作方式。有关容量范围和配置参数之间的相互影响的详细信息，请参阅[使用 Aurora serverless 的参数组](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups)。

## Aurora serverless 扩缩
<a name="aurora-serverless-v2.how-it-works.scaling"></a>

对于每个 Aurora serverless 写入器或读取器，Aurora 会持续跟踪 CPU、内存和网络等资源的使用率。这些测量统称为*负载*。负载包括应用程序执行的数据库操作。它还包括数据库服务器的后台处理和 Aurora 管理任务。当容量受到这些因素之一的限制时，Aurora serverless 会扩展。当 Aurora serverless 检测到可以通过扩展来解决的性能问题时，它也会扩展。您可以按照 [适用于 Aurora serverless 的重要 Amazon CloudWatch 指标](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) 和 [使用性能详情监控 Aurora serverless 性能](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.performance-insights) 中的步骤监控资源利用率以及了解它如何影响 Aurora serverless 扩缩。

数据库集群中的写入器和读取器的负载可能会有所不同。写入器处理所有数据定义语言（DDL）语句，例如 `CREATE TABLE`、`ALTER TABLE` 和 `DROP TABLE`。写入器还会处理所有数据操纵语言（DML）语句，例如 `INSERT` 和 `UPDATE`。读取器可以处理只读语句，例如 `SELECT` 查询。

*扩缩*是为数据库增大或减少 Aurora serverless 容量的操作。使用 Aurora serverless 时，每个写入器和读取器都有自己的当前容量值，以 ACU 衡量。当写入器或读取器的当前容量太低而无法处理负载时，Aurora serverless 会将其扩展到更高的容量。当写入器或读取器的当前容量高于所需容量时，可以将写入器或读取器缩减至更低的容量。

 Aurora serverless 可以逐步增加容量。当您的工作负载需求开始达到写入器或读取器的当前数据库容量时，Aurora serverless 会增加该写入器或读取器的 ACU 数量。Aurora serverless 按所需的增量扩展容量，以便让消耗的资源实现最佳性能。扩缩按小至 0.5 ACU 的增量进行。当前容量越大，扩缩增量就越大，因此可以更快地进行扩缩。

由于 Aurora serverless 扩展非常频繁、精细且无中断，因此它不会在 AWS 管理控制台中导致离散事件。相反，您可以测量 Amazon CloudWatch 指标（例如 `ServerlessDatabaseCapacity` 和 `ACUUtilization`），并随时间推移跟踪它们的最小值、最大值和平均值。了解有关 Aurora 指标的更多信息，请参阅[监控 Amazon Aurora 集群中的指标](MonitoringAurora.md)。有关监控 Aurora serverless 的提示，请参阅[适用于 Aurora serverless 的重要 Amazon CloudWatch 指标](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)。

您可以选择使读取器跟随关联写入器的容量，也可以独立于写入器进行扩缩。您可以通过为该读取器指定提升层来完成扩缩。
+ 对于提升层 0 和 1 中的读取器，最小容量由当前写入器容量定义，最大容量是为集群指定的最大 ACU 值。这种扩缩行为使得优先级层 0 和 1 中的读取器非常容易获得。这是因为读取器的大小至少需要与写入器相同，这样才能在失效转移情况下接管来自写入器的工作负载。如果写入器是预调配实例，那么无服务器读取器的最小容量是等同于写入器内存大小的 ACU。
+ 提升层 2-15 中的读取器可以独立于写入器进行扩缩。每个读取器都保持在您为集群指定的最小和最大 ACU 值范围内。当读取器独立于关联的写入器数据库进行扩缩时，它会变为空闲并缩减，同时写入器继续处理大量事务。如果在较低的提升层中没有其他读取器可用，它仍可作为失效转移目标。但是，如果它被提升为写入器，则可能需要扩展以处理写入器的全部工作负载。

有关提升层的详细信息，请参阅[为 Aurora serverless 读取器选择提升层](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier)。

可以在数据库连接处于打开状态、SQL 事务正在进行中、表已锁定以及临时表正在使用中的情况下进行 Aurora serverless 扩展。Aurora serverless 不会等到静止点才开始扩展。扩缩不会中断任何正在进行的数据库运营。

如果您的工作负载需要的读取容量超过单个写入器和单个读取器可提供的读取容量，则可以向集群添加多个 Aurora serverless 读取器。每个 Aurora serverless 读取器可以在您为数据库集群指定的最小和最大容量值范围内扩缩。您可以使用集群的读取器端点将只读会话定向到读取器并减少写入器上的负载。

Aurora serverless 是否执行扩缩，以及扩缩在启动后的速度也取决于集群的最小和最大 ACU 设置。此外，它还取决于读取器是配置为随写入器一起扩缩还是独立于写入器进行扩缩。有关影响 Aurora serverless 扩缩的因素的详细信息，请参阅 [Aurora serverless 的性能和扩缩](aurora-serverless-v2.setting-capacity.md)。

### 缩减至零
<a name="aurora-serverless-v2-scaling-to-zero"></a>

 在最近的 Aurora MySQL 和 Aurora PostgreSQL 版本中，Aurora serverless 写入器和读取器可以完全缩减至零 ACU。我们将此功能称为自动暂停和恢复，或者简称自动暂停。您可以通过为最小容量指定零值或非零值来选择是否允许此行为。您也可以选择 Aurora serverless 实例要等待多长时间才能暂停。有关哪些版本具有此功能的信息，请参阅 [Aurora serverless 容量](#aurora-serverless-v2.how-it-works.capacity)。有关如何有效使用它的信息，请参阅[针对 Aurora serverless 缩减到零 ACU 从而自动暂停和恢复](aurora-serverless-v2-auto-pause.md)。

 在较早的 Aurora MySQL 和 Aurora PostgreSQL 版本中，空闲 Aurora serverless 写入器和读取器可以缩减至您为集群指定的最小 ACU 值，但不能完全缩减至零 ACU。在这种情况下，当您设置容量范围时，不能选择零 ACU。

 当您的具有 Aurora serverless 容量的数据库集群在一段时间内不需要时，您也可以像对待预调配数据库集群那样，先停止整个集群，需要时再启动。这种方式最适合开发和测试系统，因为一次可能不需要很多小时，而且恢复集群的速度并不重要。停止/启动集群功能适用于所有 Aurora serverless 版本。有关此功能的更多信息，请参阅[停止和启动 Amazon Aurora 数据库集群](aurora-cluster-stop-start.md)。

## Aurora serverless 和高可用性
<a name="aurora-serverless.ha"></a>

为 Aurora 数据库集群建立高可用性的方法是使其成为多可用区数据库集群。*多可用区 Aurora 数据库集群*在多个可用区（AZ）中具有始终可用的计算容量。即使在出现重大中断的情况下，该配置也能使数据库保持正常运行。如果出现影响写入器乃至整个可用区的问题，Aurora 会执行自动失效转移。使用 Aurora serverless 时，您可以选择随写入器的容量一起扩展和缩减的备用计算容量。这样，第二个可用区的计算容量随时准备好接管当前的工作负载。同时，当数据库空闲时，所有可用区中的计算容量都可以缩减。有关 Aurora 如何使用 AWS 区域 和可用区的详细信息，请参阅 [Aurora 数据库实例的高可用性](Concepts.AuroraHighAvailability.md#Concepts.AuroraHighAvailability.Instances)。

除了写入器，Aurora serverless 多可用区功能还使用*读取器*。支持读取器是 Aurora serverless 的新功能。您可以向 Aurora 数据库集群添加最多 15 个分布在 3 个可用区的 Aurora serverless 读取器。

对于即使出现影响整个集群或整个 AWS 区域的问题时也必须保持可用的业务关键型应用程序，您可以设置 Aurora Global Database。您可以使用辅助集群中的 Aurora serverless 容量，因此它们准备好可以在灾难恢复期间接管。当数据库不忙时，它们也可以缩减。有关 Aurora Global Database 的详细信息，请参阅[使用 Amazon Aurora Global Database](aurora-global-database.md)。

Aurora serverless对于失效转移和其他高可用性功能， 的工作方式与预置实例类似。有关更多信息，请参阅 [Amazon Aurora 的高可用性](Concepts.AuroraHighAvailability.md)。

假设您想要确保您的 Aurora serverless 集群获得最大可用性。除了写入器之外，您还可以创建读取器。如果您将读取器分配到提升层 0 或 1，则读取器的最小容量将与当前写入器容量（对于预调配写入器为写入器的内存大小）匹配。这样，读取器便可随时准备好在失效转移的情况下接管写入器。

假设您希望在集群继续处理事务的同时为您的业务运行季度报告。如果您向集群添加一个 Aurora serverless 读取器，并将其分配给 2 至 15 的提升层，则您可以直接连接到该读取器以运行报告。根据报告查询占用内存和 CPU 的程度，该读取器可以扩展以适应工作负载。然后，当报告完成后，它可以再次缩减。

## Aurora serverless 和存储
<a name="aurora-serverless.storage"></a>

每个 Aurora 数据库集群的存储包含所有数据的六个副本，分布在三个可用区。无论数据库集群除了写入器之外是否还包括任何读取器，此内置数据复制都适用。这样，即使出现影响集群计算容量的问题，您的数据也可保持安全。

Aurora serverless 存储具有与 中所述相同的可靠性和持久性特征。[Amazon Aurora 存储](Aurora.Overview.StorageReliability.md)这是因为无论计算容量是使用 Aurora serverless 还是使用预置实例，Aurora 数据库集群的存储同样适用。

## Aurora 集群的配置参数
<a name="aurora-serverless-v2.parameters"></a>

您可以按照与调整预置数据库集群相同的方式来调整具有 Aurora serverless 容量的集群的所有集群和数据库配置参数。但是，一些与容量相关的参数的处理方式与 Aurora serverless 不同。在混合配置集群中，您为这些容量相关参数指定的参数值仍适用于所有预置的写入器和读取器。

Aurora serverless 写入器和读取器几乎所有参数的工作方式都与预配实例的工作方式相同。例外情况是 Aurora 在扩缩过程中自动调整的一些参数，以及 Aurora 保持为固定值的一些参数，它们取决于最大容量设置。

例如，为缓冲区缓存预留的内存量随着写入器或读取器的扩展而增加，并随着它们的缩减而减少。这样，当数据库不忙时，可以释放内存。相反，Aurora 会根据最大容量设置自动将最大连接数设置为适当的值。这样，在负载下降且 Aurora serverless 缩减时，活动连接不会断开。有关 Aurora serverless 如何处理特定参数的信息，请参阅[使用 Aurora serverless 的参数组](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups)。