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

透過 Amazon Aurora 執行概念驗證

下列內容將說明如何設定並執行 Aurora 的概念驗證。概念驗證是一種調查，可用來確認 Aurora 是否適合您的應用程式。概念驗證可助您了解資料庫應用程式中的 Aurora 功能，以及 Aurora 與您目前資料庫環境的比較。它還可以顯示移動資料、連接埠SQL代碼、調整效能以及調整目前的管理程序所需的努力程度。

在本主題中，您可以找到執行概念證明所涉及的高階程序和決策 step-by-step 大綱，如下所列。如需詳細說明，您可點選特定主題的連結，閱讀完整文件。

Aurora 概念驗證概觀

當您對 Amazon Aurora 進行概念驗證時，您將了解如何將現有資料和SQL應用程式移植到 Aurora。您會使用一定量的資料和活動來代表您的生產環境，大規模執行 Aurora 的重要面向。目標是要確認 Aurora 的優勢，能夠完美解決您不想再使用舊有資料庫基礎設施的問題。在概念驗證的結尾，您將取得堅實的計畫，能夠執行更大規模的效能基準與應用程式測試。此時，您會了解生產部署過程中最大的作業項目。

下列最佳實務的建議有助您避開基準測試期間造成問題的常見錯誤。不過，本主題並不涵蓋執行效能測試和執行效能調整的 step-by-step 程序。相關程序會取決於您的工作負載，以及您使用的 Aurora 功能。如需詳細資訊，請參考效能相關文件，例如 管理 Aurora 資料庫叢集的效能和擴展、Amazon Aurora MySQL 效能增強功能、Amazon Aurora PostgreSQL 的效能和擴展 及在 Amazon Aurora 上使用績效詳情監控資料庫負載。

本主題中的資訊主要適用於您的組織撰寫程式碼並設計結構描述以及支援 My SQL 和 Postgre SQL 開放原始碼資料庫引擎的應用程式。若您測試的商用應用程式或程式碼係由應用程式架構所產生，您可能會無法靈活應用所有準則。在這種情況下，請洽詢您的 AWS 代表，瞭解您的應用程式類型是否有 Aurora 最佳實務或案例研究。

1. 確認您的目標

評估將 Aurora 用於概念驗證時，您會選擇要訂定何種衡量方式，以及如何評估執行是否成功。

您必須確認應用程式的所有功能均與 Aurora 相容。由於 Aurora 主要版本與對應主要版本的 My SQL 和 Postgre 相容SQL，因此大多數為這些引擎開發的應用程式也與 Aurora 相容。不過，您仍必須依據每個應用程式，確認其相容性。

例如，您設定 Aurora 叢集時所選擇的部分組態，會影響您是否能夠/應該採用特定資料庫功能。您可從最一般用途的 Aurora 叢集著手，也就是佈建。接著，您可能要判斷特定組態 (如無伺服器或平行查詢) 能否為您的工作負載帶來效益。

詢問下列問題有助您確認目標並加以量化：

請花些時間認識 Aurora 資料庫引擎和平台功能，同時檢閱服務文件，並記下所有能夠幫助您取得滿意結果的功能。其中之一可能是工作負載合併，請參閱 AWS 資料庫部落格文章如何使用我對合併工作負載的SQL相容性規劃和優化 Amazon Aurora。另一個以需求為基礎的擴展功能或許也很實用，請參閱 Amazon Aurora 使用者指南中的Amazon Aurora Auto Scaling with Aurora 複本。其他功能則包括提升效能，或者簡化資料庫的操作。

2. 了解您的工作負載特性

依據您預期的使用案例來評估 Aurora。Aurora 是線上交易處理 (OLTP) 工作負載的理想選擇。您也可以在保存即時OLTP資料的叢集上執行報告，而無需佈建個別的資料倉儲叢集。您可檢視您使用案例是否具備下列特性，確認該案例是否屬於類似情境：

選擇資料庫的關鍵因素之一就是資料的速度。高速表示資料插入與更新的次數相當頻繁。此類系統可能有數千個連線及數十萬個同時查詢，都會針對資料庫進行讀取和寫入。高速系統的查詢通常會影響相對少數的資料列，而且會存取相同資料列內的多個欄。

