

# 针对 Aurora Serverless v2 缩减到零 ACU 从而自动暂停和恢复
缩减到零 ACU 从而自动暂停和恢复<a name="auto-pause"></a><a name="autopause"></a>

 如果 Aurora Serverless v2 数据库实例在指定时间段内没有任何由用户活动启动的连接，则您可以指定数据库实例缩减到零 ACU 并自动暂停。为此，您可以将数据库集群的最小 ACU 值指定为零。当实例处于暂停状态时，您无需为实例容量付费。对于使用量较少或长时间处于非活动状态的 Aurora 集群，启用自动暂停和恢复功能可以帮助您管理数据库实例集的成本。

**注意**  
 自动暂停功能同时适用于 Aurora PostgreSQL 和 Aurora MySQL 中的 Aurora Serverless v2。您可能需要升级 Aurora 数据库引擎版本才能利用此功能。有关哪些引擎版本中提供最小容量 0 ACU 的信息，请参阅 [Aurora Serverless v2 容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)。

**Topics**
+ [自动暂停概述](#auto-pause-overview)
+ [先决条件和限制](#auto-pause-prereqs)
+ [开启和关闭自动暂停](#auto-pause-enabling-disabling)
+ [自动暂停功能的工作原理](#auto-pause-how-it-works)
+ [自动暂停和 Aurora 集群配置](#auto-pause-topology)
+ [监控自动暂停](#auto-pause-monitoring)
+ [自动暂停故障排查](#auto-pause-troubleshooting)
+ [自动暂停的应用程序设计](#auto-pause-applications)

## Aurora Serverless v2 自动暂停功能概述
自动暂停概述

 Aurora Serverless v2 数据库实例可以在没有用户连接的一段时间后自动暂停，并在连接请求到达时自动恢复。Aurora Serverless v2 自动暂停/恢复功能有助于管理那些没有严格服务级别目标（SLO）的系统的成本。例如，您可以为用于开发和测试的集群启用此功能，或者为在数据库恢复时可以接受短暂停顿的内部应用程序启用此功能。如果您的工作负载有时处于非活动状态，并且可以容忍在实例恢复时略微连接延迟，请考虑对您的 Aurora Serverless v2 实例使用自动暂停以降低成本。

 您可以通过指定集群中的 Aurora Serverless v2 数据库实例能否自动暂停，以及每个实例在暂停之前必须处于空闲状态的时长来控制这种行为。要为 Aurora 集群中的所有 Aurora Serverless v2 数据库实例启用自动暂停行为，请将集群的最小容量值设置为零 ACU。

 如果您以前使用过在闲置一段时间后缩减到零 ACU 的 Aurora Serverless v1 功能，则可以升级到 Aurora Serverless v2 并使用其相应的自动暂停功能。

 自动暂停功能可以带来节省成本的好处，类似于使用停止/启动集群功能。Aurora Serverless v2 的自动暂停功能的另一个好处是，恢复速度比启动已停止的集群更快，并且可以自动判断何时暂停和恢复每个数据库实例。

 自动暂停功能还为控制集群内计算资源的成本提供了更高的精度。您可以允许集群中一些读取器实例暂停，同时使集群中的写入器实例和其他读取器始终处于活动状态。方法是，为可以独立于其他实例暂停的读取器实例分配介于 2-15 范围内的失效转移优先级。

 写入器实例和所有失效转移优先级为 0 和 1 的读取器实例始终同时暂停和恢复。因此，该组中的实例会在指定时间间隔内没有任何连接后暂停。

 Aurora 数据库集群可以包含写入器和读取器数据库实例以及预调配实例和 Aurora Serverless v2 数据库实例的组合。因此，要有效使用此功能，了解自动暂停机制的以下方面会很有帮助：
+  数据库实例可能自动暂停的情况。
+  何时可能阻止数据库实例暂停。例如，在集群上启用某些 Aurora 功能或执行某些类型的操作可能会阻止实例暂停，即使与这些实例没有任何连接也是如此。
+  实例暂停期间对监控和计费的影响。
+  哪些操作会导致数据库实例恢复处理。
+  数据库实例的容量在暂停和恢复事件发生前后如何变化。
+  如何控制数据库实例暂停前的空闲间隔。
+  如何对应用程序逻辑进行编码，以处理数据库实例恢复处理的时段。

## Aurora Serverless v2 自动暂停功能的先决条件和限制
先决条件和限制

 在使用自动暂停功能之前，请检查要使用的引擎版本。此外，请检查自动暂停是否可以与您打算使用的其他 Aurora 功能结合使用。如果您使用的引擎版本不支持自动暂停，则无法开启它。对于不兼容的功能，如果将它们与自动暂停结合使用，您不会收到任何错误。如果集群使用任何不兼容的功能或设置，则 Aurora Serverless v2 实例不会自动暂停。
+  如果您使用的是 Aurora PostgreSQL，则运行的数据库引擎版本必须至少是 16.3、15.7、14.12 或 13.15。
+  如果您使用的是 Aurora MySQL，则运行的数据库引擎版本必须是 3.08.0 或以上。
+  有关引擎版本和提供此功能的 Amazon 区域的完整列表，请参阅[支持 Aurora Serverless v2 的区域和 Aurora 数据库引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md)。
+  当 Aurora Serverless v2 实例恢复时，其容量可能会低于暂停时的容量。有关详细信息，请参阅[Aurora Serverless v2 和 Aurora Serverless v1 在自动暂停行为上的区别](#auto-pause-differences)。

 某些情况或设置会阻止 Aurora Serverless v2 实例自动暂停。有关更多信息，请参阅 [Aurora Serverless v2 不会自动暂停的情况](#auto-pause-whynot)。

## 开启和关闭自动暂停功能
开启和关闭自动暂停

 您可以在集群级别开启和关闭自动暂停功能。为此，请使用与调整集群的最小容量和最大容量时相同的过程。自动暂停功能通过 0 ACU 最小容量表示。

**Topics**
+ [开启自动暂停](#auto-pause-enabling)
+ [自动暂停超时间隔](#auto-pause-timeout)
+ [恢复实例](#auto-pause-waking)
+ [关闭自动暂停](#auto-pause-disabling)

### 为集群中的 Aurora Serverless v2 实例开启自动暂停
开启自动暂停

 按照[为集群设置 Aurora Serverless v2 容量范围](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus)中的程序操作。对于最小容量，请选择 0 ACU。当您选择的最小容量为 0 ACU 时，您还可以指定实例在自动暂停之前处于空闲状态的时间长度。

 以下 CLI 示例显示了如何创建一个启用自动暂停功能且自动暂停间隔设置为十分钟（600 秒）的 Aurora 集群。

```
aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password
```

 以下 CLI 示例显示了如何为现有 Aurora 集群开启自动暂停功能。此示例将自动暂停间隔设置为一小时（3600 秒）。

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}
```

### 可配置的 Aurora Serverless v2 自动暂停超时间隔
自动暂停超时间隔

 超时间隔在 Aurora 集群的 `ServerlessV2ScalingConfiguration` 属性中表示。如果最小容量设置为零 ACU，则可以在创建或修改 Aurora 集群时在 Amazon Web Services 管理控制台中指定此间隔。当创建或修改 Aurora 集群时，可以通过使用 `--serverless-v2-scaling-configuration` 参数在 Amazon CLI 中指定它。当创建或修改 Aurora 集群时，可以通过使用 `ServerlessV2ScalingConfiguration` 参数在 RDS API 中指定它。

 您可以设置的最小间隔为 300 秒（5 分钟）。如果您未指定间隔，将采用默认值。您可以设置的最大间隔为 86,400 秒（一天）。

 假设您通过将一个集群的最小容量更改为非零值来关闭该集群的自动暂停功能。在这种情况下，将从 `ServerlessV2ScalingConfiguration` 属性中移除间隔属性。缺少该属性也是在额外确认该集群的自动暂停功能已关闭。如果您稍后重新开启自动暂停功能，则届时可以再次指定任何自定义间隔。

### 恢复自动暂停的 Aurora Serverless v2 实例
恢复实例
+  当您连接到一个已暂停的 Aurora Serverless v2 实例时，它会自动恢复并接受连接。
+  不包含有效凭证的连接尝试仍会导致数据库实例恢复。
+  如果您通过写入器端点进行连接，Aurora 会恢复写入器数据库实例（如果它处于自动暂停状态）。同时，Aurora 会恢复所有自动暂停且失效转移优先级为 0 或 1 的读取器实例，这意味着它们的容量与写入器实例的容量挂钩。
+  如果您通过读取器端点进行连接，Aurora 会随机选择一个读取器实例。如果该读取器实例已暂停，Aurora 会恢复它。同样，Aurora 首先恢复写入器实例，因为只要有任何读取器实例处于活动状态，则写入器实例肯定始终处于活动状态。当 Aurora 恢复该写入器实例时，这也会导致失效转移提升层级零和一中的所有读取器实例恢复。
+  如果您通过 RDS 数据 API 向集群发送请求，Aurora 将恢复写入器实例（如果它被暂停）。然后 Aurora 处理数据 API 请求。
+  当您更改数据库集群参数组中配置参数的值时，Aurora 会自动恢复使用该集群参数组的所有集群中任何已暂停的 Aurora Serverless v2 实例。同样，当您更改数据库参数组中的参数值时，Aurora 会自动恢复使用该数据库参数组的所有已暂停 Aurora Serverless v2 实例。当您修改集群以分配不同的集群参数组，或者修改实例以分配不同的数据库参数组时，同样的自动恢复行为也适用。
+  如果 Aurora Serverless v2 写入器实例已暂停，则执行回溯请求会自动恢复该写入器实例。Aurora 会在写入器实例恢复后处理回溯请求。您可以回溯到 Aurora Serverless v2 实例暂停的时间。
+  拍摄集群快照或删除快照不会导致任何 Aurora Serverless v2 实例恢复。
+  创建 Aurora 克隆会导致 Aurora 恢复正在克隆的集群的写入器实例。
+  如果暂停的实例在完成恢复之前收到大量连接请求，则某些会话可能无法连接。建议实施重试逻辑，以便连接到包含一些启用了自动暂停的 Aurora Serverless v2 实例的 Aurora 集群。例如，您可以重试任何失败的连接三次。
+  Aurora 可以在不唤醒实例的情况下执行某些类型的次要内部维护。但是，在集群维护时段内发生的某些类型的维护确实需要 Aurora 恢复实例。维护完成后，如果在指定的间隔之后没有其他活动，则实例将再次自动暂停。
**注意**  
 Aurora 不会为了特定于引擎的计划作业（例如 PostgreSQL `pg_cron` 扩展或 MySQL 事件调度器中的作业）恢复暂停的实例。为确保此类作业运行，请在预定时间之前手动启动与实例的连接。在数据库实例暂停期间，Aurora 不会对计划时间发生的任何作业进行排队。当实例稍后恢复时，会跳过此类作业。
+  如果 Aurora 集群在 Aurora Serverless v2 实例自动暂停时进行失效转移，Aurora 可能会先恢复一个实例，然后将该实例提升为写入器。如果在实例暂停期间从集群中移除一个或多个数据库实例，也会发生同样的情况。在这种情况下，实例在恢复后立即成为写入器。
+  更改集群属性的操作还会导致任何自动暂停的 Aurora Serverless v2 实例恢复。例如，自动暂停的实例会因以下操作而恢复：
  +  更改集群的扩展范围。
  +  升级集群的引擎版本。
  +  描述或下载来自已暂停实例的日志文件。可以通过向 CloudWatch 上传日志并通过 CloudWatch 分析日志，来检查已暂停实例的历史日志数据。

### 关闭集群中 Aurora Serverless v2 实例的自动暂停
关闭自动暂停

 按照[为集群设置 Aurora Serverless v2 容量范围](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus)中的程序操作。对于最小容量，请选择 0.5 或更大的值。关闭自动暂停功能后，实例空闲的时间间隔将被重置。如果再次开启自动暂停，则需要指定新的超时间隔。

 以下 CLI 示例显示了如何关闭现有 Aurora 集群的自动暂停功能。`describe-db-clusters` 输出显示，当最小容量设置为非零值时，`SecondsUntilAutoPause` 属性被移除。

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}
```

## Aurora Serverless v2 自动暂停功能的工作原理
自动暂停功能的工作原理

 您可以使用以下信息来计划使用自动暂停功能。了解实例暂停、恢复或保持活跃状态的情况可以帮助您在可用性、响应能力和成本节约之间进行权衡。

**Topics**
+ [自动暂停功能的工作原理](#auto-pause-pausing)
+ [自动恢复功能的工作原理](#auto-pause-resuming)
+ [CPU 计费](#auto-pause-billing)
+ [阻止自动暂停的情况](#auto-pause-whynot)
+ [与集群停止/启动的比较](#auto-pause-stop-start)
+ [维护和升级](#auto-pause-maintenance)
+ [与 Aurora Serverless v1 比较](#auto-pause-differences)

### 当 Aurora Serverless v2 实例暂停时会发生什么情况
自动暂停功能的工作原理

 当 Aurora Serverless v2 数据库实例在一段时间没有连接后暂停时：
+  无论实例当时有多少 ACU，只要经过指定的间隔没有与实例的连接，Aurora 就开始暂停实例。
+  暂停机制不是瞬间的。即将自动暂停的 Aurora Serverless v2 实例可能会稍等片刻才能跟上对 Aurora 存储的所有更改。
+  针对该实例的收费暂停。实例暂停时，`ServerlessV2Usage` 指标的值为 0。
+  实例的状态值不变。状态仍显示为“可用”。
+  实例停止写入数据库日志文件。它会停止向 CloudWatch 发送指标，除了将 `CPUUtilization` 和 `ACUUtilization` 记录为零百分比，以及将 `ServerlessDatabaseCapacity` 记录为零。
+  当 Aurora Serverless v2 数据库实例开始暂停、完成暂停以及暂停机制中断或失败时，Aurora 会发出事件。有关这些事件的详细信息，请参阅[数据库实例事件](USER_Events.Messages.md#USER_Events.Messages.instance)。

### 当自动暂停的 Aurora Serverless v2 实例恢复时会发生什么情况
自动恢复功能的工作原理

 当 Aurora Serverless v2 数据库实例在自动暂停后恢复时，会发生以下情况：
+  当实例恢复时，会应用 `pending-reboot` 更改中的任何参数更改。
+  当每个 Aurora Serverless v2 数据库实例开始恢复、完成恢复以及实例由于某种原因无法恢复时，Aurora 会发出实例级别的事件。有关这些事件的详细信息，请参阅[数据库实例事件](USER_Events.Messages.md#USER_Events.Messages.instance)。
+  当数据库实例完成恢复后，将建立任何请求的连接。由于恢复的时间通常约为 15 秒，所以建议您将任何客户端超时设置调整为比 15 秒更长一些。例如，在 JDBC 驱动程序设置中，可以将 `connectTimeout` 和 `sslResponseTimeout` 设置的值调整为超过 15 秒。

**注意**  
 如果 Aurora Serverless v2 实例暂停超过 24 小时，Aurora 可以让该实例进入更深的睡眠状态，这就需要更长的时间才能恢复。在这种情况下，恢复时间可以是 30 秒或更长，大致相当于重启实例的时间。如果您的数据库的非活动时间超过一天，建议将连接超时设置为 30 秒或更长时间。

### 自动暂停的 Aurora Serverless v2 集群的实例计费方法
CPU 计费

 当 Aurora Serverless v2 实例自动暂停时，其实例费用为零。在此期间，`ServerlessV2Usage` 指标为零。Amazon 仍会对 Aurora 存储和集群中与该特定数据库实例无关的其他方面收费。

### Aurora Serverless v2 不会自动暂停的情况
阻止自动暂停的情况
+  如果您的数据库集群的最小容量值高于零 ACU，则集群中的 Aurora Serverless v2 实例不会自动暂停。如果您的现有集群中包含自动暂停功能推出之前的 Aurora Serverless v2 实例，则最低的最小容量设置为 0.5 ACU。要对此类集群使用自动暂停功能，请将最小容量设置修改为零 ACU。
+  如果任何用户发起的与 Aurora Serverless v2 实例的连接处于打开状态，则该实例不会暂停。在修补和升级等活动进行期间，实例也不会暂停。Aurora 用于运行状况检查的管理连接不算作活动，因此不会阻止实例暂停。
+  在启用了逻辑复制的 Aurora PostgreSQL 集群中，或者在启用了二进制日志复制的 Aurora MySQL 集群中，写入器实例和失效转移提升层级零和一中的任何读取器实例都不会自动暂停。Aurora 会为了检查复制连接的运行状况而执行一个恒定的最低量的活动。

   对于启用了复制功能的集群，您仍然可以在源集群中拥有自动暂停的 Aurora 读取器实例。为此，请将它们的失效转移优先级设置为零或一以外的值。这样，它们就可以独立于写入器实例暂停。
+  如果您的 Aurora 集群具有关联的 RDS 代理，则该代理会保持与集群中每个数据库实例的打开连接。因此，此类集群中的任何 Aurora Serverless v2 实例都不会自动暂停。
+  如果您的集群是 Aurora Global Database 中的主集群，则 Aurora 不会自动暂停 Aurora Serverless v2 写入器实例。这是因为写入器实例上需要一个恒定水平的活动来管理全局数据库中的其他集群。由于写入器实例保持活动状态，所以任何失效转移优先级为零或一的 Aurora Serverless v2 读取器实例也不会自动暂停。
+  Aurora Global Database 的辅助集群中的 Aurora Serverless v2 实例不会自动暂停。如果数据库集群升级为独立集群，并且所有其他条件都满足，则自动暂停功能变为有效。
+  在具有与 Redshift 关联的零 ETL 集成的集群中，写入器实例和失效转移提升层级零和一中的任何读取器实例都不会自动暂停。
+  除了实例的主数据库端口上的活动外，如果 Aurora PostgreSQL 实例还启用了 Babelfish 功能，则 T-SQL 端口上的任何连接和活动都将阻止该实例自动暂停。

### 自动暂停如何与集群停止/启动功能配合使用
与集群停止/启动的比较

 启用自动暂停功能后，您可以停止和启动 Aurora 集群。某些实例是否已暂停都没关系。当您再次启动集群时，任何已暂停的 Aurora Serverless v2 实例都会自动恢复。

 当 Aurora 集群停止时，任何已暂停的 Aurora Serverless v2 实例都不会根据连接尝试自动恢复。集群再次启动后，将采用暂停和恢复 Aurora Serverless v2 实例的常用机制。

### 自动暂停的 Aurora Serverless v2 集群的维护和升级工作原理
维护和升级
+  当一个 Aurora Serverless v2 实例自动暂停时，如果您尝试升级 Aurora 集群，Aurora 会恢复该实例并升级它。
+  Aurora 会定期恢复所有自动暂停的 Aurora Serverless v2 实例，以执行维护，例如次要版本升级和对参数组等属性进行更改。
+  当一个 Aurora Serverless v2 实例被唤醒以执行管理操作（例如升级或应用维护）后，Aurora 会等待至少 20 分钟才会再次暂停该实例。这将允许任何后台操作完成。如果实例连续经历多个管理操作，这二十分钟的时间段还能避免多次暂停和恢复实例。

### Aurora Serverless v2 和 Aurora Serverless v1 在自动暂停行为上的区别
与 Aurora Serverless v1 比较
+  与 Aurora Serverless v1 相比，Aurora Serverless v2 中的恢复时间有所缩短。如果实例的暂停时间少于 24 小时，则恢复时间通常约为 15 秒。如果实例的暂停时间超过 24 小时，则恢复时间可能会更长。
+  Aurora Serverless v2 应用于多可用区集群的方式意味着集群中一些数据库实例可能暂停，而另一些则处于活动状态。只要有读取器在运行，写入器实例就会恢复，因为需要写入器来协调集群中的某些活动。因为 Aurora Serverless v1 不使用读取器实例，所以整个集群将始终处于暂停或活动状态。
+  当读取器端点随机选择一个读取器实例来连接时，该读取器实例可能已经处于活动状态或可能已自动暂停。因此，访问读取器实例的时间可能不同且很难预测。使用 Aurora Serverless v2 和自动暂停的多可用区集群因而可能受益于为特定的只读用例设置自定义端点，而不是将所有只读会话定向到读取器端点。
+  Aurora Serverless v2 实例经历维护操作的频率与预调配实例相同。因为 Aurora 会在需要此类维护时自动恢复实例，所以您可能发现 Aurora Serverless v2 实例的恢复频率高于 Aurora Serverless v1 集群。

## Aurora Serverless v2 自动暂停如何适用于不同类型的 Aurora 集群
自动暂停和 Aurora 集群配置

 自动暂停功能的注意事项取决于您的 Aurora 集群中有多少实例、读取器实例的失效转移提升层级以及实例都是 Aurora Serverless v2 实例还是 Aurora Serverless v2 实例与预调配实例的组合。

**Topics**
+ [Aurora 集群布局](#auto-pause-recommended-layouts)
+ [写入器实例的自动暂停](#auto-pause-writer)
+ [多可用区集群和读取器实例的自动暂停](#auto-pause-multi-az)
+ [混合集群的自动暂停](#auto-pause-provisioned)

### 使用自动暂停时推荐的 Aurora 集群布局
Aurora 集群布局

 启用自动暂停功能时，您可以安排 Aurora 集群布局，以便在高可用性、快速响应和可扩展性之间取得适当的平衡，来适应您的用例。为此，您可以为集群中的数据库实例选择 Aurora Serverless v2 实例、预调配实例和失效转移提升层级的组合。

 以下类型的配置演示了集群的高可用性和成本优化之间的不同权衡：
+  对于开发和测试系统，您可以设置包含 Aurora Serverless v2 数据库实例的单可用区数据库集群。该单个实例可服务于所有读取和写入请求。当集群在很长一段时间内未使用时，数据库实例会暂停。此时，您的集群的数据库计算成本也会暂停。
+  对于运行优先考虑高可用性的应用程序、但集群仍有完全空闲时期的系统，您可以设置一个其中的写入器和读取器数据库实例都是 Aurora Serverless v2 的多可用区集群。将读取器实例设置为失效转移优先级为零或一，以便写入器和读取器实例同时暂停和恢复。现在，您可以在集群处于活动状态时获得快速失效转移的好处。当集群的闲置时间超过自动暂停阈值时，两个实例的数据库实例费用都将暂停。当集群恢复处理时，第一个数据库会话需要很短的时间即可连接。
+  假设您的集群一直处于活动状态，但活动量极少，并且任何连接都需要快速响应。在这种情况下，您可以创建一个包含多个 Aurora Serverless v2 读取器实例的集群，并将某些读取器实例的容量与写入器解耦。将写入器实例和某个读取器实例的失效转移优先级指定为零或一。为其他读取器实例指定大于一的优先级。这样，即使写入器和其中一个读取器保持活动状态，优先级较高的读取器实例也可以自动暂停。

   在这种情况下，您可以采用其他一些方法来确保集群保持持续可用，同时在空闲期间仍可缩减到低容量：
  +  您可以为写入器和优先级为 0 或 1 的读取器使用预调配实例。这样，两个数据库实例就永远不会自动暂停，从而始终可用于服务数据库流量和执行失效转移。
  +  您可以设置一个自定义端点，其中包含优先层级较高的 Aurora Serverless v2 实例，但不包含写入器或提升层级为 0 或 1 的读取器。这样，您就可以将对延迟不敏感的只读会话定向到可能被自动暂停的读取器。您可以避免将读取器端点用于此类请求，因为 Aurora 可能会将读取器端点连接定向到始终处于唤醒状态的读取器实例或自动暂停的实例之一。使用自定义端点，您可以根据自己对快速响应或额外扩展容量的偏好将连接定向到不同的实例组。

### Aurora Serverless v2 自动暂停如何用于数据库集群中的写入器实例
写入器实例的自动暂停

 当 Aurora 数据库集群仅包含一个数据库实例时，自动暂停和恢复数据库实例的机制非常简单。它仅取决于写入器实例上的活动。对于用于开发和测试的集群，或者为了运行高可用性不重要的应用程序，您可以采取此类配置。请注意，在单实例集群中，Aurora 会通过读取器端点将连接定向到写入器数据库实例。因此，对于单实例数据库集群来说，尝试连接到读取器端点会导致自动暂停的写入器数据库实例恢复。

 以下额外因素适用于具有多个数据库实例的 Aurora 集群：
+  在 Aurora 数据库集群中，写入器数据库实例通常被频繁访问。因此，您可能会发现，即使一个或多个读取器数据库实例自动暂停，写入器数据库实例仍保持活动状态。
+  读取器数据库实例上的某些活动要求该写入器数据库实例可用。因此，写入器数据库实例要等到所有读取器实例都暂停后方能暂停。即使您的应用程序没有直接访问写入器实例，恢复任何读取器实例也会自动恢复写入器实例。
+  失效转移提升层级为零和一的 Aurora Serverless v2 读取器实例会进行扩展，以确保容量与写入器实例保持同步。因此，当 Aurora Serverless v2 写入器实例恢复时，提升层级为零或一的任何 Aurora Serverless v2 读取器实例也会恢复。

### Aurora Serverless v2 自动暂停如何用于多可用区集群
多可用区集群和读取器实例的自动暂停

 在同时包含一个写入器和一个或多个读取器数据库实例的 Aurora 数据库集群中，某些 Aurora Serverless v2 数据库实例可能会暂停，而其他数据库实例则处于活动状态。写入器实例和任何失效转移优先级为 0 和 1 的读取器实例始终同时暂停和恢复。优先级不是 0 或 1 的读取器实例可以独立于其他实例暂停和恢复。

 当您将此功能用于具有多个读取器实例的集群时，可以在不牺牲高可用性的情况下管理成本。写入器实例和另外一个或两个读取器实例可以始终保持活动状态，而其他读取器实例可以在不需要处理高容量读取流量时暂停。

 读取器实例能否自动暂停取决于其容量能否独立扩展，或者其容量是否与写入器数据库实例的容量挂钩。该扩缩属性取决于读取器数据库实例的失效转移优先级。当读取器的优先级为零或一时，读取器的容量将跟踪写入器数据库实例的容量。因此，要允许读取器数据库实例在最广泛的情况下自动暂停，请将其优先级设置为大于 1 的值。

 恢复读取器实例的时间可能比恢复写入器实例的时间稍长一些。如果实例可能暂停，要获得最快的响应，请连接到集群端点。

### Aurora Serverless v2 自动暂停如何用于包含预调配实例的集群
混合集群的自动暂停

 Aurora 数据库集群中的任何预调配数据库实例都不会自动暂停。只有实例类为 `db.serverless` 的 Aurora Serverless v2 数据库实例才能使用自动暂停功能。

 当您的 Aurora 集群包含任何预配置的数据库实例时，任何 Aurora Serverless v2 写入器实例都不会自动暂停。这是因为在任何读取器实例处于活动状态时，写入器实例必须保持可用。Aurora Serverless v2 写入器保持活动状态这一事实也意味着，在包含任何预调配实例的混合集群中，任何失效转移优先级为 0 和 1 的 Aurora Serverless v2 读取器实例都不会自动暂停。

## 监控使用自动暂停功能的 Aurora 集群
监控自动暂停

 要监控 Aurora，您应该已经熟悉[使用 Amazon CloudWatch 监控 Amazon Aurora 指标](monitoring-cloudwatch.md)中的监控程序和 [Amazon Aurora 的指标参考](metrics-reference.md)中列出的 CloudWatch 指标。请注意，监控使用自动暂停功能的 Aurora 集群时，有一些特殊注意事项：
+  因为实例暂停，会有一些时间段 Aurora Serverless v2 实例不记录日志数据和大多数指标。实例暂停期间发送到 CloudWatch 的指标只有 `CPUUtilization` 和 `ACUUtilization` 为零百分比以及 `ServerlessDatabaseCapacity` 为零。
+  您可以检查 Aurora Serverless v2 实例暂停的频率比您预计的高还是低。为此，请检查 `ServerlessDatabaseCapacity` 指标从非零值变为零的频率以及保持零的时间长度。如果实例的暂停时间没有您预计的那么长，表明您还没有节省尽可能多的成本。如果实例的暂停和恢复频率高于您的预期，表明您的集群在响应连接请求时可能存在不必要的延迟。有关影响 Aurora Serverless v2 实例能否暂停以及暂停频率的因素的信息，请参阅 [Aurora Serverless v2 自动暂停功能的先决条件和限制](#auto-pause-prereqs)、[Aurora Serverless v2 不会自动暂停的情况](#auto-pause-whynot)和 [Aurora Serverless v2 自动暂停故障排查](#auto-pause-troubleshooting)。
+  您还可以检查记录 Aurora Serverless v2 实例自动暂停和恢复操作的日志文件。如果实例在超时间隔到期后没有暂停，则此日志文件还会包含未自动暂停的原因。有关更多信息，请参阅 [监控 Aurora Serverless v2 暂停和恢复活动](aurora-serverless-v2-administration.md#autopause-logging-instance-log)。

**Topics**
+ [检查暂停的实例](#auto-pause-status)
+ [自动暂停和自动恢复事件](#auto-pause-events)
+ [性能详情和增强监控](#auto-pause-pi-em)
+ [Aurora 指标](#auto-pause-metrics)

### 检查 Aurora Serverless v2 实例是否已暂停
检查暂停的实例

 要确定某个 Aurora Serverless v2 实例是否处于暂停状态，您可以观察该实例的 `ACUUtilization` 指标。如果实例暂停，则该指标的值为零。

 当 Aurora Serverless v2 实例暂停时，其状态值仍列为**可用**。当暂停的 Aurora Serverless v2 实例正在恢复时也是如此。这是因为即使连接稍有延迟，您仍然可以成功连接到此类实例。

 任何与 Aurora 实例可用性相关的指标都将实例暂停时期视为实例可用时期。

### 自动暂停和自动恢复操作事件
自动暂停和自动恢复事件

 当自动暂停和自动恢复操作开始、完成或取消时，Aurora 会为 Aurora Serverless v2 实例发出事件。与自动暂停功能相关的事件为 `RDS-EVENT-0370` 至 `RDS-EVENT-0374`。有关这些事件的详细信息，请参阅[数据库实例事件](USER_Events.Messages.md#USER_Events.Messages.instance)。

### 自动暂停如何与性能详情和增强监控功能配合使用
性能详情和增强监控

 在 Aurora Serverless v2 实例暂停期间，Aurora 不会通过性能详情或增强监控功能收集该实例的监控信息。实例恢复后，可能会延迟一小会儿，然后 Aurora 才恢复收集此类监控信息。

### Aurora Serverless v2 自动暂停功能如何与 Aurora 指标交互
Aurora 指标

 当某个 Aurora Serverless v2 实例暂停时，它不会发出大多数 CloudWatch 指标，也不会向其数据库日志写入任何信息。实例暂停期间发送到 CloudWatch 的指标只有 `CPUUtilization` 和 `ACUUtilization` 为零百分比以及 `ServerlessDatabaseCapacity` 为零。

 当 CloudWatch 计算与实例或集群可用性和正常运行时间相关的统计数据时，Aurora Serverless v2 实例被视为在暂停期间可用。

 当您启动 Amazon CLI 或 RDS API 操作来描述或下载已暂停 Aurora Serverless v2 实例的日志时，该实例会自动恢复以使日志信息可用。

#### CloudWatch 指标示例


 以下 Amazon CLI 示例显示了如何观察随时间推移而变化的实例容量。在这段时间内，实例会自动暂停，然后恢复。暂停时，`ServerlessDatabaseCapacity` 指标报告零值。为了确定该时间段内实例是否在任何时候暂停，我们会检查该时间段内的最小容量是否为零。

 以下 Linux 示例表示一个已自动暂停一段时间的 Aurora Serverless v2 实例。我们在三分钟内每分钟对 `ServerlessDatabaseCapacity` 采样一次。最小 ACU 值为 0.0 表明实例在每分钟内的某个时刻处于暂停状态。

```
$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
```

 接下来，我们尝试与已暂停的 Aurora Serverless v2 实例建立连接。在此示例中，我们故意使用了错误的密码，以使连接尝试失败。尽管失败了，但连接尝试仍会导致 Aurora 恢复已暂停的实例。

```
$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)
```

 以下 Linux 示例演示了暂停的实例被恢复，在闲置了大约五分钟后，又回到暂停状态。实例恢复时的容量为 2.0 ACU。然后它会稍微扩展，例如为了执行一些内部清理任务。由于该实例在五分钟的超时时间段内没有收到任何用户连接尝试，所以它从 4.0 ACU 直接进入暂停状态。

```
$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None
```

 如果报告旨在显示实例如何快速扩展以处理工作负载，则我们可以为统计数据指定 `Maximum` 而不是 `Minimum`。对于容量规划和成本估算，我们可以指定更长的时间段并使用 `Average` 统计数据。这样，我们就可以确定高度活动、低度活动和暂停状态期间的典型容量值。为了检查暂停和恢复前后的精确时间段内的行为，我们可以指定一秒钟的时间段并检查更短的时间间隔。输出中的时间戳值（例如 `2024-08-02T22:13:00+00:00`）演示了为 `--start-time` 和 `--end-time` 选项指定精确参数的格式。

## Aurora Serverless v2 自动暂停故障排查
自动暂停故障排查

 如果您发现 Aurora Serverless v2 实例没有按您的预计频率暂停，请检查以下可能的原因：
+  确认您正在运行的 Aurora 版本确实支持零 ACU 的最小容量。有关不同 Aurora 版本的容量范围，请参阅 [Aurora Serverless v2 容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)。
+  确认集群的最小容量值已设置为零 ACU。
+  确认有问题的实例实际上使用 Aurora Serverless v2 实例类 `db.serverless`，而不是预调配的实例类之一。
+  确认集群未使用任何不兼容的功能或设置，详情参见 [Aurora Serverless v2 自动暂停功能的先决条件和限制](#auto-pause-prereqs)。
+  检查相关日志文件，其中会显示 Aurora Serverless v2 实例何时暂停、恢复或 Aurora 由于某种原因而无法暂停或恢复实例。有关更多信息，请参阅 [监控 Aurora Serverless v2 暂停和恢复活动](aurora-serverless-v2-administration.md#autopause-logging-instance-log)。
+  检查是否有任何客户端或应用程序长时间保持连接打开。反过来，检查是否有使用 RDS 数据 API 或 Lambda 函数的应用程序频繁发送请求，导致实例一直闲不下来，无法暂停。您可以检查 CloudWatch 指标，例如 `ConnectionAttempts` 和 `DatabaseConnections`。有关更多信息，请参阅 [Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
+  如果读取器实例极少暂停，请检查其失效转移优先级。如果读取器用于读取扩展，而不是在失效转移时用作备用读取器，请为其设置 2-15 范围的优先级。
+  如果写入器实例极少暂停，请检查您对读取器实例的使用情况。只有整个集群处于空闲状态时，写入器才能暂停。这是因为连接任何读取器实例时都会导致写入器恢复。
+  在 Aurora Serverless v2 实例正在恢复时，如果您的应用程序在连接请求期间收到超时，请考虑延长应用程序代码或底层数据库框架使用的超时间隔。在 Aurora Serverless v2 实例正在恢复时，较长的连接超时可降低连接失败的可能性。但是，较长的超时也会使您的应用程序检测集群中可用性问题的速度变慢。

   反过来，可以考虑延长自动暂停间隔，这样应用程序就不会经常遇到暂停的实例。

   如果应用程序的自动暂停行为和集群响应之间没有逻辑上的平衡，则该集群可能不适合使用自动暂停功能。
+  在估计 Aurora Serverless v2 实例将暂停多久时，请注意有些因素的存在会导致无法做出精确预测。
  +  实例可能会定期恢复，以执行维护、次要版本升级或应用参数组更改。
  +  对于多可用区集群，在某些情况下，恢复一个实例会导致其他实例也恢复。恢复任何读取器总是会导致恢复写入器。恢复写入器总是会导致恢复失效转移优先级为 0 和 1 的所有读取器。

   建议使用实际的工作负载来测定几天内的实际暂停时间。然后，使用这些测定值设置一个基准，来预计一个实例会暂停的时间比例。
+  您可能会发现，诸如 MySQL 清除、MySQL 事件调度器、PostgreSQL 自动清理或通过 `pg_cron` 扩展安排的 PostgreSQL 作业之类的内部操作没有运行或未完成。实例不会自动恢复以执行不涉及用户与数据库的连接的此类操作。如果在自动暂停超时到期时此类内部操作正在进行中，则会取消 MySQL 清除和 PostgreSQL 自动清理等维护任务。当 Aurora 启动暂停操作时，来自 MySQL 事件调度器或 PostgreSQL `pg_cron` 扩展的计划作业假如正在进行，则也会被取消。

   如果您需要确保实例定期被唤醒以执行计划操作，则可以在作业开始之前启动连接来恢复实例。您还可以延长自动暂停的超时间隔，以便像自动清理之类的操作可以在用户活动完成后运行更长的时间。您还可以使用诸如 Lambda 函数之类的机制来按计划执行数据库操作，且必要时可以自动恢复实例。

## Aurora Serverless v2 自动暂停功能的应用程序设计注意事项
自动暂停的应用程序设计

 当 Aurora Serverless v2 数据库实例在自动暂停后恢复时，它先从相对较小的容量开始，然后在此基础上扩展。即使数据库实例在自动暂停之前不久还有很高的容量，也适用这一起始容量。

 对于在建立连接时可以容忍大约 15 秒间隔的应用程序，请使用此功能。这反映了 Aurora Serverless v2 实例由于一个或少量传入连接而恢复的典型情况。如果实例的暂停时间超过 24 小时，则恢复的时间可能会更长。

 如果您的应用程序已经在使用 Aurora Serverless v1 及其自动暂停功能，则您可能已经为连接尝试设置了这样的超时间隔。如果您已经在将 Aurora Serverless v2 与 Aurora 停止/启动集群功能结合使用，则自动暂停的 Aurora Serverless v2 实例的恢复时间通常比启动已停止的集群的时间短得多。

 在应用程序中对连接逻辑进行编码时，如果第一次尝试返回的错误是暂时性的，请重试连接。（如果错误是由身份验证失败引起的，请在重试之前更正凭证。） 恢复后紧接着发生的错误可能是超时，或者是与数据库限制相关的错误。对于 Aurora Serverless v2 实例恢复是由同时存在大量连接请求引起的这种较罕见情形，重试可以解决问题。在这种情况下，某些连接的处理时间可能比平时长，或者可能在第一次尝试时超过同时连接的限制。

 在应用程序开发和调试期间，不要留下与数据库的连接处于打开状态的客户端会话或编程工具。如果有任何用户启动的连接处于打开状态，Aurora 都不会暂停该实例，无论这些连接是否未运行任何 SQL 语句或事务。当 Aurora 集群中的一个 Aurora Serverless v2 实例无法暂停时，集群中的其他实例可能也无法暂停。有关更多信息，请参阅 [Aurora Serverless v2 不会自动暂停的情况](#auto-pause-whynot)。

 当 Aurora Serverless v2 数据库实例开始恢复、完成恢复以及实例由于某种原因无法恢复时，Aurora 会发出事件。有关这些事件的详细信息，请参阅[数据库实例事件](USER_Events.Messages.md#USER_Events.Messages.instance)。