本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用 Aurora serverless 的自動暫停和繼續擴展至零個 ACU
您可以指定 Aurora serverless 資料庫執行個體縮減規模到零個 ACU，如果使用者活動未在指定期間內啟動任何連線，則會自動暫停。您可以為資料庫叢集指定最小 ACU 值 0 來執行此操作。當執行個體處於暫停狀態時，您不需要支付執行個體容量的費用。為輕度使用或長時間閒置的 Aurora 叢集啟用自動暫停和繼續功能 (自動暫停)，可協助您管理資料庫機群的成本。
**注意**
自動暫停功能適用於 Aurora serverless 搭配 Aurora PostgreSQL 和 Aurora MySQL。您可能需要升級 Aurora 資料庫引擎版本，才能利用此功能。如需最低容量為 0 個 ACU的引擎版本，請參閱 [Aurora serverless 容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)。
**Topics**
+ [自動暫停概觀](#auto-pause-overview)
+ [先決條件和限制](#auto-pause-prereqs)
+ [開啟和關閉自動暫停](#auto-pause-enabling-disabling)
+ [自動暫停的運作方式](#auto-pause-how-it-works)
+ [自動暫停和 Aurora 叢集組態](#auto-pause-topology)
+ [監控自動暫停](#auto-pause-monitoring)
+ [自動暫停的故障診斷](#auto-pause-troubleshooting)
+ [自動暫停的應用程式設計](#auto-pause-applications)
## Aurora serverless 自動暫停功能概觀
Aurora serverless 資料庫執行個體可以在沒有使用者連線的期間之後自動暫停，並在連線請求送達時自動繼續。Aurora serverless 自動暫停/繼續功能有助於管理沒有嚴格服務水準目標 (SLO) 的系統成本。例如，您可以為用於開發和測試的叢集啟用此功能，或針對資料庫繼續時可接受短暫暫停的內部應用程式啟用此功能。如果您的工作負載處於閒置期間，並且可以在執行個體繼續時容忍輕微的連線延遲，請考慮針對 Aurora serverless 執行個體使用自動暫停來降低成本。
您可以透過指定叢集中的 Aurora serverless 資料庫執行個體是否可以自動暫停，以及每個執行個體在暫停之前必須閒置多久來控制此行為。若要啟用 Aurora 叢集中所有 Aurora serverless 資料庫執行個體的自動暫停行為，請將叢集的最小容量值設定為零個 ACU。
自動暫停功能可節省成本的優點類似於使用停止/啟動叢集功能。Aurora serverless 的自動暫停具有比啟動已停止叢集更快繼續的額外優點，並自動化決定何時暫停和繼續每個資料庫執行個體的程序。
自動暫停功能也提供額外的精細程度，以控制叢集內運算資源的成本。即使叢集中的寫入器執行個體和其他讀取器隨時保持作用中狀態，您仍可讓某些讀取器執行個體暫停。您可以透過將可與其他執行個體獨立暫停的讀取器執行個體指派為 2-15 範圍內的容錯移轉優先順序來執行此操作。
寫入器執行個體的容錯移轉優先順序為 0 和 1 的所有讀取器執行個體一律會同時暫停和繼續。因此，此群組中的執行個體在指定的時間間隔內沒有任何連線後便會暫停。
Aurora 資料庫叢集可以包含寫入器和讀取器資料庫執行個體，以及已佈建和 Aurora serverless 資料庫執行個體的組合。因此，若要有效地使用此功能，了解自動暫停機制的下列層面會很有幫助：
+ 資料庫執行個體可能自動暫停的情況。
+ 可能防止資料庫執行個體暫停的時間。例如，啟用某些 Aurora 功能或在叢集上執行特定類型的操作可能會防止執行個體暫停，即使對於這些執行個體沒有任何連線也是如此。
+ 執行個體暫停時監控和計費的後果。
+ 哪些動作會導致資料庫執行個體繼續處理。
+ 資料庫執行個體的容量在暫停和繼續事件期間如何變更。
+ 如何控制資料庫執行個體暫停之前的閒置間隔。
+ 如何編寫應用程式邏輯的程式碼，以處理資料庫執行個體繼續處理的期間。
## Aurora serverless 自動暫停功能的先決條件和限制
使用自動暫停功能之前，請檢查要使用的引擎版本。此外，請檢查自動暫停是否可搭配您打算使用的其他 Aurora 功能運作。如果您使用的是不支援它的引擎版本，則無法開啟自動暫停。對於不相容的功能，如果您將它們與自動暫停結合使用，則不會收到任何錯誤。如果叢集使用任何不相容的功能或設定，Aurora serverless 執行個體不會自動暫停。
+ 如果您使用的是 Aurora PostgreSQL，資料庫引擎必須至少執行 16.3、15.7、14.12 或 13.15 版。
+ 如果您使用的是 Aurora MySQL，資料庫引擎必須執行 3.08.0 版或更新版本。
+ 如需可使用此功能之引擎版本和 AWS 區域的完整清單，請參閱 [Aurora serverless 支援的區域和 Aurora 資料庫引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md)。
+ 當 Aurora serverless 執行個體繼續時，其容量可能會低於執行個體暫停時的容量。
特定情況或設定會防止 Aurora serverless 執行個體自動暫停。如需詳細資訊，請參閱[Aurora serverless 不會自動暫停的情況](#auto-pause-whynot)。
## 開啟和關閉自動暫停功能
您可以在叢集層級開啟和關閉自動暫停功能。若要這樣做，您可以使用與調整叢集容量下限和上限時相同的程序。自動暫停功能以最小容量 0 ACU 表示。
**Topics**
+ [開啟自動暫停](#auto-pause-enabling)
+ [自動暫停逾時間隔](#auto-pause-timeout)
+ [繼續執行個體](#auto-pause-waking)
+ [關閉自動暫停](#auto-pause-disabling)
### 為叢集中的 Aurora serverless 執行個體開啟自動暫停
請遵循 [設定叢集的 Aurora serverless 容量範圍](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus) 中的程序。針對最小容量，請選擇 0 ACU。當您選擇最小容量為 0 ACU 時，您也可以指定執行個體在自動暫停之前閒置的時間長度。
下列 CLI 範例顯示如何在啟用自動暫停功能且自動暫停間隔設定為十分鐘 (600 秒) 的情況下建立 Aurora 叢集。
```
aws rds create-db-cluster \
--db-cluster-identifier {{my-serverless-v2-cluster}} \
--region {{eu-central-1}} \
--engine {{aurora-mysql}} \
--engine-version {{8.0}} \
--serverless-v2-scaling-configuration MinCapacity={{0}},MaxCapacity={{4}},SecondsUntilAutoPause={{600}} \
--master-username {{myuser}} \
--manage-master-user-password
```
下列 CLI 範例顯示如何開啟現有 Aurora 叢集的自動暫停功能。此範例會將自動暫停間隔設定為一小時 (3600 秒)。
```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
--serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 0,
"MaxCapacity": 80.0,
"SecondsUntilAutoPause": 3600
}
```
### 可設定的 Aurora serverless 自動暫停逾時間隔
逾時間隔會以 Aurora 叢集的 `ServerlessV2ScalingConfiguration` 屬性表示。如果最小容量設定為零 ACUs，您可以在建立或修改 Aurora 叢集 AWS 管理主控台 時，在 中指定此間隔。您可以在建立或修改 Aurora 叢集時使用 `--serverless-v2-scaling-configuration` 參數， AWS CLI 在 中指定它。您可以在建立或修改 Aurora 叢集時使用 `ServerlessV2ScalingConfiguration` 參數，在 RDS API 中指定它。
您可以設定的最小間隔為 300 秒 (5 分鐘)。如果您未指定間隔，則這是預設值。您可以設定的間隔上限為 86,400 秒 (一天)。
假設您透過將叢集的最小容量變更為非零值來關閉叢集的自動暫停功能。在這種情況下，間隔屬性會從 `ServerlessV2ScalingConfiguration` 屬性中移除。缺少該屬性可額外確認該叢集的自動暫停功能已關閉。如果您稍後重新開啟自動暫停，您可以在此時再次指定任何自訂間隔。
### 繼續自動暫停的 Aurora serverless 執行個體
+ 當您連線到暫停的 Aurora serverless 執行個體時，它會自動繼續並接受連線。
+ 未包含有效憑證的連線嘗試仍會導致資料庫執行個體繼續。
+ 如果您透過寫入器端點連線，Aurora 會在自動暫停時繼續寫入器資料庫執行個體。同時，Aurora 會繼續容錯移轉優先順序為 0 或 1 的任何自動暫停讀取器執行個體，這表示其容量與寫入器執行個體的容量繫結。
+ 如果您透過讀取器端點連線，Aurora 會隨機選擇讀取器執行個體。如果該讀取器執行個體暫停，Aurora 會繼續它。Aurora 也會先繼續寫入器執行個體，因為如果任何讀取器執行個體處於作用中狀態，寫入器執行個體必須一律處於作用中狀態。當 Aurora 繼續該寫入器執行個體時，這也會導致容錯移轉提升層 0 和 1 中的任何讀取器執行個體繼續。
+ 如果您透過 RDS Data API 傳送請求至叢集，Aurora 會在暫停時繼續寫入器執行個體。然後，Aurora 會處理資料 API 請求。
+ 當您變更資料庫叢集參數群組中組態參數的值時，Aurora 會自動繼續使用該叢集參數群組的所有叢集中任何暫停的 Aurora serverless 執行個體。同樣地，當您變更資料庫參數群組中的參數值時，Aurora 會自動繼續使用該資料庫參數群組的任何暫停 Aurora serverless 執行個體。當您修改叢集以指派不同的叢集參數群組，或是修改執行個體以指派不同的資料庫參數群組時，也會套用相同的自動繼續行為。
+ 如果 Aurora serverless 寫入器執行個體暫停，執行繼續請求會自動繼續。Aurora 會在寫入器執行個體繼續後處理恢復請求。您可以恢復到 Aurora serverless 執行個體暫停的時間。
+ 建立叢集快照或刪除快照不會導致任何 Aurora serverless 執行個體繼續。
+ 建立 Aurora 複製會導致 Aurora 繼續所複製叢集的寫入器執行個體。
+ 如果暫停的執行個體在完成繼續之前收到大量的連線請求，則某些工作階段可能無法連線。我們建議對已啟用自動暫停的某些 Aurora serverless 執行個體的 Aurora 叢集的連線實作重試邏輯。例如，您可以重試任何失敗的連線三次。
+ Aurora 可以執行某些類型的次要內部維護，而無需喚醒執行個體。不過，在叢集維護時段期間發生的某些維護類型確實需要 Aurora 才能繼續執行個體。維護完成後，如果在指定的間隔後沒有活動，執行個體會自動再次暫停。
**注意**
Aurora 不會自動繼續引擎特定排程任務的暫停執行個體，例如 PostgreSQL `pg_cron` 延伸模組或 MySQL 事件排程器中的執行個體。為了確保此類任務執行，請在排程時間之前手動啟動與執行個體的連線。Aurora 不會將資料庫執行個體暫停時發生排程時間的任何任務排入佇列。當執行個體稍後繼續時，系統會略過此類任務。
+ 如果 Aurora 叢集在 Aurora serverless 執行個體自動暫停時經歷容錯移轉，Aurora 可能會繼續執行個體，然後將該執行個體提升為寫入器。如果一個或多個資料庫執行個體在執行個體暫停時從叢集中移除，則可能會發生相同情況。在此情況下，執行個體會在繼續時立即成為寫入器。
+ 變更叢集屬性的操作也會導致任何自動暫停的 Aurora serverless 執行個體繼續。例如，自動暫停的執行個體會繼續執行下列操作：
+ 變更叢集的擴展範圍。
+ 升級叢集的引擎版本
+ 從暫停的執行個體描述或下載日誌檔案。您可以啟用日誌上傳至 CloudWatch 並透過 CloudWatch 分析日誌，以檢查暫停執行個體的歷史日誌資料。
### 關閉叢集中 Aurora serverless 執行個體的自動暫停
請遵循 [設定叢集的 Aurora serverless 容量範圍](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus) 中的程序。針對最小容量，選擇 0.5 或更高的值。當您關閉自動暫停功能時，執行個體閒置的間隔會重設。如果您再次開啟自動暫停，您可以指定新的逾時間隔。
下列 CLI 範例顯示如何關閉現有 Aurora 叢集的自動暫停功能。`describe-db-clusters` 輸出顯示當最小容量設定為非零值時，會移除 `SecondsUntilAutoPause` 屬性。
```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
--serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 2,
"MaxCapacity": 80.0
}
```
## Aurora serverless 自動暫停功能的運作方式
您可以使用以下資訊來規劃使用自動暫停功能。了解執行個體暫停、繼續或保持作用中狀態的情況，可協助您平衡可用性、回應能力和成本節省之間的權衡。
**Topics**
+ [自動暫停的運作方式](#auto-pause-pausing)
+ [自動繼續的運作方式](#auto-pause-resuming)
+ [CPU 計費](#auto-pause-billing)
+ [防止自動暫停的情況](#auto-pause-whynot)
+ [與叢集停止/啟動的比較](#auto-pause-stop-start)
+ [維護和升級](#auto-pause-maintenance)
### Aurora serverless 執行個體暫停時會發生什麼情況
當 Aurora serverless 資料庫執行個體在一段時間後沒有連線的情況下暫停時：
+ 無論執行個體當時有多少 ACU，Aurora 都會在指定的間隔經過且沒有與執行個體的連線後開始暫停執行個體。
+ 暫停機制不是即時的。即將自動暫停的 Aurora serverless 執行個體可能會短暫等待，以了解 Aurora 儲存體的所有變更。
+ 該執行個體的執行個體費用會保留。當執行個體暫停時，`ServerlessV2Usage` 指標的值為 0。
+ 執行個體的狀態值不會變更。狀態仍顯示為「可用」。
+ 執行個體會停止寫入資料庫日誌檔案。除了為 `CPUUtilization` 和 `ACUUtilization` 註冊零百分比，以及為 `ServerlessDatabaseCapacity` 註冊零百分比以外，它會停止將指標傳送至 CloudWatch。
+ 當 Aurora serverless 資料庫執行個體開始暫停、完成暫停，以及暫停機制中斷或失敗時，Aurora 會發出事件。如需這些事件的詳細資訊，請參閱 [資料庫執行個體事件](USER_Events.Messages.md#USER_Events.Messages.instance)。
### 自動暫停的 Aurora serverless 執行個體繼續時會發生什麼情況
當 Aurora serverless 資料庫執行個體在自動暫停後繼續時，適用下列情況：
+ 執行個體繼續時，會套用 `pending-reboot` 變更中的任何參數變更。
+ Aurora 會在每個 Aurora serverless資料庫執行個體開始繼續、完成繼續，以及執行個體因某種原因而無法繼續時發出執行個體層級事件。如需這些事件的詳細資訊，請參閱 [資料庫執行個體事件](USER_Events.Messages.md#USER_Events.Messages.instance)。
+ 任何請求的連線會在資料庫執行個體完成繼續後建立。由於繼續的典型時間約為 15 秒，我們建議您將任何用戶端逾時設定調整為超過 15 秒。例如，在 JDBC 驅動程式設定中，您可以將 `connectTimeout` 和 `sslResponseTimeout` 設定的值調整為超過 15 秒。
**注意**
如果 Aurora serverless 執行個體保持暫停超過 24 小時，Aurora 可以讓執行個體進入更深層的睡眠，這需要更長的時間才能繼續。在這種情況下，繼續時間可以是 30 秒或更長，大約等同於重新啟動執行個體。如果您的資料庫閒置期間超過一天，建議您將連線逾時設定為 30 秒或以上。
### 執行個體計費對自動暫停 Aurora serverless 叢集的運作方式
當 Aurora serverless 執行個體自動暫停時，其執行個體費用為零。該期間的 `ServerlessV2Usage` 指標為零。Aurora 儲存體和叢集中未與該特定資料庫執行個體繫結的其他層面 AWS 仍會收費。
### Aurora serverless 不會自動暫停的情況
+ 如果資料庫叢集的最小容量值高於零個 ACU，則叢集中的 Aurora serverless 執行個體不會自動暫停。如果您現有的叢集在自動暫停功能可用之前具有 Aurora serverless 執行個體，最低容量設定為 0.5 ACU。若要對此類叢集使用自動暫停功能，請將最小容量設定修改為零個 ACU。
+ 如果任何使用者起始的連線開放給 Aurora serverless 執行個體，執行個體將不會暫停。當修補和升級等活動正在進行時，執行個體也不會暫停。Aurora 用於運作狀態檢查的管理連線不會計入活動，也不會防止執行個體暫停。
+ 在已啟用邏輯複寫的 Aurora PostgreSQL 叢集中，或已啟用 binlog 複寫的 Aurora MySQL 叢集中，容錯移轉提升層 0 和 1 中的寫入器和任何讀取器執行個體不會自動暫停。Aurora 會執行持續的最小活動量，以檢查複寫連線的運作狀態。
對於啟用複寫的叢集，您仍可在自動暫停的來源叢集中擁有 Aurora 讀取器執行個體。若要這樣做，請將容錯移轉優先順序設定為 0 或 1 以外的值。如此一來，它們就可以與寫入器執行個體分開暫停。
+ 如果您的 Aurora 叢集具有相關聯的 RDS Proxy，Proxy 會維護叢集中每個資料庫執行個體的開放連線。因此，此類叢集中的任何 Aurora serverless 執行個體都不會自動暫停。
+ 如果您的叢集是 Aurora 全球資料庫中的主要叢集，Aurora 不會自動暫停 Aurora serverless 寫入器執行個體。這是因為寫入器執行個體需要持續的活動層級，才能管理全球資料庫中的其他叢集。由於寫入器執行個體保持作用中狀態，任何容錯移轉優先順序為 0 或 1 的 Aurora serverless 讀取器執行個體也不會自動暫停。
+ Aurora 全球資料庫次要叢集中的 Aurora serverless 執行個體不會自動暫停。如果資料庫叢集提升為獨立叢集，則自動暫停功能會在符合所有其他情況時生效。
+ 在與 Redshift 有關聯的零 ETL 整合的叢集中，寫入器執行個體和容錯移轉提升層 0 和 1 中的任何讀取器執行個體不會自動暫停。
+ 除了執行個體主資料庫連接埠上的活動之外，如果 Aurora PostgreSQL 執行個體已啟用 Babelfish 功能，則 T-SQL 連接埠上的任何連線和活動都會防止執行個體自動暫停。
### 自動暫停如何搭配叢集停止/啟動功能運作
您可以在啟用自動暫停功能時停止和啟動 Aurora 叢集。某些執行個體是否暫停並不重要。當您再次啟動叢集時，任何暫停的 Aurora serverless 執行個體都會自動繼續。
當 Aurora 叢集停止時，任何暫停的 Aurora serverless 執行個體都不會根據連線嘗試自動繼續。再次啟動叢集後，就會套用暫停和繼續 Aurora serverless 執行個體的一般機制。
### 自動暫停 Aurora serverless 叢集的維護和升級如何運作
+ 當 Aurora serverless 執行個體自動暫停時，如果您嘗試升級 Aurora 叢集，Aurora 會繼續執行個體並進行升級。
+ Aurora 會定期繼續任何自動暫停的 Aurora serverless 執行個體以執行維護，例如次要版本升級和參數群組等屬性的變更。
+ Aurora serverless 執行個體喚醒以進行升級或套用維護等管理操作後，Aurora 會等待至少 20 分鐘，然後再次暫停該執行個體。這是為了允許任何背景操作完成。如果執行個體連續進行多個管理操作，則二十分鐘期間也會避免暫停和繼續執行個體多次。
## Aurora serverless 自動暫停如何適用於不同類型的 Aurora 叢集
自動暫停功能的考量取決於 Aurora 叢集中有多少執行個體、讀取器執行個體的容錯移轉提升層，以及所有執行個體是否是 Aurora serverless 或 Aurora serverless 和已佈建的組合。
**Topics**
+ [Aurora 叢集配置](#auto-pause-recommended-layouts)
+ [自動暫停寫入器執行個體](#auto-pause-writer)
+ [自動暫停多個可用區叢集和讀取器執行個體](#auto-pause-multi-az)
+ [自動暫停混合叢集](#auto-pause-provisioned)
### 使用自動暫停時建議的 Aurora 叢集配置
啟用自動暫停功能時，您可以為 Aurora 叢集安排高可用性、快速回應和可擴展性之間的適當平衡，以符合您的使用案例。您可以透過為叢集中的資料庫執行個體選擇 Aurora serverless 執行個體、已佈建執行個體和容錯移轉提升層的組合來執行此操作。
下列類型的組態示範叢集的高可用性和成本最佳化之間的不同權衡：
+ 對於開發和測試系統，您可以設定具有 Aurora serverless 資料庫執行個體的單一可用區域資料庫叢集。單一執行個體提供所有讀取和寫入請求。當叢集在相當時間間隔內未使用時，資料庫執行個體會暫停。此時，叢集的資料庫運算成本也會暫停。
+ 對於執行高可用性為優先順序的應用程式，但叢集仍有完全閒置期間的系統，您可以設定多個可用區叢集，其中寫入器和讀取器資料庫執行個體都是 Aurora serverless。將讀取器執行個體設定為容錯移轉優先順序 0 或 1，讓寫入器和讀取器執行個體同時暫停和繼續。現在，您可以在叢集處於作用中狀態時獲得快速容錯移轉的優勢。當叢集保持閒置狀態的時間超過自動暫停閾值時，這兩個執行個體的資料庫執行個體費用都會暫停。當叢集繼續處理時，第一個資料庫工作階段需要短暫的連線時間。
+ 假設您的叢集持續處於作用中狀態、活動量極少，且任何連線都需要快速回應。在這種情況下，您可以建立具有多個 Aurora serverless 讀取器執行個體的叢集，並將某些讀取器執行個體的容量從寫入器分離。為寫入器執行個體和一個讀取器執行個體指定容錯移轉優先順序 0 或 1。為其他讀取器執行個體指定大於 1 的優先順序。如此一來，較高優先順序層中的讀取器執行個體可以自動暫停，即使寫入器和其中一個讀取器保持作用中也是如此。
在這種情況下，您可以採用一些其他技術，以確保叢集在閒置期間仍縮減規模至低容量時持續可用：
+ 您可以針對寫入器和優先順序 0 或 1 讀取器使用佈建的執行個體。如此一來，兩個資料庫執行個體永遠不會自動暫停，且一律可用於提供資料庫流量和執行容錯移轉。
+ 您可以設定自訂端點，其中包含較高優先順序層中的 Aurora serverless 執行個體，但無法設定寫入器或提升層 0 或 1 讀取器。如此一來，您可以將對延遲不敏感的唯讀工作階段導向至可能會自動暫停的讀取器。您可以避免對此類請求使用讀取器端點，因為 Aurora 可能會將讀取器端點連線導向始終保持喚醒的讀取器執行個體，或是其中一個自動暫停的執行個體。使用自訂端點可讓您根據對快速回應或額外擴展容量的偏好，將連線導向不同的執行個體群組。
### 資料庫叢集中寫入器執行個體的 Aurora serverless 自動暫停運作方式
當 Aurora 資料庫叢集只包含單一資料庫執行個體時，自動暫停和繼續資料庫執行個體的機制非常簡單。它僅取決於寫入器執行個體上的活動。對於用於開發和測試的叢集，或用於執行高可用性不重要的應用程式，您可能具有此類組態。請注意，在單一執行個體叢集中，Aurora 會透過讀取器端點將連線導向寫入器資料庫執行個體。因此，對於單一執行個體資料庫叢集，嘗試連線至讀取器端點會導致自動暫停的寫入器資料庫執行個體繼續。
下列其他因素適用於具有多個資料庫執行個體的 Aurora 叢集：
+ 在 Aurora 資料庫叢集中，寫入器資料庫執行個體通常會經常性存取。因此，即使一或多個讀取器資料庫執行個體自動暫停，您可能會發現寫入器資料庫執行個體保持作用中狀態。
+ 讀取器資料庫執行個體上的某些活動需要提供寫入器資料庫執行個體。因此，在所有讀取器執行個體也暫停之前，寫入器資料庫執行個體都無法暫停。即使您的應用程式未直接存取寫入器執行個體，繼續任何讀取器執行個體也會自動繼續寫入器執行個體。
+ 容錯移轉提升層 0 和 1 中的 Aurora serverless 讀取器執行個體會進行擴展，使其容量與寫入器執行個體保持同步。因此，當 Aurora serverless 寫入器執行個體繼續時，任何位於提升層 0 或 1 的 Aurora serverless 讀取器執行個體都會繼續。
### Aurora serverless 自動暫停對多個可用區叢集的運作方式
在同時包含寫入器和一或多個讀取器資料庫執行個體的 Aurora 資料庫叢集內，某些 Aurora serverless 資料庫執行個體可能會在其他資料庫執行個體處於作用中狀態時暫停。寫入器執行個體和容錯移轉優先順序為 0 和 1 的任何讀取器執行個體一律會同時暫停和繼續。優先順序不是 0 或 1 的讀取器執行個體可以與其他執行個體分開暫停和繼續。
當您將此功能用於具有多個讀取器執行個體的叢集時，您可以管理成本，而不會犧牲高可用性。寫入器執行個體和另一個一或兩個讀取器執行個體隨時可以保持作用中狀態，而其他讀取器執行個體可以在不需要處理大量讀取流量時暫停。
讀取器執行個體是否可以自動暫停取決於其容量是否可以獨立擴展，或容量是否與寫入器資料庫執行個體的容量繫結。該擴展屬性取決於讀取器資料庫執行個體的容錯移轉優先順序。當讀取器的優先順序為 0 或 1 時，讀取器的容量會追蹤寫入器資料庫執行個體的容量。因此，若要允許讀取器資料庫執行個體在最廣泛的情況下自動暫停，請將優先順序設定為高於 1 的值。
繼續讀取器執行個體的時間可能比繼續寫入器執行個體稍長。如需執行個體可能暫停時的最快回應，請連線至叢集端點。
### Aurora serverless 自動暫停對具有佈建執行個體的叢集的運作方式
Aurora 資料庫叢集中的任何已佈建資料庫執行個體都不會自動暫停。只有具有 `db.serverless` 執行個體類別的 Aurora serverless 資料庫執行個體才能使用自動暫停功能。
當您的 Aurora 叢集包含任何佈建的資料庫執行個體時，任何 Aurora serverless 寫入器執行個體都不會自動暫停。這是因為在任何讀取器執行個體作用中時，寫入器執行個體必須保持可用。Aurora serverless 寫入器保持作用中的事實也表示容錯移轉優先順序為 0 和 1 的任何 Aurora serverless 讀取器執行個體都不會在包含任何已佈建執行個體的混合叢集中自動暫停。
## 監控使用自動暫停的 Aurora 叢集
若要監控 Aurora，您應該已經熟悉 [使用 Amazon CloudWatch 監控 Amazon Aurora 指標](monitoring-cloudwatch.md) 中的監控程序，以及 [Amazon Aurora 的指標參考](metrics-reference.md) 中列出的 CloudWatch 指標。請注意，當您監控使用自動暫停功能的 Aurora 叢集時，有一些特殊考量：
+ 因為 Aurora serverless 執行個體已暫停，所以有時候執行個體不會記錄日誌資料和大多數指標。執行個體暫停時傳送到 CloudWatch 的唯一指標為 `CPUUtilization` 和 `ACUUtilization` 的零百分比，以及 `ServerlessDatabaseCapacity` 的零百分比。
+ 您可以檢查 Aurora serverless 執行個體暫停的頻率是否高於或低於預期。若要這樣做，請檢查 `ServerlessDatabaseCapacity` 指標從非零值變更為零的頻率，以及它保持零的時間長度。如果執行個體的暫停時間不如預期，則無法節省盡可能多的成本。如果執行個體暫停和繼續的頻率高於您的預期，您的叢集在回應連線請求時可能會有不必要的延遲。如需影響 Aurora serverless 執行個體是否可以暫停以及暫停頻率之因素的相關資訊，請參閱 [Aurora serverless 自動暫停功能的先決條件和限制](#auto-pause-prereqs)、[Aurora serverless 不會自動暫停的情況](#auto-pause-whynot) 和 [Aurora serverless 自動暫停的故障診斷](#auto-pause-troubleshooting)。
+ 您也可以檢查記錄 Aurora serverless 執行個體自動暫停和繼續操作的日誌檔案。如果執行個體在逾時間隔到期後未暫停，此日誌檔案也包含自動暫停未發生的原因。如需詳細資訊，請參閱[監控 Aurora serverless 暫停和繼續活動](aurora-serverless-v2-administration.md#autopause-logging-instance-log)。
**Topics**
+ [檢查暫停的執行個體](#auto-pause-status)
+ [自動暫停和自動繼續事件](#auto-pause-events)
+ [Performance Insights 和增強型監控](#auto-pause-pi-em)
+ [Aurora 指標](#auto-pause-metrics)
### 檢查 Aurora serverless 執行個體是否暫停
若要判斷 Aurora serverless 執行個體是否處於暫停狀態，您可以觀察執行個體的 `ACUUtilization` 指標。執行個體暫停時，該指標的值為零。
當 Aurora serverless 執行個體暫停時，其狀態值仍會列為**可用**。當暫停的 Aurora serverless 執行個體正在繼續時，同樣適用。這是因為即使連線發生些微延遲，您也可以成功連線到此類執行個體。
任何與 Aurora 執行個體可用性相關的指標都會將執行個體暫停的期間視為執行個體可用的時間。
### 自動暫停和自動繼續操作的事件
當自動暫停和自動繼續操作開始、完成或取消時，Aurora 會發出 Aurora serverless 執行個體的事件。與自動暫停功能相關的事件是透過 `RDS-EVENT-0374` 的 `RDS-EVENT-0370`。如需這些事件的詳細資訊，請參閱 [資料庫執行個體事件](USER_Events.Messages.md#USER_Events.Messages.instance)。
### 自動暫停如何與 Performance Insights 和增強型監控搭配使用
當 Aurora serverless 執行個體暫停時，Aurora 不會透過 Performance Insights 或增強型監控來收集該執行個體的監控資訊。執行個體繼續時，在 Aurora 繼續收集此類監控資訊之前，可能會有短暫的延遲。
### Aurora serverless 自動暫停功能如何與 Aurora 指標互動
當 Aurora serverless 執行個體暫停時，它不會發出大多數 CloudWatch 指標或將任何資訊寫入其資料庫日誌。執行個體暫停時傳送到 CloudWatch 的唯一指標為 `CPUUtilization` 和 `ACUUtilization` 的零百分比，以及 `ServerlessDatabaseCapacity` 的零百分比。
當 CloudWatch 是執行個體或叢集可用性和執行時間相關的運算統計資料時，Aurora serverless 執行個體會被視為在暫停期間可用。
當您啟動 AWS CLI 或 RDS API 動作來描述或下載暫停Aurora serverless執行個體的日誌時，執行個體會自動繼續，以提供日誌資訊。
#### CloudWatch 指標範例
下列 AWS CLI 範例示範如何觀察執行個體容量隨時間變更的情況。在此期間，執行個體會自動暫停，然後繼續。暫停時，`ServerlessDatabaseCapacity` 指標會報告 0 的值。為了判斷執行個體是否在期間內的任何時間點暫停，我們會檢查該期間內的最小容量是否為零。
下列 Linux 範例代表已自動暫停一段時間的 Aurora serverless 執行個體。我們會在三分鐘的期間內每分鐘取樣 `ServerlessDatabaseCapacity` 一次。最小 ACU 值 0.0 會確認執行個體已在每分鐘的某個時間點暫停。
```
$ aws cloudwatch get-metric-statistics \
--metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--statistics Minimum \
--namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
--output text | sort -k 3
ServerlessDatabaseCapacity
DATAPOINTS 0.0 2024-08-02T22:11:00+00:00 None
DATAPOINTS 0.0 2024-08-02T22:12:00+00:00 None
DATAPOINTS 0.0 2024-08-02T22:13:00+00:00 None
```
接下來，我們會嘗試與暫停的 Aurora serverless 執行個體建立連線。在此範例中，我們刻意使用不正確的密碼，讓連線嘗試不會成功。儘管失敗，連線嘗試會導致 Aurora 繼續暫停的執行個體。
```
$ mysql -h {{my_cluster_endpoint}}.rds.amazonaws.com -u admin -p{{wrong-password}}
ERROR 1045 (28000): Access denied for user 'admin'@'{{ip_address}}' (using password: YES)
```
下列 Linux 範例示範暫停的執行個體已繼續、保持閒置約五分鐘，然後回到暫停狀態。執行個體以 2.0 ACU 的容量繼續。然後，它會稍微向上擴展，例如執行一些內部清除。由於它在五分鐘的逾時期間內未收到任何使用者連線嘗試，因此從 4.0 ACU 直接進入暫停狀態。
```
$ aws cloudwatch get-metric-statistics \
--metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--statistics Minimum \
--namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
--output text | sort -k 3
ServerlessDatabaseCapacity
DATAPOINTS 0.0 2024-08-02T22:13:00+00:00 None
DATAPOINTS 2.0 2024-08-02T22:14:00+00:00 None
DATAPOINTS 3.0 2024-08-02T22:15:00+00:00 None
DATAPOINTS 3.0 2024-08-02T22:16:00+00:00 None
DATAPOINTS 4.0 2024-08-02T22:17:00+00:00 None
DATAPOINTS 4.0 2024-08-02T22:18:00+00:00 None
DATAPOINTS 4.0 2024-08-02T22:19:00+00:00 None
DATAPOINTS 0.0 2024-08-02T22:20:00+00:00 None
```
如果報告旨在顯示執行個體擴展處理工作負載的速度，我們可能會為統計資料指定 `Maximum` 而非 `Minimum`。對於容量規劃和成本估算，我們可能會指定更長的期間並使用 `Average` 統計資料。如此一來，我們可以判斷在高活動量、低活動量和暫停狀態期間的一般容量值。為了在關於暫停和繼續的精確時間內檢查行為，我們可能會指定一秒的期間，並檢查較短的時間間隔。輸出中的時間戳記值，例如 `2024-08-02T22:13:00+00:00`，示範為 `--start-time` 和 `--end-time` 選項指定精確參數的格式。
## Aurora serverless 自動暫停的故障診斷
如果您發現 Aurora serverless 執行個體的暫停頻率不如預期，請檢查下列可能原因：
+ 確認您執行的 Aurora 版本支援最低容量為零個 ACU。如需不同 Aurora 版本的容量範圍，請參閱 [Aurora serverless 容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)。
+ 確認叢集的最小容量值設定為零個 ACU。
+ 確認有問題的執行個體實際使用 Aurora serverless 執行個體類別 `db.serverless`，而不是其中一個佈建的執行個體類別。
+ 確認叢集未使用來自 [Aurora serverless 自動暫停功能的先決條件和限制](#auto-pause-prereqs) 的任何不相容功能或設定。
+ 檢查日誌檔案，顯示 Aurora serverless 執行個體何時暫停、繼續，或 Aurora 因為某些原因而無法暫停或繼續執行個體。如需詳細資訊，請參閱[監控 Aurora serverless 暫停和繼續活動](aurora-serverless-v2-administration.md#autopause-logging-instance-log)。
+ 檢查是否有任何用戶端或應用程式長時間保持連線開啟。相反地，請檢查任何使用 RDS 資料 API 或 Lambda 函數的應用程式是否經常傳送請求，讓執行個體永遠不會閒置到足以暫停的時間。您可以檢查 CloudWatch 指標，例如 `ConnectionAttempts` 和 `DatabaseConnections`。如需詳細資訊，請參閱[Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
+ 如果讀取器執行個體很少暫停，請檢查其容錯移轉優先順序。如果讀取器用於讀取擴展，而不是在容錯移轉時作為待命，請將其設定為 2-15 範圍內的優先順序。
+ 如果寫入器執行個體很少暫停，請檢查您的讀取器執行個體使用情況。寫入器只能在整個叢集處於閒置狀態時暫停。這是因為連線到任何讀取器執行個體會導致寫入器繼續。
+ 如果您的應用程式在 Aurora serverless 執行個體繼續時於連線請求期間收到逾時，請考慮延長應用程式程式碼或基礎資料庫架構所使用的逾時間隔。較長的連線逾時可降低 Aurora serverless 執行個體繼續時連線失敗的可能性。不過，較長的逾時也會讓您的應用程式較慢，難以偵測叢集中的可用性問題。
相反地，請考慮延長自動暫停間隔，讓應用程式不會經常遇到暫停的執行個體。
如果自動暫停行為與應用程式的叢集回應能力之間沒有邏輯平衡，則該叢集可能不適合使用自動暫停功能。
+ 如果您估計 Aurora serverless 執行個體會暫停多久，請注意，有些因素會使精確預測變得不切實際。
+ 執行個體可能會定期繼續執行維護、次要版本升級，或將變更套用至參數群組。
+ 對於多個可用區叢集，在某些情況下，繼續一個執行個體也會導致其他執行個體繼續。繼續任何讀取器一律會導致寫入器繼續。繼續寫入器一律會導致容錯移轉優先順序為 0 和 1 的任何讀取器繼續。
我們建議您使用實際的工作負載，測量幾天內的實際暫停時間。然後，使用這些測量來設定您可以預期執行個體暫停的時間比例的基準。
+ 您可能會發現 MySQL 清除、MySQL 事件排程器、PostgreSQL 自動清空或透過 `pg_cron` 延伸模組排程的 PostgreSQL 任務等內部操作未執行或未完成。執行個體不會自動繼續執行不涉及使用者與資料庫連線的操作。如果自動暫停逾時到期時正在進行此類內部操作，則會取消 MySQL 清除和 PostgreSQL 自動清空等維護任務。如果 MySQL 事件排程器或 PostgreSQL `pg_cron` 延伸模組中的排程任務在 Aurora 啟動暫停操作時正在進行，也會取消這些任務。
如果您需要確保執行個體定期喚醒以執行排程的操作，您可以在任務開始時間之前啟動連線以繼續執行個體。您也可以增加自動暫停逾時間隔，以便在使用者活動完成後，自動清空等操作可以執行更長的時間。您也可以使用 Lambda 函數之類的機制，以在必要時自動繼續執行個體的方式排程執行資料庫操作。
## Aurora serverless 自動暫停功能的應用程式設計考量
當 Aurora serverless 資料庫執行個體在自動暫停後繼續時，它會從相對較小的容量開始，並從該容量向上擴展。即使資料庫執行個體在自動暫停之前有更高的容量，此起始容量也適用。
將此功能用於在建立連線時可容忍大約 15 秒間隔的應用程式。這會說明 Aurora serverless 執行個體因一個或少量傳入連線而繼續的典型案例。如果執行個體暫停超過 24 小時，則繼續的時間可能會更長。
如果您使用 Aurora serverless 搭配 Aurora 停止/啟動叢集功能，自動暫停Aurora serverless執行個體的恢復時間通常比啟動已停止叢集的時間短得多。
在應用程式中編碼連線邏輯時，如果第一次嘗試傳回具有暫時性原因的錯誤，請重試連線。(如果錯誤是由於驗證失敗，請在重試之前修正憑證。) 繼續後立即發生的錯誤可能是逾時，或與資料庫限制相關的一些錯誤。在極少數情況下，重試可以處理由於大量同時連線請求而繼續 Aurora serverless 執行個體的問題。在這種情況下，某些連線可能需要比平常更長的時間來處理，或可能超過第一次嘗試時同時連線的限制。
在應用程式開發和偵錯期間，請勿讓用戶端工作階段或具有資料庫連線的程式設計工具保持開啟狀態。如果有任何使用者起始的連線開啟，無論連線是否未執行任何 SQL 陳述式或交易，Aurora 都不會暫停執行個體。當 Aurora 叢集中的一個 Aurora serverless 執行個體無法暫停時，叢集中的其他執行個體也可能無法暫停。如需詳細資訊，請參閱[Aurora serverless 不會自動暫停的情況](#auto-pause-whynot)。
當 Aurora serverless 資料庫執行個體開始繼續、完成繼續，以及執行個體因為某些原因而無法繼續時，Aurora 會發出事件。如需這些事件的詳細資訊，請參閱 [資料庫執行個體事件](USER_Events.Messages.md#USER_Events.Messages.instance)。