Aurora 係針對處理高速資料而設計，搭配單一 r4.16xlarge 資料庫執行個體的 Aurora 叢集會視其工作負載，每秒可能要處理超過 60 萬筆 SELECT 陳述式。同樣地，取決於工作負載而定，這樣的叢集每秒可以處理 200,000 個 INSERT、UPDATE，以及DELETE 陳述式。Aurora 是一個資料列儲存區資料庫，非常適合用於大量、高輸送量和高度平行OLTP化的工作負載。

Aurora 也可以在處理OLTP工作負載的相同叢集上執行報告查詢。Aurora 支援多達 15 個複本，每個複本平均會在主要執行個體的 10—20 毫秒內。分析師可以即時查詢OLTP資料，而無需將資料複製到個別的資料倉儲叢集。透過 Aurora 叢集使用平行查詢功能，您可將多數處理、篩選和彙總作業，卸載至廣泛分散的 Aurora 儲存子系統。

使用此規劃階段來熟悉 Aurora、其他 AWS 服務 AWS Management Console、和. AWS CLI此外，請確認如何在概念驗證中，將這些功能與您預計要使用的其他工具搭配使用。

3. 使用 AWS Management Console 或練習 AWS CLI

下一步，練習 AWS Management Console 或 AWS CLI，熟悉這些工具和 Aurora。

與實踐 AWS Management Console

Aurora 資料庫叢集的下列初始活動主要是讓您熟悉 AWS Management Console 環境，並練習設定和修改 Aurora 叢集。如果您將與我的SQL兼容和 Postgre 兼容的數據庫引擎與 Amazon 一起使用RDS，則可以在使用 Aurora 時SQL基於該知識。

善用 Aurora 的共用儲存模型和功能 (如複寫和快照)，可將整個資料庫叢集視為另一種您可以自由掌控的物件。在概念驗證期間，您可頻繁設定、拆卸和變更 Aurora 叢集的容量，不用因為最初的容量、資料庫設定和實際資料配置選擇而綁手綁腳。

若要開始使用，請設置空的 Aurora 叢集。請為您的最初測試選擇 provisioned (佈建的) 容量類型，以及 regional (區域性) 位置。

使用用戶端程式 (例如SQL命令列應用程式) Connect 至該叢集。首先，您使用叢集端點來連接。您可以連線到該端點以執行任何寫入作業，例如資料定義語言 (DDL) 陳述式和擷取、轉換、load (ETL) 程序。稍後在概念驗證中，您會使用讀取器端點來連接至查詢密集的工作階段，此端點會將查詢工作負載分散至叢集內的多個資料庫執行個體。

新增更多 Aurora 複本來擴展叢集，相關程序請參閱以 Amazon Aurora 進行複寫。透過變更執行個體類別來擴展或縮減資料庫 AWS 執行個體。請了解 Aurora 如何簡化這類操作，若您對系統容量的初估值不正確，即可知道如何調整，無須重新來過。

建立快照，並將其還原至不同的叢集。

檢查叢集指標來查看各個時間的活動，並確認指標如何套用至叢集內的資料庫執行個體。

它是有用的熟悉如何通過 AWS Management Console 在一開始做這些事情。了解 Aurora 的功能後，即可進展至使用 AWS CLI，將這些操作自動化。在以下各節中，您可以找到有關此 proof-of-concept 期間這些活動的程序和最佳作法的更多詳細資訊。

與實踐 AWS CLI

我們建議自動化部署和管理程序，即使在 proof-of-concept 設定中也是如此。要做到這一點，熟悉 AWS CLI 如果你還沒有。如果您將與我的SQL兼容和 Postgre 兼容的數據庫引擎與 Amazon 一起使用RDS，則可以在使用 Aurora 時SQL基於該知識。

Aurora 通常會牽涉到叢集內安排的資料庫執行個體群組。因此，許多操作會判斷與叢集相關聯的資料庫執行個體，然後重複在所有執行個體執行管理操作。

例如，您自動化的步驟可能包括建立 Aurora 叢集、透過更大的執行個體類別或額外的資料庫執行個體分別將之垂直、橫向擴展。如此一來，即可在概念驗證中的任何階段重複動作，並探索不同類或不同組態的 Aurora 叢集的模擬情境。

