Aurora Serverless v2 的性能和扩缩 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Aurora Serverless v2 的性能和扩缩

以下程序和示例说明如何设置 Aurora Serverless v2 集群的容量范围及其关联的数据库实例。您还可以使用以下程序来监控数据库实例的繁忙程度。然后,您可以使用结果来确定是需要向上还是向下调整容量范围。

在使用这些程序之前,请确保熟知 Aurora Serverless v2 扩缩的工作原理。该扩缩机制不同于 Aurora Serverless v1 的扩缩机制。有关详细信息,请参阅 Aurora Serverless v2 扩缩

选择 Aurora 集群的 Aurora Serverless v2 容量范围

对于 Aurora Serverless v2 数据库实例,您可以在添加第一个 Aurora Serverless v2 数据库实例到数据库集群的时候设置适用于数据库集群中所有数据库实例的容量范围。有关执行此操作的程序,请参阅为集群设置 Aurora Serverless v2 容量范围

您还可以更改现有集群的容量范围。以下部分更详细地介绍了如何选择适当的最小值和最大值,以及在更改容量范围时会发生什么。例如,更改容量范围会修改某些配置参数的默认值。应用所有参数更改需要重新启动每个 Aurora Serverless v2 数据库实例。

选择集群的最小 Aurora Serverless v2 容量设置

最好是始终为最小 Aurora Serverless v2 容量设置选择 0.5。该值让数据库实例可以在完全空闲时最大限度地缩减。但是,根据您使用该群集的方式和配置的其他设置,设置为另一个值可能会更高效。选择最小容量设置时,请考虑以下因素:

  • Aurora Serverless v2 数据库实例的扩缩率取决于其当前容量。当前容量越大,扩展速度就越快。如果您需要数据库实例快速扩展到非常高的容量,请考虑将最小容量设置为其扩缩率可满足要求的值。

  • 如果您通常在预期工作负载特别高或特别低的情况下修改数据库实例的数据库实例类,则可以利用这个经验粗略估计等效的 Aurora Serverless v2 容量范围。要确定在低流量时使用的内存大小,请参阅 适用于 Aurora 的数据库实例类的硬件规格

    例如,假设您在集群的工作负载较低时使用 db.r6g.xlarge 数据库实例类。该数据库实例类具有 32 GiB 的内存。因此,您可以将最小 Aurora 容量单位(ACU)设置指定为 16,从而设置一个可以缩减至大约是这个相同容量的 Aurora Serverless v2 数据库实例。那是因为每个 ACU 对应大约 2 GiB 的内存。如果 db.r6g.xlarge 数据库实例有时未充分利用,您可以指定一个稍低的值,以便进一步缩减数据库实例。

  • 如果当数据库实例在缓冲区缓存中有一定量的数据时,应用程序的运行效率最高,请考虑指定一个最小 ACU 设置,让内存足够大,可以容纳经常访问的数据。否则,当 Aurora Serverless v2 数据库实例缩减至较小的内存大小时,一些数据会从缓冲区缓存中移出。然后,随着时间的推移,当数据库实例再扩展回来时,信息会读回到缓冲区缓存中。如果将数据带回缓冲区缓存的 I/O 量很大,则选择更高的最小 ACU 值可能会更有效。

  • 如果您的 Aurora Serverless v2 数据库实例大部分时间都以特定容量运行,请考虑指定低于该基准但不要太低的最小容量设置。Aurora Serverless v2当前容量没有远低于所需容量时,Aurora Serverless v2 数据库实例可以最有效地估计扩展的规模和速度。

  • 如果您的预置工作负载的内存要求对于 T3 或 T4g 等小型数据库实例类而言太高,请选择可提供与 R5 或 R6g 数据库实例的内存相当的最低 ACU 设置。

    特别是,我们建议在使用指定特征时使用以下最低容量(这些建议可能会发生变化):

    • 性能详情 – 2 个 ACU

    • Aurora 全局数据库 – 8 个 ACU(仅适用于主要 Amazon Web Services 区域)

  • 在某些情况下,您的集群可能包含可独立于写入器进行扩缩的 Aurora Serverless v2 读取器数据库实例。如果是这样,请选择一个足够高的最小容量设置,以便当写入器数据库实例忙于写入密集型工作负载时,读取器数据库实例可以毫不落后地应用来自写入器的更改。如果在提升层 2-15 的读取器中观察到复制滞后,请考虑增大集群的最小容量设置。有关选择读取器数据库实例是随写入器扩缩还是独立扩缩的详细信息,请参阅为 Aurora Serverless v2 读取器选择提升层

  • 如果您的数据库集群包含 Aurora Serverless v2 读取器数据库实例,则当读取器的提升层不是 0 或 1 时,读取器不会随写入器数据库实例一起扩展。在这种情况下,设置较低的最小容量会导致复制滞后过大。这是因为在数据库忙碌时,读取器可能没有足够的容量来应用来自写入器的更改。我们建议您将最小容量设置为一个值,该值表示与写入器数据库实例相当的内存量和 CPU 量。

  • Aurora Serverless v2 数据库实例的 max_connections 参数的值基于从最大 ACU 得出的内存大小。但是,当您在 PostgreSQL 兼容的数据库实例上指定 0.5 个 ACU 的最小容量时,max_connections 最大值的上限为 2000。

    如果您打算将 Aurora PostgreSQL 集群用于重要连接工作负载,请考虑使用值为 1 或更高的最低 ACU 设置。有关 Aurora Serverless v2 如何处理 max_connections 配置参数的详细信息,请参阅 Aurora Serverless v2 的最大连接数

  • Aurora Serverless v2 数据库实例从最小容量扩展到最大容量所花的时间取决于其最小和最大 ACU 值之间的差异。与数据库实例从小容量开始的情况相比,当数据库实例的当前容量很大时,Aurora Serverless v2 会以更大的增量扩展。因此,如果您指定了相对较大的最大容量,且数据库实例的大部分运行时间都接近该容量,则请考虑增大最小 ACU 设置。这样,空闲数据库实例可以更快地扩展回到最大容量。

