管理 Aurora 数据库集群的性能和扩展 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

管理 Aurora 数据库集群的性能和扩展

您可以使用以下选项管理 Aurora 数据库集群和数据库实例的性能和扩展:

存储扩展

Aurora 存储自动使用您的集群卷中的数据进行扩展。随着数据的增长,您的集群卷存储最大可扩展到 128 TiB 或 64 TiB。最大大小取决于数据库引擎版本。要了解集群卷中包含哪些类型的数据,请参阅Amazon Aurora 存储和可靠性。有关特定版本最大大小的详细信息,请参阅 Amazon Aurora 大小限制

每小时评估一次集群卷的大小以确定存储成本。有关定价的信息,请参阅 Aurora 定价页面

尽管 Aurora 集群卷的大小可以扩展到许多 TB,但您只需为卷中使用的空间付费。确定计费存储空间的机制取决于 Aurora 集群的版本。

  • 从集群卷中删除 Aurora 数据时,总计费空间会减少相当数量。当删除或重组基础表空间以占用更少的空间时,就会发生这种动态调整大小的行为。因此,您可以通过删除不再需要的表和数据库来减少存储费用。动态调整大小适用于某些 Aurora 版本。以下是在删除数据后集群卷会动态调整大小的 Aurora 版本:

    Aurora MySQL
    • 版本 3(与 MySQL 8.0 兼容):所有支持的版本

    • 版本 2(与 MySQL 5.7 兼容):2.11 及更高版本

    Aurora PostgreSQL 支持的所有版本
    Aurora Serverless v2 支持的所有版本
    Aurora Serverless v1 支持的所有版本
  • 在低于前面所列版本的 Aurora 版本中,集群卷可以重用在删除数据时释放的空间,但卷本身的大小从不会减小。

  • 此功能正在分阶段部署到支持 Aurora 的Amazon区域。根据集群所在的区域,此功能可能尚不可用。

动态调整大小适用于以物理方式删除集群卷中的表空间或调整其大小的操作。因此,它适用于 DROP TABLEDROP DATABASETRUNCATE TABLEALTER TABLE ... DROP PARTITION 之类的 SQL 语句。它不适用于使用 DELETE 语句删除行。如果从表中删除了大量的行,则可以在之后运行 Aurora MySQL OPTIMIZE TABLE 语句或使用 Aurora PostgreSQL pg_repack 扩展以重组表并动态调整集群卷的大小。

注意

对于 Aurora MySQL,innodb_file_per_table 参数影响表存储的组织方式。当表是系统表空间的一部分时,删除表不会减小系统表空间的大小。因此,请确保对于 Aurora MySQL 数据库集群将 innodb_file_per_table 设置为 1,以充分利用动态调整大小功能。

对于 Aurora MySQL 版本 2.11 及更高版本,InnoDB 临时表空间将被删除并在重启时重新创建。这会将临时表空间占用的空间释放给系统,然后调整集群卷的大小。为了充分利用动态调整大小功能,我们建议您将数据库集群升级到 Aurora MySQL 2.11 或更高版本。

当删除表空间中的表时,动态调整大小功能不会立即回收空间,而是以每天大约 10TB 的速度逐渐回收空间。不会回收系统表空间中的空间,因为从不会删除系统表空间。当某项操作需要某个表空间中的空间时,该表空间中未回收的空闲空间将被重用。只有当集群处于可用状态时,动态调整大小功能才能回收存储空间。

您可以通过监控 CloudWatch 中的 VolumeBytesUsed 指标来检查集群使用的存储空间量。有关存储账单的更多信息,请参阅Aurora 数据存储的计费方式

  • 在 Amazon Web Services Management Console 中,您可以通过查看集群详细信息页面上的 Monitoring 选项卡,在图表中查看此数字。

  • 使用 Amazon CLI,您可以运行类似于以下 Linux 示例的命令。用您自己的值替换开始和结束时间以及集群的名称。

    aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" \ --statistics Average Maximum Minimum \ --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier

    该命令产生的输出类似于以下内容。

    { "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T21:25:00+00:00", "Average": 182871982080.0, "Minimum": 182871982080.0, "Maximum": 182871982080.0, "Unit": "Bytes" } ] }