請認識基礎設施部署工具 (如 AWS CloudFormation) 的功能與限制。您可能會發現您在 proof-of-concept 前後關聯中執行的活動不適合生產使用。例如，修改的 AWS CloudFormation 行為是建立新執行個體並刪除目前執行個體，包括其資料。如需此行為的詳細資訊，請參閱 AWS CloudFormation 使用者指南中的更新堆疊資源的行為。

4. 建立 Aurora 叢集

透過 Aurora，您可將資料庫執行個體新增至叢集，或者將資料庫執行個體擴展為更為強大的執行個體類別，藉此探索模擬情境。您也可用不同的組態設定來建立叢集，同時執行相同的工作負載。有了 Aurora，您將享受更多彈性來設置、拆卸或重新設定資料庫叢集。鑑於此，在過程的早期階段練習這些技術會很有幫 proof-of-concept 助。如需建立 Aurora 叢集的一般程序，請參閱建立 Amazon Aurora 資料庫叢集。

如可行，請使用下列設定來著手。若您心中有特定使用案例，請略過此步驟。例如，若您的使用案例需要特殊類別的 Aurora 叢集，則可略過此步驟；或者，若您需要特定資料庫引擎和版本的組合，也可略過此步驟。

5. 設定您的結構描述

在 Aurora 叢集上，為您的應用程式設定資料庫、資料表、索引、外部索引鍵和其他結構描述物件。如果您要從另一個 My SQL 兼容或 Postgre SQL 兼容的數據庫系統中移動，請期望此階段簡單明了。您可以使用與資料庫引擎相同的SQL語法和命令列或其他用戶端應用程式。

若要在叢集上發出SQL陳述式，請尋找其叢集端點，並提供該值做為用戶端應用程式的連線參數。在叢集詳細資訊頁面的 Connectivity (連線功能) 索引標籤中，即可找到叢集端點。叢集端點會標記 Writer (寫入器)，另一個標記為 Reader (讀取器) 的端點就是您可提供給最終使用者的唯讀連線，讓他們執行報告或其他唯讀查詢。如需連接至叢集的問題協助，請參閱連接至 Amazon Aurora 資料庫叢集。

若您要從不同的資料庫系統轉換結構描述和資料，此時必須略為修改結構描述，這些結構描述變更是為了符合 Aurora 中可用的SQL語法和功能。您可以保留部分欄、限制、觸發條件或其他結構描述物件不變，這樣做可能很有用，因為這些物件對您的概念驗證目標而言可能並不重要，而且未來或許需要搭配 Aurora 相容性重新處理。

如果您要從具有與 Aurora 不同的基礎引擎的資料庫系統進行遷移，請考慮使用 AWS Schema Conversion Tool (AWS SCT) 來簡化程序。如需詳細資訊，請參閱 AWS Schema Conversion Tool 使用者指南。如需有關移轉和移轉活動的一般詳細資訊，請參閱將資料庫遷移到 Amazon Aurora AWS 白皮書。

此時您可評估結構描述設定是否有效率不彰的問題，例如索引策略或其他資料表結構 (如分割資料表)。將應用程式部署在使用多個資料庫執行個體且工作負載繁重的叢集時，這類效率問題可能會放大。請考慮是否現在就微調這方面的效能層面，或者在稍後的活動 (如完整基準測試) 中再來微調。

6. 匯入資料

概念驗證期間，您會將資料或代表範本，遷離舊有的資料庫系統。如可行，請在每個資料表內至少設定一些資料，如此有助測試所有資料類型和結構描述功能的相容性。練習基本的 Aurora 功能後，請擴展資料量。當您完成概念驗證時，您應該使用足夠大的資料集來測試您的ETL工具、查詢和整體工作負載，這些資料集足以得出準確的結論。

您可使用數個技術，將實體資料或邏輯備份資料匯入 Aurora。如需詳細資訊，請參閱將資料遷移到 Amazon Aurora 我的資料SQL庫叢集或使用 Postgre SQL 相容性將資料遷移至 Amazon Aurora (視您在概念驗證中使用的資料庫引擎而一)。

試用您正在考慮的ETL工具和技術。並選出最能符合需求的。請同時考量輸送量和彈性，例如，某些ETL工具會執行一次性傳輸，而其他工具則涉及從舊系統到 Aurora 的持續複寫。