选择集群的最大 Aurora Serverless v2 容量设置

最好是始终为最大 Aurora Serverless v2 容量设置选择一些较高的值。较大的最大容量让数据库实例可以在运行密集型工作负载时最大限度地扩展。使用较小的值可以避免产生意外费用。根据您使用该群集的方式以及配置的其他设置,最有效的值可能会比原先想象的值更高或更低。选择最大容量设置时,请考虑以下因素:

  • 最大容量必须至少与最小容量相同。可以将最小容量和最大容量设置为完全相同。但是,在这种情况下,容量永远不会扩展或缩减。因此,除了在测试状况下,对最小和最大容量使用完全相同的值并不合适。

  • 最大容量必须高于 0.5 ACU。在大多数情况下,可以将最小容量和最大容量设置为相同。但是,您不能将最小值和最大值同时指定为 0.5。请为最大容量使用 1 或更高的值。

  • 如果您通常在预期工作负载特别高或特别低的情况下修改数据库实例的数据库实例类,则可以利用这个经验估计等效的 Aurora Serverless v2 容量范围。要确定在高流量时使用的内存大小,请参阅 适用于 Aurora 的数据库实例类的硬件规格

    例如,假设您在集群的工作负载较高时使用 db.r6g.4xlarge 数据库实例类。该数据库实例类具有 128 GiB 的内存。因此,您可以将最大 ACU 设置指定为 64,从而设置一个可以扩展至大约是这个相同容量的 Aurora Serverless v2 数据库实例。那是因为每个 ACU 对应大约 2 GiB 的内存。如果 db.r6g.4xlarge 数据库实例有时没有足够的容量来有效处理工作负载,则可以指定一个稍高的值来让数据库实例进一步扩展。

  • 如果您的数据库使用有预算上限,请选择一个即使所有 Aurora Serverless v2 数据库实例始终以最大容量运行时仍能保持在该上限内的值。请记住,如果您的集群中有 n 个 Aurora Serverless v2 数据库实例,则该集群在任何时刻可以使用的理论最大 Aurora Serverless v2 容量是 n 乘以集群的最大 ACU 设置。(例如,如果一些读取器独立于写入器进行扩展,则实际消耗量可能更少。)

  • 如果您使用 Aurora Serverless v2 读取器数据库实例从写入器数据库实例中分流一些只读工作负载,您可以选择较低的最大容量设置。这样做是为了反映这一点,每个读取器数据库实例不需要像集群只包含一个数据库实例那样扩展得那么高。

  • 假设您想防止由于应用程序中的数据库参数配置错误或低效查询而导致过度使用。在这种情况下,您可以通过选择一个最大容量设置,使之低于可以设置的绝对最高容量,从而避免意外过度使用。

  • 如果由于实际用户活动造成的峰值很少见但确实会发生,那么在选择最大容量设置时可以考虑这些情况。如果优先级是使应用程序以全面的性能和可扩展性保持运行,则可以指定比正常使用情况下的容量更大的最大容量设置。如果在非常极端的活动高峰期间应用程序可以降低吞吐量运行,则可以选择稍低的最大容量设置。确保选择的设置仍然有足够的内存和 CPU 资源以使应用程序保持运行。

  • 如果您在集群中启用了增加每个数据库实例内存使用量的设置,请在决定最大 ACU 值时将该内存考虑在内。此类设置包括 Performance Insights、Aurora MySQL 并行查询、Aurora MySQL 性能架构和 Aurora MySQL 二进制日志复制的设置。确保最大 ACU 值允许 Aurora Serverless v2 数据库实例扩展到足以在使用这些特征时处理工作负载。有关排除由于低最大 ACU 设置和增加内存开销的 Aurora 特征组合而引起的问题的信息,请参阅避免内存不足错误

