

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 管理 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 叢集磁碟區的大小可以擴展至數個 TiB，您只需支付磁碟區中所使用空間的費用。判斷計費儲存空間的機制取決於 Aurora 叢集的版本。
+ 從叢集磁碟區移除 Aurora 資料時，整體計費空間將會大幅減少。當捨棄或重整基礎資料表空間以使用較少的空間時，就會發生此動態調整大小的行為。因此，您可以捨棄不再需要的資料表和資料庫，以減少儲存費用。動態調整大小適用於特定 Aurora 版本。下列是當您移除資料時，叢集磁碟區動態調整大小的 Aurora 版本：    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ 在低於上述清單中的 Aurora 版本中，叢集磁碟區可以重複使用移除資料時釋放的空間，但磁碟區本身的大小永遠不會減少。

動態調整大小適用於實際移除叢集磁碟區內資料表空間或調整大小的操作。因此，它適用於 SQL 陳述式，例如 `DROP TABLE`、`DROP DATABASE`、`TRUNCATE TABLE` 和 `ALTER TABLE ... DROP PARTITION`。它不適用於使用 `DELETE` 陳述式刪除資料列。如果您從資料表中刪除大量的資料列，之後您可以執行 Aurora MySQL `OPTIMIZE TABLE` 陳述式或使用 Aurora PostgreSQL `pg_repack` 擴充功能來重組資料表，並動態調整叢集磁碟區的大小。

對於 Aurora MySQL，適用下列考量：
+ 將資料庫叢集升級至支援動態調整大小的資料庫引擎版本後，當該功能在該特定中啟用時 AWS 區域，可`DROP TABLE`回收稍後由特定 SQL 陳述式釋放的任何空間，例如 。

  如果功能在特定 中明確停用 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 版或更新版本。

**注意**  
動態調整大小功能不會在資料表空間中的資料表捨棄時立即回收空間，而是以每天大約 10 TB 的速率逐漸回收空間。系統資料表空間中的空間不會回收，因為永遠不會移除系統資料表空間。當操作需要資料表空間中的空間時，就會重複使用該資料表空間中未回收的可用空間。只有當叢集處於可用狀態時，動態調整大小功能才能回收儲存空間。

您可以透過監控 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` 值是沒有意義的，因為指標是以間隔時間收集，而非持續收集。此外，Aurora 儲存操作有時會在相關的 SQL 陳述式完成後，繼續在後台運作一段時間。

第一個範例以預設 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` 值重新格式化為 Gigabyte (GB) 和 Gibibyte (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`。

```
$ 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>

您可以在資料庫叢集中建立最多 15 個 Aurora 複本，以達成 Aurora 資料庫叢集的讀取擴展。在主要執行個體寫入更新之後，每個 Aurora 複本會以最短的複本延遲從叢集磁碟區傳回相同的資料，通常遠低於 100 毫秒。當讀取流量增加時，您可以建立更多 Aurora 複本，並直接連線這些複本，以分散資料庫叢集的讀取負載。Aurora 複本的資料庫執行個體類別不必與主要執行個體相同。

如需新增 Aurora 複本到資料庫叢集的詳細資訊，請參閱[將 Aurora 複本新增至資料庫叢集](aurora-replicas-adding.md)。

## 管理連線
<a name="Aurora.Managing.MaxConnections"></a>

允許對 Aurora 資料庫執行個體建立的連線數上限，由資料庫執行個體的執行個體層級參數群組中的 `max_connections` 參數決定。根據用於資料庫執行個體的資料庫執行個體類別及資料庫引擎相容性，此參數的預設值有所不同。


| 資料庫引擎 | max\$1connections 預設值 | 
| --- | --- | 
|  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 Proxy。RDS 代理是個完全受管、高可用性的資料庫代理，其使用連線集區，安全且高效地共用資料庫連線。如要進一步了解 RDS 代理，請參閱 [Amazon RDS Proxy for Aurora](rds-proxy.md)。

## 管理查詢執行計劃
<a name="Aurora.Managing.Optimizing"></a>

如果您使用的是 Aurora PostgreSQL 的查詢計劃管理，您能夠控制最佳化工具將執行哪些計劃。如需更多詳細資訊，請參閱 [管理 Aurora PostgreSQL 的查詢執行計劃](AuroraPostgreSQL.Optimize.md)。