如果您要從我的SQL相容系統遷移至 Aurora MySQL，則可以使用原生資料傳輸工具。如果您要從 Postgre SQL 兼容系統遷移到 Aurora Postgre，則同樣適用。SQL如果您要從使用與 Aurora 不同的基礎引擎的資料庫系統遷移，您可以嘗試使用 AWS Database Migration Service (AWS DMS)。如需詳細資訊 AWS DMS，請參閱使AWS Database Migration Service 用者指南。

如需有關移轉和移轉活動的詳細資訊，請參閱 Aurora 移轉手冊 AWS白皮書。

7. 移植您的SQL程式碼

根據不同的情況，嘗試SQL和關聯的應用程序需要不同程度的努力。特別是，努力程度取決於您是從 My 兼容還是 Postgre SQL SQL 兼容系統還是其他類型的系統移動。

此時您可評估結構描述設定是否有效率不彰的問題，例如索引策略或其他資料表結構 (如分割資料表)。請考慮是否現在就微調這方面的效能層面，或者在稍後的活動 (如完整基準測試) 中再來微調。

您可在應用程式中驗證資料庫連線邏輯。為了善加運用 Aurora 的分散式處理能力，讀取和寫入操作可能需要不同的連線，而查詢操作則使用相對短的工作階段。如需連線的詳細資訊，請參閱 9. 連線到 Aurora。

請確認您的生產資料庫是否有所犧牲或權衡以應付問題，在 proof-of-concept 排程中建置時間，以改善結構描述設計和查詢。如要判斷您是否成功兼顧效能、營運成本和擴充能力，請在不同 Aurora 叢集上同時測試原始和修改後的應用程式。

如需有關移轉和移轉活動的詳細資訊，請參閱 Aurora 移轉手冊 AWS白皮書。

8. 指定組態設定

您也可以在 Aurora proof-of-concept 練習中檢閱資料庫組態參數。您可能已經針對目前環境中的效能和延展性進行了調整 My SQL 或 Postgre SQL 組態設定。Aurora 儲存子系統會針對分散式雲端環境和高速儲存子系統進行調整，因此許多舊有的資料庫引擎設定並不適用。建議您透過預設 Aurora 組態設定來進行初始測試。只有當效能和擴充能力出現瓶頸時，才重新套用目前環境的設定。如果您有興趣，可以在 AWS 資料庫部落格上簡介 Aurora 儲存引擎中更深入地了解這個主題。

對於特定應用或使用案例，Aurora 可輕鬆重複使用最佳組態設定。您會管理指派至整個叢集或特定資料庫執行個體的參數組，無須針對每個資料庫執行個體個別編輯組態檔案。例如，時區設定會套用至叢集內的所有資料庫執行個體，而且您可針對每個資料庫執行個體調整頁面快取大小設定。

請從一組預設參數組著手，再將變更套用至您需要微調的參數。如需使用參數群組的詳細資訊，請參閱 Amazon Aurora 資料庫叢集和資料庫執行個體參數。如需 Aurora 叢集適用或不適用的組態設定資訊，請參閱 Aurora MySQL 組態參數或 Amazon Aurora PostgreSQL 參數 (視您的資料庫引擎而異)。

9. 連線到 Aurora

初次設定結構描述與資料並執行範例查詢時，您會發現您可連線至 Aurora 叢集內的不同端點。所使用的端點取決於該操作為讀取 (如 SELECT 陳述式) 或者寫入 (如 CREATE 或 INSERT 陳述式)。在 Aurora 叢集上增加工作負載並測試 Aurora 功能時，您的應用程式務必將每個操作指派給適當的端點。

針對寫入操作使用叢集端點，您會一律連線至叢集內具有讀/寫能力的資料庫執行個體。根據預設，Aurora 叢集內只有一個資料庫執行個體具備讀/寫能力。這個執行個體稱為主要執行個體。若原始主要執行個體變得無法使用，Aurora 會啟動容錯移轉機制，另一個資料庫執行個體會成為主要執行個體。

同樣地，將 SELECT 陳述式指向讀取器端點，即可分散叢集內資料庫執行個體處理查詢的作業。每個讀取器連線都會使用循環配置DNS解析度指派給不同的資料庫執行個體 在唯讀資料庫 Aurora 複本上執行大部分的查詢工作可減少主執行個體的負載，讓它能夠處理DDL和DML陳述式。