示例:更改 Aurora MySQL 集群的 Aurora Serverless v2 容量范围

以下 Amazon CLI 示例显示了如何更新现有 Aurora MySQL 集群中的 Aurora Serverless v2 数据库实例的 ACU 范围。最初,集群的容量范围为 8-32 个 ACU。

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

数据库实例处于空闲状态,并缩减至 8 个 ACU。此时,以下与容量相关的设置适用于数据库实例。为了使用简单易读的单位表示缓冲池的大小,我们将它除以 2 的 30 次方,得出以 GiB 为单位的测量值。这是因为 Aurora 的内存相关测量值使用 2 的幂,而不是 10 的幂为单位。

mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 3000 | +-------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 9294577664 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +-----------+ | gibibytes | +-----------+ | 8.65625 | +-----------+ 1 row in set (0.00 sec)

接下来,我们更改集群的容量范围。在 modify-db-cluster 命令完成后,集群的 ACU 范围为 12.5-80。

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \ --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80 aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 12.5, "MaxCapacity": 80.0 }

更改容量范围会导致某些配置参数的默认值发生更改。Aurora 可以立即应用其中一些新的默认值。但是,某些参数更改只有在重新启动后才会生效。pending-reboot 状态表示需要重新启动才能应用一些参数更改。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "pending-reboot" } ] }

此时,集群处于空闲状态且数据库实例 serverless-v2-instance-1 正在使用 12.5 个 ACU。innodb_buffer_pool_size 参数将根据数据库实例的当前容量进行调整。max_connections 参数仍然反映以前的最大容量的值。重置该值需要重新启动数据库实例。

注意

如果您直接在自定义数据库参数组中设置 max_connections 参数,则无需重启。

mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 3000 | +-------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 15572402176 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +---------------+ | gibibytes | +---------------+ | 14.5029296875 | +---------------+ 1 row in set (0.00 sec)

现在,我们重新启动数据库实例,并等待实例再次变为可用。

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1 { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBInstanceStatus": "rebooting" } aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

已清除 pending-reboot 状态。in-sync 值确认 Aurora 已应用所有待处理的参数更改。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "in-sync" } ] }

对于空闲数据库实例,innodb_buffer_pool_size 参数已增大至最终大小。max_connections 参数已增大,以便反映从最大 ACU 值派生的值。当内存大小增加一倍时,Aurora 用于 max_connections 的公式会导致增加 1,000。

mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 16139681792 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +-----------+ | gibibytes | +-----------+ | 15.03125 | +-----------+ 1 row in set (0.00 sec) mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 4000 | +-------------------+ 1 row in set (0.00 sec)

我们将容量范围设置为 0.5–128 个 ACU,然后重启数据库实例。现在,空闲数据库实例的缓冲区缓存大小不到 1 GiB,因此我们以 MiB 为单位来衡量它。max_connections 值 5000 来源于最大容量设置的内存大小。

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections; +-----------+-------------------+ | mebibytes | @@max_connections | +-----------+-------------------+ | 672 | 5000 | +-----------+-------------------+ 1 row in set (0.00 sec)

示例:更改 Aurora PostgreSQL 集群的 Aurora Serverless v2 容量范围

以下 CLI 示例显示如何更新现有 Aurora PostgreSQL 集群中 Aurora Serverless v2 数据库实例的 ACU 范围。

  1. 集群的容量范围以 0.5–1 个 ACU 开始。

  2. 将容量范围更改为 8–32 个 ACU。

  3. 将容量范围更改为 12.5–80 个 ACU。

  4. 将容量范围更改为 0.5–128 个 ACU。

  5. 将容量恢复到其初始范围 0.5–1 个 ACU。

下图显示了 Amazon CloudWatch 中的容量变化。


                Aurora Serverless v2 容量变化的 CloudWatch 图

数据库实例处于空闲状态,并缩减至 0.5 个 ACU。此时,以下与容量相关的设置适用于数据库实例。

postgres=> show max_connections; max_connections ----------------- 189 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 16384 (1 row)

接下来,我们更改集群的容量范围。在 modify-db-cluster 命令完成后,集群的 ACU 范围为 8.0–32。

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

更改容量范围会导致某些配置参数的默认值发生更改。Aurora 可以立即应用其中一些新的默认值。但是,某些参数更改只有在重新启动后才会生效。pending-reboot 状态表示需要重新启动才能应用一些参数更改。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "pending-reboot" } ] }