以下示例显示了如何在 Linux 系统上使用 Amazon CLI 命令,跟踪一段时间内的 Aurora 集群存储使用量。--start-time--end-time 参数将整个时间间隔定义为一天。--period 参数每隔一小时请求一次测量。选择一个小的 --period 值没有意义,因为这些指标是按间隔收集的,而不是连续收集的。此外,在相关 SQL 语句完成后,Aurora 存储操作有时会在后台继续一段时间。

第一个示例以默认 JSON 格式返回输出。数据点以任意顺序返回,而不是按时间戳排序。您可以将此 JSON 数据导入到图表工具中以进行排序和可视化。

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id { "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T19:40:00+00:00", "Maximum": 182872522752.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-05T00:40:00+00:00", "Maximum": 198573719552.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-05T05:40:00+00:00", "Maximum": 206827454464.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-04T17:40:00+00:00", "Maximum": 182872522752.0, "Unit": "Bytes" }, ... output omitted ...

此示例返回与前一个示例相同的数据。--output 参数以紧凑的纯文本格式表示数据。aws cloudwatch 命令通过管道将其输出传递给 sort 命令。-k 命令的 sort 参数按第三个字段(通用协调时间 (UTC) 格式的时间戳)对输出进行排序。

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \ --output text | sort -k 3 VolumeBytesUsed DATAPOINTS 182872522752.0 2020-08-04T17:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T18:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T19:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T20:41:00+00:00 Bytes DATAPOINTS 187667791872.0 2020-08-04T21:41:00+00:00 Bytes DATAPOINTS 190981029888.0 2020-08-04T22:41:00+00:00 Bytes DATAPOINTS 195587244032.0 2020-08-04T23:41:00+00:00 Bytes DATAPOINTS 201048915968.0 2020-08-05T00:41:00+00:00 Bytes DATAPOINTS 205368492032.0 2020-08-05T01:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T02:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T03:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T04:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T05:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T06:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T07:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T08:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T09:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T10:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T11:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T12:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T13:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T14:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T15:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T16:41:00+00:00 Bytes

排序后的输出显示在监控周期开始和结束时使用的存储空间量。您还可以找到在此期间 Aurora 为集群分配更多存储空间的时间点。以下示例使用 Linux 命令将 VolumeBytesUsed 开始值和结束值重新格式化为 GB 和 GiB。GB 表示以 10 的幂测量的单位,通常用于讨论旋转硬盘驱动器的存储。千兆字节表示以 2 的幂进行测量的单位。Aurora 存储空间的测量和限制通常以 2 的幂为单位表示,如 GiB 和 TiB。

$ GiB=$((1024*1024*1024)) $ GB=$((1000*1000*1000)) $ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB" Start: 170 GiB, End: 192 GiB $ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB" Start: 182 GB, End: 206 GB

VolumeBytesUsed 指标告诉您集群中有多少存储空间产生费用。因此,最好在可行的情况下最小化此数字。但是,此指标不包括一些 Aurora 在集群内部使用且不收费的存储空间。如果您的集群接近存储限制并且可能会用完空间,则监控 AuroraVolumeBytesLeftTotal 指标并尝试最大化此数字会更有帮助。以下示例运行与前一个示例类似的计算,但针对 AuroraVolumeBytesLeftTotal 而不是针对 VolumeBytesUsed

$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \ --output text | sort -k 3 AuroraVolumeBytesLeftTotal DATAPOINTS 140530528288768.0 2023-02-23T19:25:00+00:00 Count $ TiB=$((1024*1024*1024*1024)) $ TB=$((1000*1000*1000*1000)) $ echo "$((69797067915264 / $TB)) TB remaining for this cluster" 69 TB remaining for this cluster $ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster" 63 TiB remaining for this cluster

对于运行 Aurora MySQL 版本 2.09 或更高版本或 Aurora PostgreSQL 的集群,添加数据时 VolumeBytesUsed 报告的可用大小会增大,删除数据时会减小。下面的示例演示如何操作。在创建和删除包含临时数据的表时,此报告每隔 15 分钟显示一次集群的最大和最小存储大小。此报告在最小值之前列出最大值。因此,要了解在 15 分钟间隔内存储使用量如何变化,请从右向左解释这些数字。

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id --output text | sort -k 4 VolumeBytesUsed DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T20:49:00+00:00 Bytes DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T21:19:00+00:00 Bytes DATAPOINTS 22022176768.0 14545305600.0 2020-08-05T21:49:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:19:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:49:00+00:00 Bytes DATAPOINTS 22022176768.0 15614263296.0 2020-08-05T23:19:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-05T23:49:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-06T00:19:00+00:00 Bytes

以下示例显示了对于运行 Aurora MySQL 版本 2.09 或更高版本或 Aurora PostgreSQL 的集群,AuroraVolumeBytesLeftTotal 报告的可用大小如何反映较高的 128TiB 大小限制。

$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \ --output text | sort -k 3 AuroraVolumeBytesLeftTotal DATAPOINTS 140515818864640.0 2020-08-05T20:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:26:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:56:00+00:00 Count DATAPOINTS 140514866757632.0 2020-08-05T22:26:00+00:00 Count DATAPOINTS 140511020580864.0 2020-08-05T22:56:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:26:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-06T00:26:00+00:00 Count $ TiB=$((1024*1024*1024*1024)) $ TB=$((1000*1000*1000*1000)) $ echo "$((140515818864640 / $TB)) TB remaining for this cluster" 140 TB remaining for this cluster $ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster" 127 TiB remaining for this cluster

实例扩展

可通过修改数据库集群中每个数据库实例的数据库实例类来按需扩展 Aurora 数据库集群。Aurora 支持多个针对 Aurora 进行优化的数据库实例类,具体情况取决于数据库引擎的兼容性。

读取扩展

可通过在 Aurora 数据库集群中创建最多 15 个 Aurora 副本,以实现针对该数据库集群的读取扩缩。每个 Aurora 副本均返回集群卷中的相同数据,且副本滞后时间最短 — 通常大大少于主实例写入更新后的 100 毫秒。当读取流量增大时,可创建额外 Aurora 副本并直接连接到这些副本以为您的数据库集群分配读取负载。Aurora 副本不必具有与主实例相同的数据库实例类。

有关将 Aurora 副本添加到数据库集群的信息,请参阅将 Aurora 副本添加到数据库集群

管理连接

允许连接到 Aurora 数据库实例的最大数量由数据库实例的实例级参数组中的 max_connections 参数确定。参数的默认值因用于数据库实例的数据库实例类和数据库引擎兼容性而异。

数据库引擎 max_connections 默认值

Amazon Aurora MySQL

请参阅 至 Aurora MySQL 数据库实例的最大连接数

Amazon Aurora PostgreSQL

请参阅 至 Aurora PostgreSQL 数据库实例的最大连接数

提示

如果您的应用程序经常打开和关闭连接,或使大量长期连接保持打开,我们建议您使用 Amazon RDS 代理。RDS 代理是一种完全托管的高可用性数据库代理,它使用连接池安全有效地共享数据库连接。要了解有关 RDS 代理的更多信息,请参阅将 Amazon RDS 代理用于 Aurora

管理查询执行计划

如果使用 Aurora PostgreSQL 的查询计划管理,则可以控制优化程序运行的计划。有关更多信息,请参阅“管理 Aurora PostgreSQL 的查询执行计划”。