使用這些端點會減少對硬編碼主機名稱的依賴，有助應用程式更快速從資料庫執行個體的故障中恢復。

Aurora 複本會產生複本延遲，不過通常僅 10 至 20 毫秒。您可監控複寫延遲，並判斷該延遲是否仍在您資料一致性所需的範圍內。在某些情況下，您的讀取查詢可能需要較強的讀取一致性（read-after-write一致性）。此時可沿用叢集端點，不要改用讀取器端點。

如要善加運用 Aurora 的功能來達成分散式平行執行，您可能需要變更連線邏輯，目標是避免將所有讀取請求傳送至主要執行個體。唯讀 Aurora 複本及其中所有資料會準備好來處理 SELECT 陳述式。將應用程式的邏輯，撰寫成針對各種操作使用適當的端點。請遵守這些一般準則：

如需 Aurora 連線管理和端點的一般資訊，請參閱連接至 Amazon Aurora 資料庫叢集。如需深入瞭解此主題，請參閱 Aurora 我的SQL資料庫管理員手冊 — 連線管理。

10. 執行工作負載

結構描述、資料和組態設定就緒後，即可執行工作負載，開始演練叢集。在概念驗證中使用的工作負載，要能反映生產工作負載的主要面向。我們建議始終使用真實測試和工作負載來決定性能，而不是使用 sysbench 或-C 等綜合基準測試。TPC 無論何時，都可以根據您自己的結構描述、查詢模式和使用量來收集測量結果。

並盡可能複製出應用程式執行所在的實際情況。例如，您通常在與 Aurora 叢集位於相同 AWS 區域和相同虛擬私有雲端 (VPC) 的 Amazon EC2 執行個體上執行應用程式程式碼。如果您的生產應用程式在跨多個可用區域的多個EC2執行個體上執行，請以相同的方式設定您的 proof-of-concept 環境。如需區 AWS 域的詳細資訊，請參閱 Amazon RDS 使用者指南中的區域和可用區域。要了解有關 Amazon VPC 服務的更多信息，請參閱什麼是 AmazonVPC？ 在 Amazon 用VPC戶指南。

確認應用程式運作的基本功能並能夠透過 Aurora 存取資料後，您可以演練 Aurora 叢集的各個面向。建議您試用的功能包括搭配負載平衡的並行連線，以及自動複寫。

此時您應已熟悉資料傳輸機制，因此可以運用大量範例資料來執行測試。

在這個階段，您就能看見組態設定變動的效果，例如記憶體限制和連線限制。請重複 8. 指定組態設定中的程序。

您亦可演練其他機制，例如建立並還原快照。例如，您可以使用不同的 AWS 執行個體類別、 AWS 複本數量等來建立叢集。然後在每個叢集上，還原內含您的結構描述和所有資料的相同快照。如需此階段的詳細資訊，請參閱建立資料庫叢集快照及從資料庫叢集快照還原。

11. 測量效能

這部份的最佳實務能夠確保所有工具和流程均正確設定，可在工作負載操作期間快速隔離異常行為，也能讓您可靠辨識任何問題的合理原因。

您可在 Monitoring (監控) 索引標籤查看叢集的目前狀態，或者隨時間檢查趨勢。每個 Aurora 叢集或資料庫執行個體的主控台詳細資訊頁面，都會提供此索引標籤，它以圖表的形式顯示來自 Amazon CloudWatch 監控服務的指標。您可依據名稱、資料庫執行個體和時間區間篩選指標。

如需 Monitoring (監控) 索引標籤的更多選項，請在叢集設定內啟用增強型監控及績效詳情。若設定叢集時未選擇啟用這些選項，您也可以稍後再進行設定。

如要測量效能，您主要會仰賴呈現整個 Aurora 叢集的活動的圖表。您可確認 Aurora 複本是否有類似負載和回應時間，並查看作業是如何分割到讀/寫主要執行個體及唯讀 Aurora 複本。若資料庫執行個體之間並不平衡，或者某個問題僅影響一個資料庫執行個體，您可在 Monitoring (監控) 索引標籤內檢查該特定執行個體的情形。

模擬生產應用程式的環境和實際工作負載設定完成後，您可測量 Aurora 的效能。最重要的問題如下：