此时,集群处于空闲状态且数据库实例 serverless-v2-instance-1 正在使用 8.0 个 ACU。shared_buffers 参数将根据数据库实例的当前容量进行调整。max_connections 参数仍然反映以前的最大容量的值。重置该值需要重新启动数据库实例。

注意

如果您直接在自定义数据库参数组中设置 max_connections 参数,则无需重启。

postgres=> show max_connections; max_connections ----------------- 189 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 1425408 (1 row)

我们重启数据库实例,并等待实例再次变为可用。

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1 { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBInstanceStatus": "rebooting" } aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

现在数据库实例已重新启动,pending-reboot 状态已清除。in-sync 值确认 Aurora 已应用所有待处理的参数更改。

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "in-sync" } ] }

重启后,max_connections 显示新的最大容量中的值。

postgres=> show max_connections; max_connections ----------------- 5000 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 1425408 (1 row)

接下来,我们将集群的容量范围更改为 12.5–80 个 ACU。

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \ --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80 aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 12.5, "MaxCapacity": 80.0 }

此时,集群处于空闲状态且数据库实例 serverless-v2-instance-1 正在使用 12.5 个 ACU。shared_buffers 参数将根据数据库实例的当前容量进行调整。max_connections 值仍为 5000。

postgres=> show max_connections; max_connections ----------------- 5000 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 2211840 (1 row)

我们再次重启,但参数值保持不变。这是因为,对于运行 Aurora PostgreSQL 的 Aurora Serverless v2 数据库集群,max_connections 的最大值为 5000。

postgres=> show max_connections; max_connections ----------------- 5000 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 2211840 (1 row)

现在,我们将容量范围设置为 0.5 - 128 个 ACU。数据库集群缩减到 10 个 ACU,然后缩减到 2 个。我们重启数据库实例。

postgres=> show max_connections; max_connections ----------------- 2000 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 16384 (1 row)

Aurora Serverless v2 数据库实例的 max_connections 值基于从最大 ACU 得出的内存大小。但是,当您在 PostgreSQL 兼容的数据库实例上指定 0.5 个 ACU 的最小容量时,max_connections 最大值的上限为 2000。

现在,我们将容量恢复到其初始范围 0.5–1 个 ACU,然后重启数据库实例。max_connections 参数已恢复为其原始值。

postgres=> show max_connections; max_connections ----------------- 189 (1 row) postgres=> show shared_buffers; shared_buffers ---------------- 16384 (1 row)

使用 Aurora Serverless v2 的参数组

当您创建您的 Aurora Serverless v2 数据库集群时,您可以选择特定 Aurora 数据库引擎和关联的数据库集群参数组。如果您不熟悉 Aurora 如何使用参数组在群集之间一致地应用配置设置,请参阅使用参数组。所有这些用于创建、修改、应用参数组和其他操作的过程都适用于 Aurora Serverless v2。

参数组特征在预置集群和包含 Aurora Serverless v2 数据库实例的集群中的工作方式通常相同:

  • 集群中所有数据库实例的默认参数值由集群参数组定义。

  • 您可以通过为特定数据库实例指定自定义数据库参数组来覆盖这些数据库实例的一些参数。您可以在特定数据库实例的调试或性能优化时执行此操作。例如,假设您有一个集群包含一些 Aurora Serverless v2 数据库实例和一些预置数据库实例。在这种情况下,您可以使用自定义数据库参数组为预置数据库实例指定一些不同的参数。

  • 对于 Aurora Serverless v2,您可以使用在参数组的 SupportedEngineModes 属性中具有 provisioned 值的所有参数。在 Aurora Serverless v1 中,您只可以使用在 SupportedEngineModes 属性中具有 serverless 值的参数的子集。

默认参数值

预置数据库实例和 Aurora Serverless v2 数据库实例之间的关键区别是,Aurora 会覆盖与数据库实例容量相关的某些参数的任何自定义参数值。自定义参数值仍适用于集群中的任何预置数据库实例。有关 Aurora Serverless v2 数据库实例如何解读 Aurora 参数组中的参数的更多信息,请参阅Aurora 集群的配置参数。对于 Aurora Serverless v2 覆盖的具体参数,请参阅 Aurora 在 Aurora Serverless v2 扩展和缩减时调整的参数Aurora 基于 Aurora Serverless v2 最大容量计算的参数

通过使用 describe-db-cluster-parameters CLI 命令并查询 Amazon Web Services 区域,您可以获得各种 Aurora 数据库引擎的默认参数组的默认值列表。以下是您可为与 Aurora Serverless v2 兼容的引擎版本的 --db-parameter-group-family-db-parameter-group-name 选项使用的值。

数据库引擎和版本 参数组系列 默认参数组名称

Aurora MySQL 版本 3

