

# 管理 Aurora 数据库集群的性能和扩展
<a name="Aurora.Managing.Performance"></a>

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

**Topics**
+ [存储扩展](#Aurora.Managing.Performance.StorageScaling)
+ [实例扩展](#Aurora.Managing.Performance.InstanceScaling)
+ [读取扩展](#Aurora.Managing.Performance.ReadScaling)
+ [管理连接](#Aurora.Managing.MaxConnections)
+ [管理查询执行计划](#Aurora.Managing.Optimizing)

## 存储扩展
<a name="Aurora.Managing.Performance.StorageScaling"></a>

Aurora 存储自动使用您的集群卷中的数据进行扩展。随着数据量增长，集群卷存储会进行扩展，具体取决于数据库引擎版本。有关每个引擎版本的最大 Aurora 集群卷大小的信息，请参阅 [Amazon Aurora 大小限制](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)。要了解集群卷中包含哪些类型的数据，请参阅[Amazon Aurora 存储](Aurora.Overview.StorageReliability.md)。有关特定版本最大大小的详细信息，请参阅 [Amazon Aurora 大小限制](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)。

每小时评估一次集群卷的大小以确定存储成本。有关定价的信息，请参阅 [Aurora 定价页面](https://aws.amazon.com/rds/aurora/pricing)。

尽管 Aurora 集群卷的大小可以扩展到许多 TB，但您只需为卷中使用的空间付费。确定计费存储空间的机制取决于 Aurora 集群的版本。
+ 从集群卷中删除 Aurora 数据时，总计费空间会减少相当数量。当删除或重组基础表空间以占用更少的空间时，就会发生这种动态调整大小的行为。因此，您可以通过删除不再需要的表和数据库来减少存储费用。动态调整大小适用于某些 Aurora 版本。以下是在删除数据后集群卷会动态调整大小的 Aurora 版本：    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ 在低于前面所列版本的 Aurora 版本中，集群卷可以重用在删除数据时释放的空间，但卷本身的大小从不会减小。

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

对于 Aurora MySQL，应注意以下事项：
+ 将数据库集群升级到支持动态调整大小的数据库引擎版本，并在该特定 AWS 区域中启用此功能后，一些 SQL 语句（例如 `DROP TABLE`）在以后释放的任何空间均可回收。

  如果在特定 AWS 区域中明确禁用了此功能，则该空间可能只能重复使用但不可回收，即使在支持动态调整大小的版本上也是如此。

  此功能在 2020 年 11 月至 2022 年 3 月期间针对特定的数据库引擎版本（1.23.0-1.23.4、2.09.0-2.09.3 和 2.10.0）启用，并在任何后续版本中默认启用。
+ 表在内部存储在一个或多个大小可变的连续片段中。运行 `TRUNCATE TABLE` 操作时，与第一个片段对应的空间可重复使用且不可回收。其他片段是可以回收的。在 `DROP TABLE` 操作期间，可以回收与整个表空间相对应的空间。
+ `innodb_file_per_table` 参数影响表存储的组织方式。当表是系统表空间的一部分时，删除表不会减小系统表空间的大小。因此，请确保对于 Aurora MySQL 数据库集群将 `innodb_file_per_table` 设置为 1，以充分利用动态调整大小功能。
+ 在版本 2.11 及更高版本中，InnoDB 临时表空间将被删除并在重启时重新创建。这会将临时表空间占用的空间释放给系统，然后调整集群卷的大小。为了充分利用动态调整大小功能，我们建议您将数据库集群升级到版本 2.11 或更高版本。

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

您可以通过监控 CloudWatch 中的 `VolumeBytesUsed` 指标来检查集群使用的存储空间量。有关存储账单的更多信息，请参阅[Aurora 数据存储的计费方式](Aurora.Overview.StorageReliability.md#aurora-storage-data-billing)。
+ 在 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` 命令。`-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 或 Aurora PostgreSQL 兼容版本的集群，`AuroraVolumeBytesLeftTotal` 报告的可用大小如何反映 256 TiB 大小限制。有关兼容版本的更多信息，请参阅 [Amazon Aurora 大小限制](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)。

```
$ 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"
256 TiB remaining for this cluster
```

## 实例扩展
<a name="Aurora.Managing.Performance.InstanceScaling"></a>

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


| 数据库引擎 | 实例扩展 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  请参阅 [扩展 Aurora MySQL 数据库实例](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.Performance.InstanceScaling)  | 
|  Amazon Aurora PostgreSQL  |  请参阅 [扩展 Aurora PostgreSQL 数据库实例](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.Performance.InstanceScaling)  | 

## 读取扩展
<a name="Aurora.Managing.Performance.ReadScaling"></a>

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

有关将 Aurora 副本添加到数据库集群的信息，请参阅[将 Aurora 副本添加到数据库集群](aurora-replicas-adding.md)。

## 管理连接
<a name="Aurora.Managing.MaxConnections"></a>

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


| 数据库引擎 | max\_connections 默认值 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  请参阅 [至 Aurora MySQL 数据库实例的最大连接数](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections)  | 
|  Amazon Aurora PostgreSQL  |  请参阅 [至 Aurora PostgreSQL 数据库实例的最大连接数](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections)  | 

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

## 管理查询执行计划
<a name="Aurora.Managing.Optimizing"></a>

如果使用 Aurora PostgreSQL 的查询计划管理，则可以控制优化程序运行的计划。有关更多信息，请参阅“[管理 Aurora PostgreSQL 的查询执行计划](AuroraPostgreSQL.Optimize.md)”。