若要檢視輸送量和延遲指標，請在 Amazon RDS 主控台中查看指定 Aurora 叢集的監控索引標籤。下列擷取畫面顯示「監督」頁籤上的「選取延遲」、「DML延遲」、「選取傳輸DML量」和「傳輸量」測量結果的範例。

若可以，請在您目前環境為這些指標建立基準值。若無法，請執行等同於生產應用程式的工作負載，藉此在 Aurora 上建構基準。例如，執行您的 Aurora 工作負載，其中同時上線使用者和查詢數量採用類似數量。接著，觀察這些值如何依據您測試不同的執行個體類別、叢集大小、組態設定等而變化。

若輸送量數據低於預期，請進一步調查影響工作負載資料庫效能的因素。同樣地，若延遲數據高於預期，請進一步調查。若要這樣做，請監視資料庫伺服器 (CPU、記憶體等) 的次要度量。檢查資料庫執行個體是否接近這些限制值。您也可看到資料庫執行個體有多少多餘的容量，可處理更多並行查詢、對更大資料表的查詢等等。

評估理想 Aurora 叢集大小和容量時，您找到的組態須能夠處理應用程式的尖峰效能，而且不會過度佈建資源。其中一個重要的因素在於在 Aurora 叢集中，為資料庫執行個體找到適當大小。首先選取CPU與您目前生產環境具有類似記憶體容量的執行個體大小。然後收集工作負載在該執行個體大小中的輸送量和延遲數據。接著，將執行個體擴展至下一個更大的大小，檢查輸送量和延遲數據是否改善。同樣地，縮減執行個體大小，並檢查延遲和輸送量數據是否不變。您的目標是在最小的執行個體上，取得最高的輸送量及最低的延遲。

執行效能測試的時間要夠長，才能測量資料庫在穩定的預備狀態下的效能。您可能要執行工作負載數分鐘、甚至數小時，才能到達穩定狀態。執行初期出現些許變動十分正常，變動出現的原因在於每個 Aurora 複本，會依據其處理的 SELECT 查詢來讓快取準備就緒。

Aurora 在處理交易式工作負載的效能最佳，其中涉及多個同時使用者和查詢。如要確保您啟動的負載足以實現最佳效能，請執行多執行緒的基準，或在效能測試中同時執行多個執行個體。請運用數百甚至數千個同時用戶端執行緒來測量效能，並模擬生產環境預期會同時出現的執行緒數量。您可能也要以更多執行緒執行其他壓力測試，藉以測量 Aurora 的擴充能力。

12. 演練 Aurora 高可用性

Aurora 的許多主要功能均與高可用性有關。這些功能包括自動複寫、自動容錯移轉、具有 point-in-time 還原功能的自動備份，以及將資料庫執行個體新增至叢集的功能。這類功能提供的安全與可靠性，對於關鍵任務應用程式十分重要。

評估這些功能需要特定思維。在早期活動 (如效能測量) 中，您會觀察到系統在一切運作順利下的效能如何，而測試高可用性必須全面考慮最差情況的行為。您必須考量各種故障類型，即使該情況非常少見也不能忽略。建議您故意引發一些問題，確認系統可正確而快速地回復。

我們建議在每個 Aurora 叢集內使用至少兩個執行個體，Aurora 叢集中的資料庫執行個體最多可跨三個可用區域 (AZs)。請將前兩個或三個資料庫執行個體放入不同 AZ。當您開始使用較大的叢集時，請將資料庫執行個體分散到 AWS 區域AZs中的所有執行個體。如此可增加容錯能力。即使一個問題影響整個 AZ，Aurora 可容錯移轉至不同 AZ 的資料庫執行個體。如果您執行的叢集包含三個以上的執行個體，請盡可能平均地將資料庫執行個體分配到這三個執行個體上AZs。

如要進一步了解如何模擬故障情形來測試高可用性功能，請參閱測試 Amazon Aurora 我SQL使用故障注入查詢。

作為 proof-of-concept 練習的一部分，其中一個目標是為這些資料庫執行個體找到理想的資料庫執行個體數量和最佳執行個體類別。要達到這個目標，您必須兼顧高可用性及效能的各自需求。

以 Aurora 而言，叢集內有愈多資料庫執行個體，高可用性的效益就愈大。擁有的資料庫執行個體數較多，也會改善讀取密集型應用程式的可擴展性。Aurora 可以在唯讀 Aurora 複本中分佈多個連接，來進行 SELECT 查詢。