aurora-mysql8.0

default.aurora-mysql8.0

Aurora PostgreSQL 版本 13.x

aurora-postgresql13

default.aurora-postgresql13

Aurora PostgreSQL 版本 14.x

aurora-postgresql14

default.aurora-postgresql14

Aurora PostgreSQL 版本 15.x

aurora-postgresql15

default.aurora-postgresql15

以下示例从 Aurora MySQL 版本 3 和 Aurora PostgreSQL 13 的默认数据库集群组中获取参数列表。这些是您与 Aurora Serverless v2 配合使用的 Aurora MySQL 和 Aurora PostgreSQL 版本。

对于 Linux、macOS 或 Unix:

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name default.aurora-mysql8.0 \ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \ --output text aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name default.aurora-postgresql13 \ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \ --output text

对于 Windows:

aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name default.aurora-mysql8.0 ^ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^ --output text aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name default.aurora-postgresql13 ^ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^ --output text

Aurora Serverless v2 的最大连接数

对于 Aurora MySQL 和 Aurora PostgreSQL,Aurora Serverless v2 数据库实例使 max_connections 参数保持不变,所以在数据库实例缩减时不会断开连接。此参数的默认值源自基于数据库实例的内存大小的公式。有关公式和预置数据库实例类的默认值的详细信息,请参阅 至 Aurora MySQL 数据库实例的最大连接数至 Aurora PostgreSQL 数据库实例的最大连接数

当 Aurora Serverless v2 计算公式时,它使用的内存大小基于数据库实例的最大 Aurora 容量单位(ACU),而不是当前 ACU 值。如果您更改默认值,我们建议使用该公式的变体,而不是指定常数值。这样,Aurora Serverless v2 可以根据最大容量使用适当的设置。

当您更改 Aurora Serverless v2 数据库集群的最大容量时,必须重启 Aurora Serverless v2 数据库实例才能更新 max_connections 值。这是因为 max_connections 是 Aurora Serverless v2 的一个静态参数。

下表显示了适用于 Aurora Serverless v2 的 max_connections 基于最大 ACU 值的默认值。

最大 ACU 数 Aurora MySQL 上的默认最大连接数 Aurora PostgreSQL 上的默认最大连接数
1 90 189
4 135 823
8 1000 1669
16 2000 3360
32 3000 5000
64 4,000 5000
128 5000 5000
注意

Aurora Serverless v2 数据库实例的 max_connections 值基于从最大 ACU 得出的内存大小。但是,当您在 PostgreSQL 兼容的数据库实例上指定 0.5 个 ACU 的最小容量时,max_connections 最大值的上限为 2000。

有关显示 max_connections 如何随最大 ACU 值而变化的具体示例,请参阅 示例:更改 Aurora MySQL 集群的 Aurora Serverless v2 容量范围示例:更改 Aurora PostgreSQL 集群的 Aurora Serverless v2 容量范围

Aurora 在 Aurora Serverless v2 扩展和缩减时调整的参数

在弹性伸缩期间,Aurora Serverless v2 需要能够更改每个数据库实例的参数,以便在容量增加或减少时发挥最佳作用。因此,您无法覆盖与容量相关的某些参数。对于一些可以覆盖的参数,请避免直接写入固定值。以下注意事项适用于与容量相关的这些设置。

对于 Aurora MySQL,Aurora Serverless v2 在扩缩期间动态调整部分参数的大小。对于以下参数,Aurora Serverless v2 不使用您指定的任何自定义参数值:

  • innodb_buffer_pool_size

  • innodb_purge_threads

  • table_definition_cache

  • table_open_cache

对于 Aurora PostgreSQL,Aurora Serverless v2 在扩缩期间动态调整以下参数的大小。对于以下参数,Aurora Serverless v2 不使用您指定的任何自定义参数值:

  • shared_buffers

对于除此处列出的参数以外的所有参数,Aurora Serverless v2 数据库实例与预调配数据库实例的工作方式相同。从集群参数组继承默认参数值。您可以使用自定义集群参数组修改整个集群的默认值。或者,您可以使用自定义数据库参数组修改某些数据库实例的默认值。动态参数会立即更新。对静态参数的更改仅在重新启动数据库实例后才会生效。

Aurora 基于 Aurora Serverless v2 最大容量计算的参数

对于以下参数,Aurora PostgreSQL 使用基于最大 ACU 设置的内存大小得出的默认值,与 max_connections 相同:

  • autovacuum_max_workers

  • autovacuum_vacuum_cost_limit

  • autovacuum_work_mem

  • effective_cache_size

  • maintenance_work_mem

避免内存不足错误

如果您的其中一个 Aurora Serverless v2 数据库实例持续达到最大容量的限制,Aurora 会通过将数据库实例设置为 incompatible-parameters 状态来表明这种状况。数据库实例处于 incompatible-parameters 状态时,某些操作会被阻止。例如,您无法升级引擎版本。

