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

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

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

存储扩展

Aurora 存储自动使用您的集群卷中的数据进行扩展。随着数据的增长,您的集群卷存储最大可扩展到 128 tebibytes (TiB)。要了解集群卷中包含哪些类型的数据,请参阅Amazon Aurora 存储和可靠性

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

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

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

    • Aurora MySQL 2.09(与 MySQL 5.7 兼容)

    • Aurora MySQL 1.23(与 MySQL 5.6 兼容)

    • Aurora PostgreSQL 3.3.0(与 PostgreSQL 11.8 兼容)

    • Aurora PostgreSQL 2.6.0(与 PostgreSQL 10.13 兼容)

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

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

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

注意

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

与较低版本相比,这些 Aurora 版本对集群卷的存储限制也较高。因此,如果您即将超过原始的 64 TiB 卷大小,则可以考虑升级到这些版本之一。

您可以通过监控 CloudWatch 中的 VolumeBytesUsed 指标来检查集群使用的存储空间量。

  • 在 AWS 管理控制台 中,您可以通过查看集群详细信息页面上的 Monitoring 选项卡,在图表中查看此数字。

  • 使用 AWS 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 系统上使用 AWS 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 命令。sort 命令的 -k 参数按第三个字段(通用协调时间 (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 的幂测量的单位,通常用于讨论旋转硬盘驱动器的存储。GiB 表示以 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。您可以看到,此集群的可用大小反映了原始的 64 TiB 限制,因为此集群正在运行 Aurora MySQL 1.22 版本。

$ 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 69797193744384.0 2020-08-05T17:52:00+00:00 Count DATAPOINTS 69797193744384.0 2020-08-05T18:52: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 版本 1.23 或 2.09 及更高版本或 Aurora PostgreSQL 3.3.0 或 2.6.0 及更高版本的集群,添加数据时 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 版本 1.23 或 2.09 及更高版本或 Aurora PostgreSQL 3.3.0 或 2.6.0 及更高版本的集群,AuroraVolumeBytesLeftTotal 报告的可用大小如何反映较高的 128 TiB 大小限制。

$ 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 优化的数据库实例类,具体取决于数据库引擎兼容性。

数据库引擎 实例扩展

Amazon Aurora MySQL

请参阅 扩展 Aurora MySQL 数据库实例

Amazon Aurora PostgreSQL

请参阅 扩展 Aurora PostgreSQL 数据库实例

读取扩展

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

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

管理连接

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

数据库引擎 max_connections 默认值

Amazon Aurora MySQL

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

Amazon Aurora PostgreSQL

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

管理查询执行计划

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