另一方面，限制資料庫執行個體的數量，會減少從主要節點的複寫流量。複寫流量會消耗網路頻寬，此為整體效能和擴充能力必須考量的另一面向。因此，對於寫入密集型OLTP應用程式，偏好擁有較少數量的大型資料庫執行個體，而不是許多小型資料庫執行個體。

在典型的 Aurora 叢集中，一個資料庫執行個體 (主要執行個體) 會處理所有DDL和DML陳述式。其他資料庫執行個體 (Aurora 複本) 則僅處理 SELECT 陳述式。雖然資料庫執行個體的工作量不一定相同，我們建議叢集內的所有資料庫執行個體都採用相同的執行個體類別。如此一來，若故障發生使得 Aurora 將一個唯讀資料庫執行個體提升為新的主要執行個體，則主要執行個體就可保有相同容量。

若同一叢集內須使用不同容量的資料庫執行個體，請為這些資料庫執行個體設定容錯移轉方案。這些方案會決定容錯移轉機制提升 Aurora 複本的順序。將容量明顯較大或較小的資料庫執行個體放到更低的容錯移轉方案，如此才會最後才選擇它們進行提升。

練習 Aurora 的資料復原功能，例如自動 point-in-time 還原、手動快照與還原，以及叢集回溯。如果適用，請將快照複製到其他 AWS 區域並還原到其他 AWS 區域以模擬 DR 案例。

調查組織對還原時間目標 (RTO)、還原點目標 (RPO) 和地理備援的需求。多數組織將這些事項納入整體災難復原類別底下。在災難復原程序的內容中評估本節所述的 Aurora 高可用性功能，以確保符合您的RTO和RPO需求。

13. 後續作業

在成功的 proof-of-concept 過程結束時，您根據預期的工作負載確認 Aurora 是適合您的解決方案。透過上述流程，您已檢查 Aurora 在實際操作環境中的運作情形，同時測量其是否符合您的成功條件。

透過 Aurora 設定完資料庫環境並開始運行後，接著您可開始執行更詳細的評估作業，最後才會遷移並進行生產部署。根據您的情況，這些其他步驟可能包含或可能不會包含在此過 proof-of-concept 程中。如需有關移轉和移轉活動的詳細資訊，請參閱 Aurora 移轉手冊 AWS白皮書。

另一項後續作業則是，請考量工作負載相關的安全組態，並將其設計為滿足您生產環境的安全要求。請計劃要採取哪些控管措施，以保護 Aurora 叢集主要使用者登入資料的存取。請定義資料庫使用者的角色與責任，以控制對存放於 Aurora 叢集內資料的存取。請考量應用程式、指令碼和第三方工具或服務的資料庫存取要求。探索 AWS 服務和功能，例如 AWS Secrets Manager 和 AWS Identity and Access Management (IAM) 驗證。

此時，您應已理解透過 Aurora 執行基準測試的程序和最佳實務，因此可能會需要其他效能調校。如需詳細資訊，請參閱管理 Aurora 資料庫叢集的效能和擴展、Amazon Aurora MySQL 效能增強功能、Amazon Aurora PostgreSQL 的效能和擴展 和在 Amazon Aurora 上使用績效詳情監控資料庫負載。若需要其他調校作業，請確認您已熟悉您在概念驗證期間收集的指標。在後續作業中，您建立的新叢集可能會選擇不同的組態設定、資料庫引擎和資料庫版本。或者，您可能會建立特殊類別的 Aurora 叢集，以滿足特定使用案例的需求。

例如，您可以探索適用於混合式交易/分析處理 (HTAP) 應用程式的 Aurora parallel 查詢叢集。為了災難復原或縮減延遲而需要分散的地理分布，您可探索 Aurora 全球資料庫。若您的工作負載為間歇性，或者您正在開發/測試情境中使用 Aurora，您可探索 Aurora Serverless 叢集。

您的生產叢集可能也需要處理大量傳入連線。若要瞭解這些技巧，請參閱 A AWS urora 我的SQL資料庫管理員手冊 — 連線管理。

概念驗證之後，若您覺得 Aurora 不適合您的使用案例，請考慮其他 AWS 服務：