通常,当由于内存不足错误而频繁重新启动时,数据库实例会进入此状态。发生这种类型的重启时,Aurora 会记录一个事件。您可以按照 查看 Amazon RDS 事件 中的步骤查看事件。由于开启 Performance Insights 和 IAM 身份验证等设置会产生开销,所以通常会出现高内存使用率。数据库实例上存在繁重的工作负载,或者要管理与大量架构对象相关联的元数据时,也会导致出现高内存使用率。

如果内存压力变得更低,以致数据库实例不会经常达到最大容量,Aurora 会自动将数据库实例状态更改回 available

要从这种情况中恢复,您可以采取以下部分或全部操作:

  • 通过更改集群的最小 Aurora 容量单位(ACU)值,提高 Aurora Serverless v2 数据库实例的容量下限。这样做可以避免空闲数据库缩减到某个容量,以至于内存太少,无法满足集群中启用的特征所需的内存。更改集群的 ACU 设置后,重新启动 Aurora Serverless v2 数据库实例。这样做可计算出 Aurora 是否可以将状态重置回 available

  • 通过更改集群的最大 ACU 值,提高 Aurora Serverless v2 数据库实例的容量上限。这样做可避免繁忙的数据库无法扩展到某个容量,以至于没有足够的内存来满足集群中启用的特征和数据库工作负载所需的内存。更改集群的 ACU 设置后,重新启动 Aurora Serverless v2 数据库实例。这样做可计算出 Aurora 是否可以将状态重置回 available

  • 关闭需要内存开销的配置设置。例如,假设您已启用 Amazon Identity and Access Management(IAM)、Performance Insights 或 Aurora MySQL 二进制日志复制等特征,但未使用它们。如果是这样,您可以关闭这些功能。或者,您可以将集群的最小和最大容量值调高,以便考虑到这些特征使用的内存。有关选择最小和最大容量设置的指引,请参阅选择 Aurora 集群的 Aurora Serverless v2 容量范围

  • 减少数据库实例上的工作负载。例如,您可以将读取器数据库实例添加到集群中,以便将只读查询的负载分散到更多数据库实例中。

  • 调优应用程序使用的 SQL 代码,以使用更少的资源。例如,您可以检查查询计划、检查慢速查询日志或调整表的索引。您还可以执行其他传统类型的 SQL 优化。

适用于 Aurora Serverless v2 的重要 Amazon CloudWatch 指标

要开始为您的 Aurora Serverless v2 数据库实例使用 Amazon CloudWatch,请参阅在 Amazon CloudWatch 中查看 Aurora Serverless v2 日志。要详细了解如何通过 CloudWatch 监控 Aurora 数据库集群 ,请参阅在 Amazon CloudWatch 中监控日志事件

您可以在 CloudWatch 中查看 Aurora Serverless v2 数据库实例,以便使用 ServerlessDatabaseCapacity 指标监控每个数据库实例使用的容量。您还可以监控所有标准 Aurora CloudWatch 指标,例如 DatabaseConnectionsQueries。有关可为 Aurora 监控的 CloudWatch 指标的完整列表,请参阅Amazon Aurora 的 Amazon CloudWatch 指标。这些指标分为集群级和实例级指标,请分别参阅Amazon Aurora 的集群级指标Amazon Aurora 的实例级指标

为了了解 Aurora Serverless v2 数据库实例如何扩展和缩减,重要的是监控以下 CloudWatch 实例级指标。所有这些指标每秒计算一次。这样,您就可以监控 Aurora Serverless v2 数据库实例的当前状态。您可以设置警报,以便在任何 Aurora Serverless v2 数据库实例接近与容量相关的指标阈值时通知您。您可以确定最小和最大容量设置是否合适,或者是否需要调整它们。您可以确定将精力集中在哪方面来优化数据库的效率。

  • ServerlessDatabaseCapacity。作为实例级指标,它会报告当前数据库实例容量所代表的 ACU 数量。作为集群级指标,它代表集群中所有 Aurora Serverless v2 数据库实例的 ServerlessDatabaseCapacity 值的平均值。在 Aurora Serverless v1 中,此指标只是一个集群级指标。在 Aurora Serverless v2 中,它可以在数据库实例级和集群级使用。

  • ACUUtilization。此指标是 Aurora Serverless v2 中的新指标。此值以百分比表示。它的计算方法是 ServerlessDatabaseCapacity 指标的值除以数据库集群的最大 ACU 值。解读此指标并采取行动时考虑以下准则:

    • 如果此指标接近值 100.0,则数据库实例已扩展到它能达到的最大容量。考虑增大集群的最大 ACU 设置。这样,写入器和读取器数据库实例都可以扩展到更高的容量。

    • 假设只读工作负载导致读取器数据库实例的 100.0 属性接近 ACUUtilization,而写入器数据库实例未接近其最大容量。在这种情况下,请考虑向集群添加额外的读取器数据库实例。这样,您可以将工作负载的只读部分分散到更多数据库实例上,从而减少每个读取器数据库实例的负载。

    • 假设您正在运行生产应用程序,其中性能和可扩展性是主要考虑因素。在这种情况下,您可以将集群的最大 ACU 值设置为较高的数字。您的目标是让 ACUUtilization 指标始终低于 100.0。使用较高的最大 ACU 值,您可以确信有足够的空间来应对数据库活动中出现的意外高峰。您只需为实际使用的数据库容量付费。

  • CPUUtilization。这个指标在 Aurora Serverless v2 中的解读不同于预置数据库实例中的解读。对于 Aurora Serverless v2,此值是一个百分比,其计算方法是当前使用的 CPU 量除以在数据库集群的最大 ACU 值基础上提供的 CPU 容量。当数据库实例持续使用其 CPU 容量的很大一部分时,Aurora 会自动监控此值并扩展 Aurora Serverless v2 数据库实例。

    如果此指标接近值 100.0,则该数据库实例已达到其最大 CPU 容量。考虑增大集群的最大 ACU 设置。如果读取器数据库实例上的这个指标接近值 100.0,请考虑向集群添加额外的读取器数据库实例。这样,您可以将工作负载的只读部分分散到更多数据库实例上,从而减少每个读取器数据库实例的负载。

  • FreeableMemory。此值表示当 Aurora Serverless v2 数据库实例已扩展到其最大容量时,提供的未使用内存量。对于当前容量低于最大容量的每个 ACU,此值增加大约 2 GiB。因此,在数据库实例扩展到它可以达到的最大值之前,此指标不会接近零。

    如果此指标接近值 0,则数据库实例已扩展到它可以达到的最大值,并且已接近其可用内存的限制。考虑增大集群的最大 ACU 设置。如果读取器数据库实例上的这个指标接近值 0,请考虑向集群添加额外的读取器数据库实例。这样,工作负载的只读部分可以分散到更多数据库实例上,从而减少每个读取器数据库实例的内存使用。

  • TempStorageIops。在连接到数据库实例的本地存储上完成的 IOPS 数。它包括读取和写入的 IOPS。此指标表示计数,每秒测量一次。这是一个 Aurora Serverless v2 的新指标。有关详细信息,请参阅 Amazon Aurora 的实例级指标

  • TempStorageThroughput。传入或传出与数据库实例关联的本地存储的数据量。此指标表示字节数,每秒测量一次。这是一个 Aurora Serverless v2 的新指标。有关详细信息,请参阅 Amazon Aurora 的实例级指标

通常情况下,Aurora Serverless v2 数据库实例的大多数扩展是因内存使用和 CPU 活动而引起。TempStorageIopsTempStorageThroughput 指标可以帮助您诊断数据库实例和本地存储设备之间传输的网络活动导致意外容量增加的罕见情况。要监控其他网络活动,您可以使用以下现有指标:

  • NetworkReceiveThroughput

  • NetworkThroughput

  • NetworkTransmitThroughput

  • StorageNetworkReceiveThroughput

  • StorageNetworkThroughput

  • StorageNetworkTransmitThroughput

您可使用 Aurora 将某些或所有数据库日志发布到 CloudWatch。通过启用与包含 Aurora Serverless v2 数据库实例的集群关联的数据库集群参数组中的 general_log 和 slow_query_log 等配置参数,选择要发布的日志。在禁用日志配置参数时,将停止向 CloudWatch 发布该日志。如果不再需要使用日志,您也可以在 CloudWatch 中删除这些日志。

Aurora Serverless v2 指标如何适用于 Amazon 账单

Amazon 账单上的 Aurora Serverless v2 费用基于您可以监控的相同 ServerlessDatabaseCapacity 指标进行计算。如果使用 Aurora Serverless v2 容量不到一个小时,计费机制可能与此指标的已计算 CloudWatch 平均值不同。如果系统问题导致 CloudWatch 指标在短时间内不可用,计费机制也可能会有所不同。因此,如果您自己根据 ServerlessDatabaseCapacity 平均值进行计算,可能会在账单上看到 ACU 小时值略有不同。

Aurora Serverless v2 指标的 CloudWatch 命令示例

以下 Amazon CLI 示例演示了如何监控与 Aurora Serverless v2 相关的最重要 CloudWatch 指标。在每种情况下,请使用您自己的 Aurora Serverless v2 数据库实例替换 --dimensions 参数的 Value= 字符串。

以下 Linux 示例显示了数据库实例的最小容量、最大容量和平均容量值,在一小时内每 10 分钟测量一次。Linux date 命令指定相对于当前日期和时间的开始时间和结束时间。--query 参数中的 sort_by 函数根据 Timestamp 字段按时间顺序对结果进行排序。

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

以下 Linux 示例显示了监控集群中每个数据库实例的容量。它们衡量每个数据库实例的最小容量、最大容量和平均容量利用率。在三个小时内,每小时进行一次测量。这些示例使用 ACUUtilization 指标表示 ACU 上限的百分比,而不是使用 ServerlessDatabaseCapacity 表示固定数量的 ACU。这样,您就不需要知道容量范围内的最小和最大 ACU 值的实际数字。您可以看到 0 到 100 之间的百分比。

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \ --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \ --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

下面的 Linux 示例执行的测量与之前的示例类似。在本例中,测量值针对 CPUUtilization 指标。在 1 小时内,每 10 分钟进行一次测量。这些数字表示已使用的可用 CPU的百分比,基于数据库实例的最大容量设置中可用的 CPU 资源。

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

下面的 Linux 示例执行的测量与之前的示例类似。在本例中,测量值针对 FreeableMemory 指标。在 1 小时内,每 10 分钟进行一次测量。

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

使用 Performance Insights 监控 Aurora Serverless v2 性能

您可以使用 Performance Insights 来监控 Aurora Serverless v2 数据库实例的性能。有关 Performance Insights 的程序,请参阅在 Amazon Aurora 上使用性能详情监控数据库负载

以下新 Performance Insights 计数器适用于 Aurora Serverless v2 数据库实例:

  • os.general.serverlessDatabaseCapacity – 数据库实例以 ACU 表示的当前容量。该值对应于数据库实例的 ServerlessDatabaseCapacity CloudWatch 指标。

  • os.general.acuUtilization – 当前容量占最大配置容量的百分比。该值对应于数据库实例的 ACUUtilization CloudWatch 指标。

  • os.general.maxConfiguredAcu – 您为此 Aurora Serverless v2 数据库实例配置的最大容量。它用 ACU 来测量。

  • os.general.minConfiguredAcu – 您为此 Aurora Serverless v2 数据库实例配置的最小容量。它用 ACU 来测量。

有关 Performance Insights 计数器的完整列表,请参阅 Performance Insights 计数器指标

在 Performance Insights 中为 Aurora Serverless v2 数据库实例显示 vCPU 值时,这些值表示基于数据库实例的 ACU 值的估计值。默认时间间隔为 1 分钟,任何小数 vCPU 值将向上舍入到最接近的整数。对于更长的时间间隔,显示的 vCPU 值是每分钟的整数 vCPU 值的平均值。

Aurora Serverless v2 容量问题疑难解答

在某些情况下,即使数据库上没有负载,Aurora Serverless v2 也不会缩减至最小容量。这可能是由于以下原因之一:

  • 某些特征可以增加资源使用量并防止数据库缩减到最低容量。这些特征如下所示:

    • Aurora 全局数据库

    • 导出 CloudWatch Logs

    • 在与 Aurora PostgreSQL 兼容的数据库集群上启用 pg_audit

    • 增强监控

    • Performance Insights

    有关更多信息,请参阅选择集群的最小 Aurora Serverless v2 容量设置

  • 如果读取器实例未缩减到最小值,并保持在与写入器实例相同或更高的容量,请检查读取器实例的优先级层。层为 0 或 1 的 Aurora Serverless v2 读取器数据库实例保持在至少与写入器数据库实例一样高的最小容量。将读取器的优先级层更改为 2 或更高,这样它就可以独立于写入器而纵向扩展和缩减。有关更多信息,请参阅为 Aurora Serverless v2 读取器选择提升层

  • 将影响共享内存大小的任何数据库参数设置为其默认值。将值设置为高于默认值会增加共享内存需求,并防止数据库缩减到最小容量。示例包括 max_connectionsmax_locks_per_transaction

    注意

    更新共享内存参数需要重新启动数据库才能使更改生效。

  • 繁重的数据库工作负载可能会增加资源使用量。

  • 较大的数据库卷可能会增加资源使用量。

    Amazon Aurora 使用内存和 CPU 资源进行数据库集群管理。Aurora 需要更多的 CPU 和内存来管理具有更大数据库卷的数据库集群。如果您的集群的最小容量低于集群管理所需的最小容量,则您的集群不会缩减到最小容量。

  • 后台进程(如清除)也可能增加资源使用量。

如果数据库仍无法缩减到配置的最小容量,则停止并重新启动数据库,以回收可能随着时间推移而累积的所有内存碎片。停止和启动数据库会导致停机,因此我们建议谨慎执行此操作。