Amazon Aurora 常見問答集

Amazon Aurora 是一種現代化關聯式資料庫服務，可大規模提供效能和高可用性、完全開放原始碼 MySQL (和 PostgreSQL) 相容版本，以及一系列用於建置無伺服器和機器學習 (ML) 驅動型應用程式的開發人員工具。

Aurora 具有分散式、容錯和自我修復的儲存系統，該系統與運算資源分離並將每個資料庫執行個體自動擴展至 128 TiB。它提供高效能和可用性，以及高達 15 個低延遲僅供讀取複本、時間點復原、持續備份至 Amazon Simple Storage Service (Amazon S3)，還可以跨三個可用區域 (AZ) 複寫。

Aurora 也是一項全受管服務，可自動執行硬體佈建、資料庫設定、修補和備份等耗時的管理任務，同時以十分之一的成本提供商業資料庫的安全性、可用性和可靠性。

Amazon Aurora 與現有的 MySQL 開源資料庫直接相容，並定期新增對新版本的支援。這意味著您可以使用標準匯入/匯出工具或快照輕鬆地將 MySQL 資料庫遷移至 Aurora 或從 Aurora 遷移。它還意味著您目前在 MySQL 資料庫使用的大部分程式碼、應用程式、驅動程式和工具只需進行少量變更或不需變更，即可與 Aurora 搭配使用。這使得在兩個引擎之間移動應用程式變得很容易。

您可以在文件中查看當前 Amazon Aurora 與 MySQL 版本的相容性資訊。

Amazon Aurora 與現有的 PostgreSQL 開源資料庫直接相容，並定期新增對新版本的支援。這意味著您可以使用標準匯入/匯出工具或快照輕鬆地將 PostgreSQL 資料庫遷移至 Aurora 或從 Aurora 遷移。它還意味著您目前在 PostgreSQL 資料庫使用的大部分程式碼、應用程式、驅動程式和工具只需進行少量變更或不需變更，即可與 Aurora 搭配使用。

您可以在文件中查看當前 Amazon Aurora 與 PostgreSQL 版本的相容性資訊。

Amazon 全力支援 Aurora PostgreSQL 以及 Aurora 可用的所有擴充功能。如果您需要 Aurora PostgreSQL 的支援，請聯絡 AWS Support。如果您擁有有效的 AWS Premium Support 帳戶，可以聯絡 AWS Premium Support 解決 Aurora 的特定問題。

若要試用 Aurora，請登入 AWS 管理主控台，選取資料庫類別下的 RDS，然後選擇 Amazon Aurora 作為您的資料庫引擎。如需詳細指導和資源，請查看我們的 Aurora 入門頁面。

您可以在此處查看 Aurora 的區域可用性。

如果您想從 MySQL 遷移到 Aurora 或反向遷移，則有幾種選擇：

• 您可以使用標準的 mysqldump 公用程式將資料從 MySQL 中匯出，並用 mysqlimport 公用程式將資料匯入 Aurora，或者反向遷移。
• 您還可以使用 Amazon RDS 的資料庫快照遷移功能，透過 AWS 管理主控台將 Amazon RDS for MySQL 資料庫快照遷移至 Aurora。

雖然持續時間取決於格式和資料集大小，但大多數客戶可以在一小時內完成到 Aurora 的遷移。如需詳細資訊，請參閱將 MySQL 資料庫遷移至 Amazon Aurora 的最佳實務。

如果您想從 PostgreSQL 遷移到 Aurora 或反向遷移，則有幾種選擇：

• 您可以使用標準 pg_dump 公用程式將資料從 PostgreSQL 匯出，以及使用 pg_restore 公用程式將資料匯入 Aurora，或者反向遷移。
• 您還可以使用 RDS 的資料庫快照遷移功能，透過 AWS 管理主控台將 Amazon RDS for PostgreSQL 資料庫快照遷移至 Aurora。

雖然持續時間取決於格式和資料集大小，但大多數客戶可以在一小時內完成到 Aurora 的遷移。

若要將 SQL Server 資料庫遷移至 Amazon Aurora PostgreSQL 相容版本，您可以使用 Babelfish for Aurora PostgreSQL。您的應用程式無需任何變更即可執行。如需詳細資訊，請參閱 Babelfish 文件。

不需要，Aurora 可與標準的 PostgreSQL 資料庫驅動程式搭配使用。

Amazon Aurora 透過將資料庫引擎與為資料庫工作負載建構的 SSD 虛擬化儲存層緊密整合、減少儲存系統的寫入操作、大幅降低鎖定爭用並消除資料庫處理執行緒所產生的延遲，使效能大幅超越 MySQL。

我們使用 SysBench 測試 r3.8xlarge 執行個體的結果顯示，Amazon Aurora 每秒傳送超過 500,000 個 SELECT 和 100,000 個 UPDATE，比在同一硬體上執行同一基準的 MySQL 高出五倍。如需此基準及如何自行複製此基準的詳細說明，請參閱 Amazon Aurora MySQL 相容版本效能基準指南。

Amazon Aurora 透過將資料庫引擎與為資料庫工作負載建構的 SSD 虛擬化儲存層緊密整合、減少儲存系統的寫入操作、大幅降低鎖定爭用並消除資料庫處理執行緒所產生的延遲，使效能大幅超越 PostgreSQL。

我們使用 SysBench 測試 r4.16xlarge 執行個體的結果顯示，Amazon Aurora 每秒傳送的 SELECT 和 UPDATE 比在同一硬體上執行同一基準的 PostgreSQL 高出三倍。如需此基準及如何自行複製此基準的詳細說明，請參閱 Amazon Aurora PostgreSQL 相容版本效能基準指南。

Amazon Aurora 的設計與 MySQL 相容，因此現有 MySQL 應用程式和工具無須修改即可執行。不過，Amazon Aurora 針對 MySQL 加強了一個區域，那就是高度並行工作負載。若要最大化 Amazon Aurora 上的工作負載輸送量，建議您將應用程式建置為可驅動大量並行查詢和交易。

Amazon Aurora 的設計與 PostgreSQL 相容，因此現有的 PostgreSQL 應用程式和工具無須修改即可執行。不過，Amazon Aurora 針對 PostgreSQL 加強了一個區域，那就是高度並行工作負載。若要最大化 Amazon Aurora 上的工作負載輸送量，建議您將應用程式建置為可驅動大量並行查詢和交易。

請參閱 Aurora 定價頁面了解最新的定價資訊。

目前沒有適用於 Aurora 的 AWS 免費方案產品。不過，Aurora 會將您的資料持久儲存在三個可用區域，而且只需支付一份資料副本的費用。您不需要支付高達 100% 資料庫叢集大小的備份費用。在為資料庫叢集設定的備份保留期間，您也無需支付快照費用。

不是，Aurora 複寫的價格已捆綁在定價中。我們將根據資料庫在資料庫層消耗的儲存量向您收費，而非根據在 Aurora 虛擬儲存層消耗的儲存量收費。

I/O 操作由 Aurora 資料庫引擎在其 SSD 虛擬儲存層中執行。每個資料庫頁面讀取操作視為一個輸入/輸出。
Aurora 資料庫引擎發出讀取儲存層請求，以擷取不在快取記憶體中的資料庫頁面：

• 如果您的查詢流量能完全以記憶體或快取滿足，不會因您自記憶體擷取任何資料頁面而收費。
• 如果您的查詢流量無法完全以記憶體滿足，會按照需要自儲存區擷取的資料頁面向您收費。
  每個資料庫頁面在 Amazon Aurora MySQL 相容版本中為 16 KB，在 Aurora PostgreSQL 相容版本中為 8 KB。

Aurora 的設計目的是為了移除不必要的 I/O 操作，以降低成本及確保有足夠的資源可供讀取/寫入流量使用。會消耗寫入 I/O 操作的情形僅限於為使寫入耐久，Aurora MySQL 相容版本中對儲存層的持續重做日誌記錄或 Aurora PostgreSQL 相容版本中對儲存層的預寫日誌記錄。

寫入 I/O 操作以 4KB 為單位計算。例如，1024 位元組的日誌記錄當作一個寫入 I/O 操作計算。然而，如果日誌記錄大於 4KB，需要不只一次寫入 I/O 操作方能持久。

日誌記錄小於 4KB 的並行寫入操作可透過 Aurora 資料庫引擎併在一起，以最佳化 I/O 耗用量。有別於傳統資料庫引擎，Aurora 從不將已變更的資料頁面排清至儲存區。

您可以在 AWS 管理主控台查看 Aurora 執行個體耗用的輸入/輸出請求 數。要了解輸入/輸出的耗用量，前往主控台的 Amazon RDS 區段，查看執行個體清單，選取 Aurora 執行個體，然後在監控區段尋找 "Billed read operations" 和 "Billed write operations" 指標。

如需 I/O 操作定價的詳細資訊，請造訪 Aurora 定價頁面。將資料庫叢集設定為 Aurora 標準組態時，需支付讀取和寫入 I/O 操作的費用。將資料庫叢集設定為 Amazon Aurora I/O 最佳化時，不需支付讀取和寫入 I/O 操作的費用。

Aurora 依據您的價格效能比和價格可預測性需求，讓您在兩種組態選項之間進行選擇，從而提供最佳化資料庫支出的彈性。這兩種組態選項是「Aurora 標準」和「Aurora I/O 最佳化」。這兩種選項都不需要預先佈建 I/O 或儲存，而且兩者都可以擴展 I/O 操作來支援最嚴苛的應用程式。

Aurora 標準是一種資料庫叢集組態，可為絕大多數低至適中 I/O 用量的應用程式提供具成本效益的定價。使用 Aurora 標準，您可以支付資料庫執行個體、儲存和按請求付費 I/O 的費用。

Aurora I/O 最佳化是一種資料庫叢集組態，可為支付處理系統、電子商務系統和財務應用程式等 I/O 密集型應用程式提供改善的價格效能比。此外，如果您的 I/O 支出超過 Aurora 資料庫總支出的 25%，Aurora I/O 最佳化可節省高達 40% 的成本。讀取和寫入 I/O 操作不收取費用，因此 Aurora I/O 最佳化為所有應用程式提供可預測的定價，這使其非常適合具有高 I/O 可變性的工作負載。

當您需要任何應用程式的可預測成本時，Aurora I/O 最佳化是理想的選擇。對於需要高寫入輸送量或執行處理大量資料的分析查詢，I/O 密集型應用程式可提供改善的價格效能比。對於 I/O 支出超過 Aurora 帳單 25% 的客戶，Aurora I/O 最佳化也可節省高達 40% 的成本。

可以使用 AWS 管理主控台提供的一鍵式體驗，將現有資料庫叢集的儲存類型變更為 Aurora I/O 最佳化。也可以叫用 AWS Command Line Interface (AWS CLI) 或 AWS 軟體開發套件來進行此變更。

可以每 30 天將現有的資料庫叢集切換至 Aurora I/O 最佳化一次。您可以隨時切換回 Aurora 標準。

是，Aurora I/O 最佳化適用於現有的 Aurora 預留執行個體。Aurora 會自動說明對於預留執行個體，Aurora 標準和 Aurora I/O 最佳化之間的價格差異。使用 Aurora I/O 最佳化的預留執行個體折扣，您可以節省更多的 I/O 支出。

使用 Aurora I/O 最佳化功能時，回溯、快照、匯出或持續備份的價格不會有任何變更。

是，將繼續收取跨區域複寫資料所需的 I/O 操作費用。Aurora I/O 最佳化不會收取讀取和寫入 I/O 操作的費用，這與資料複寫不同。

最低儲存為 10 GB。根據您的資料庫使用量，您的 Amazon Aurora 儲存將以 10 GB 的增量自動增長到 128 TiB，而不會影響資料庫的效能。無需提前佈建儲存。

有兩種方法可以擴展與我的 Amazon Aurora 資料庫執行個體相關聯的運算資源 – 透過 Aurora Serverless 和透過手動調整。

您可以使用 Aurora Serverless (Amazon Aurora 的隨需自動擴展組態) 根據應用程式需求擴展資料庫運算資源。它可讓您在雲端執行資料庫，而不必擔心資料庫容量管理。您可以指定所需的資料庫容量範圍，並且您的資料庫將根據應用程式的需求進行擴展。詳情請參閱《Aurora Serverless 使用者指南》。

您還可以透過在 AWS 管理主控台中選取所需的資料庫執行個體類型來手動擴展與資料庫關聯的運算資源。您請求的變更將在您指定的維護時段內套用，或者您可以使用 "Apply Immediately" (立即應用) 旗標來立即變更資料庫執行個體類型。

在執行擴展操作期間，這兩個選項將會對可用性造成幾分鐘的影響。請注意，這也會同時套用任何其他待定系統變更。

Amazon Aurora 資料庫執行個體的持續自動備份會一直處於啟用的狀態。備份不會影響資料庫效能。

是，拍攝快照並不影響效能。請注意，從資料庫快照中恢復資料需要建立新的資料庫執行個體。

Amazon Aurora 會在三個可用區域 (AZ) 自動維護六個資料副本，並自動嘗試在運作狀態良好的可用區域內恢復您的資料庫，不會遺失任何資料。在極少數的情況下，無法在 Amazon Aurora 儲存內找到您的資料，您可以從資料庫快照中進行恢復或對新執行個體執行 point-in-time 恢復操作。請注意，時間點還原操作的最近可還原時間最多為 5 分鐘之前。

您可以選擇在刪除資料庫執行個體時建立最終的資料庫快照。如果進行此操作，之後便可以使用此資料庫快照恢復已刪除的資料庫執行個體。刪除資料庫執行個體之後，Amazon Aurora 會保留這個使用者建立的最終資料庫快照與所有其他手動建立的資料庫快照。刪除資料庫執行個體後只會保留資料庫快照 (即，不會保留為 point-in-time 恢復建立的自動備份)。

是。Aurora 讓您能夠建立資料庫的快照，稍後您可用它來恢復資料庫。您可以與不同的 AWS 帳戶共享快照，收件人帳戶的擁有者可以使用您的快照來恢復包含您資料的資料庫。您甚至可以選擇讓快照成為公有，也就是說，任何人都可以恢復包含您 (公有) 資料的資料庫。

您可以使用這個功能，在各個具備不同 AWS 帳戶的環境 (生產、開發/測試、分段等) 之間共享資料，這個功能還能在個別帳戶保護所有資料備份的安全，以因應萬一出現主 AWS 帳戶被盜的情況。

在帳戶間共享快照不需付費。不過，可能需要支付快照本身的費用，以及從共享快照恢復任何資料庫的費用。進一步了解 Aurora 定價。

我們不支援自動共享資料庫快照。若要共享快照，您必須手動建立快照複本，然後共享複本。

您最多可以與 20 個 AWS 帳戶 ID 共享手動快照。如果想要與 20 個以上帳戶共享快照，可將快照當做公有共享，或聯絡支援以提高您的配額。

您可以在提供 Aurora 的各 AWS 區域共享 Aurora 快照。

否。只有與共享快照的帳戶位於同一個區域中的帳戶可以存取共享的 Aurora 快照。

是，您可以共享加密的 Aurora 快照。

Amazon Aurora 會將您的資料庫磁碟區自動分成 10 GB 的區段並分散在多個磁碟上。資料庫磁碟區的每個 10 GB 區塊都能在三個可用區域間以六種方法進行複寫。Amazon Aurora 的設計可完全透明化的處理最多兩個資料副本的損失，而不會影響資料庫寫入可用性；最多三個資料副本的損失，而不會影響資料庫讀取可用性。

Amazon Aurora 儲存還具有自我修復能力。可持續掃描資料區塊和磁碟有無錯誤並自動修復。

與其他資料庫不同的是，Amazon Aurora 在資料庫損毀之後不需重新執行最後一個資料庫檢查點 (通常為 5 分鐘) 的重做日誌，且不需要在資料庫運作之前確認已套用所有變更。在大多數情況下，這可將資料庫的重新啟動時間降低到 60 秒以下。

Amazon Aurora 將緩衝區快取從資料庫處理程序中移出，以便在重新啟動時立即使用。如此一來，您就不需要在重新匯入快取時限制存取，以避免發生暫時低壓。

Amazon Aurora MySQL 相容版本和 Amazon Aurora PostgreSQL 相容版本都支援 Amazon Aurora 複本，該複本與相同 AWS 區域中的主執行個體共享同一個基礎磁碟區。所有 Amazon Aurora 複本都可看見主執行個體做出的更新。

透過 Amazon Aurora MySQL 相容版本，您還可以根據 MySQL 的 binlog 複寫引擎建立跨區域 MySQL 僅供讀取複本。在 MySQL 僅供讀取複本中，主執行個體的資料會作為交易在您的複本上重新執行。對於大多數使用案例，包括讀取擴展和高可用性，我們建議使用 Amazon Aurora 複本。

您可以根據應用程式需求，靈活搭配這兩種複本類型：

除了上面列出的選項之外，還有另外兩個複寫選項。您可以使用 Amazon 全球資料庫，在不同區域的 Aurora 叢集之間進行更快的實體複寫。對於 Aurora 和非 Aurora MySQL 相容版本資料庫之間的複寫 (甚至在 AWS 之外)，您可以設定自己的自我管理 binlog 複寫。

是，您可以透過實體複寫或邏輯複寫來設定跨區域 Aurora 複本。實體複寫 (稱為 Amazon Aurora Global Database) 使用專用基礎設施，讓資料庫充分為您的應用程式提供服務，而且複寫到最多五個次要區域通常延遲時間不到一秒。它適用於 Aurora MySQL 相容版本和 Aurora PostgreSQL 相容版本。

針對低延遲全球讀取和災難復原，我們建議使用 Amazon Aurora Global Database。
Aurora 支援在各資料庫引擎進行原生邏輯複寫 (MySQL 和 PostgreSQL 的 binlog，以及 PostgreSQL 的複寫位置)，您可以複寫至 Aurora 和非 Aurora 資料庫，甚至跨區域複寫。

Aurora MySQL 相容版本也提供易於使用的邏輯跨區域讀取複本功能，支援最多五個次要 AWS 區域。其以單一緒行緒的 MySQL binlog 複寫為基礎，因此複寫延遲會受到特定所選區域之間網路通訊中的變更/套用速率和延遲的影響。

是，您可以在每一個跨區域叢集最多新增 15 個 Aurora 複本，這些複本會與跨區域複本共用相同的基礎儲存。跨區域複本做為叢集的主複本，而叢集上的 Aurora 複本一般會比主複本延遲數十毫秒。

是，您可以從 Amazon RDS 主控台將跨區域複本提升成新的主複本。至於邏輯 (binlog) 複寫，提升程序一般需要幾分鐘，取決於您的工作負載。一旦啟動提升程序，跨區域複寫將會停止。

利用 Amazon Aurora 全球資料庫，您可以在一分鐘內提升次要區域，以取得完整的讀/寫工作負載。

是。您可以在叢集中對每個執行個體指派提升優先順序方案。在主執行個體失敗時，Amazon RDS 會將具有最高優先順序的複本提升成主要執行個體。如果兩個或多個 Aurora 複本共享相同的優先級，則 Amazon RDS 會升級最大的複本。如果兩個或多個 Aurora 複本共享相同的優先級和大小，則 Amazon RDS 會在同一促銷方案中推廣任意複本。

如需容錯移轉邏輯的詳細資訊，請閱讀 Amazon Aurora 使用者指南。

是，您可以隨時修改執行個體的優先順序方案。只修改優先順序方案不會觸發容錯移轉。

您可以指派較低優先順序的方案給不想提升成主執行個體的複本。然而，如果叢集上較高優先順序複本出於某些原因而運作狀況不佳或無法使用，則 Amazon RDS 會提升較低優先順序的複本。

您可以新增 Amazon Aurora 複本。同一個 AWS 區域中的 Aurora 複本會與主執行個體共用相同的基礎儲存。任何 Aurora 複本都可在不損失任何資料的情況下提升為主執行個體，因此，可用於在主要資料庫執行個體故障時提高容錯能力。

若要提高資料庫可用性，只需在 3 個可用區域中的任何一個建立 1 到 15 個複本，Amazon RDS 將在發生資料庫執行中斷時將其納入容錯移轉主選擇中。如果希望資料庫跨越多個 AWS 區域，則可以使用 Amazon Aurora Global Database。這會複寫您的資料且不會影響資料庫效能，並從全區域故障提供災難復原。

Amazon Aurora 會自動處理容錯移轉，所以您的應用程式可以儘快恢復資料庫操作，而無須人為管理介入。

• 如果您在相同或不同可用區域中有一個 Aurora 複本，當容錯移轉時，Aurora 會翻轉資料庫執行個體的正規名稱記錄 (CNAME) 以指向執行狀態正常的複本，該複本會提升成新的主複本。容錯移轉從開始到結束通常可在 30 秒內完成。為改善彈性和更快進行容錯移轉，請考慮使用 Amazon RDS Proxy，該服務會自動連線至容錯移轉資料庫執行個體，同時保留應用程式連線。Proxy 可讓容錯移轉對您的應用程式而言是透明的，並減少多達 66% 的容錯移轉時間。
• 如果您執行的是 Aurora Serverless v1，且資料庫執行個體或可用區域無法使用，Aurora 會自動在不同的可用區域中重新建立資料庫執行個體。Aurora Serverless v2 的運作方式，與佈建的容錯移轉和其他高可用性功能相似。如需詳細資訊，請參閱 Aurora Serverless v2 和高可用性。 
• 如果您沒有 Aurora 複本 (即單一執行個體) 且未執行 Aurora Serverless，Aurora 會嘗試在與原始執行個體相同的可用區域中建立新的資料庫執行個體。已盡力進行這種原始執行個體的取代操作，但可能不成功，例如，在出現會廣泛影響可用區域的問題時。
  

您的應用程式應在連線中斷時重試資料庫連線。跨區域災難復原是一個手動程序，您可以在此提升次要區域，以取得讀/寫工作負載。

Amazon Aurora 會自動偵測主執行個體的問題並觸發容錯移轉。如果您使用的是叢集端點，您的讀取/寫入連線會自動重新導向至將提升成主執行個體的 Amazon Aurora 複本。

此外，Aurora 複本提供的讀取流量將短暫中斷。如果您使用叢集讀取者端點將讀取流量導向至 Aurora 複本，會將唯讀連線導向至新提升的 Aurora 複本，直至將舊的主節點復原為複本。

由於 Amazon Aurora 複本與相同 AWS 區域中的主執行個體共享同一個資料磁碟區，因此幾乎不會有複寫延遲的情況。據我們觀察，延遲時間一般為數十毫秒。

對於跨區域複寫，以二進位日誌為基礎的邏輯複寫延遲會因變更/應用率以及網路通訊而無限制延長延遲時間。然而，在一般條件下，一分鐘以內的複寫延遲很常見。使用 Amazon Aurora 全球資料庫實體複寫的跨區域複本，其一般延遲在一秒內。

是，您可以在 Aurora MySQL 相容版本執行個體和外部 MySQL 資料庫之間設定 binlog 複寫。另一個資料庫可以在 Amazon RDS 上執行，也可以作為 AWS 上的自我管理資料庫執行，也可以完全在 AWS 之外執行。

如果您正在執行 Aurora MySQL 相容版本 5.7，請考慮設定以 GTID 為基礎的 binlog 複寫。這將提供完整的一致性，因此即使在容錯移轉或停機後，您的複寫也不會錯過交易或產生衝突。

Amazon Aurora 全球資料庫是一項功能，可讓單一 Amazon Aurora 資料庫跨越多個 AWS 區域。它會複寫您的資料且不會影響資料庫效能，讓每個區域都有不到一秒一般延遲的快速本機讀取，並從全區域故障提供災難復原。在極少見的區域性降低或故障情況下，可以在不到 1 分鐘的時間內提升次要區域，使其能夠完整讀取/寫入。此功能適用於 Aurora MySQL 相容版本和 Aurora PostgreSQL 相容版本。

只要在 Amazon RDS 主控台按幾下，就能建立 Aurora 全球資料庫。或者，您可以使用 AWS 軟體開發套件 (SDK) 或 AWS Command-Line Interface (CLI)。您需要在 Amazon Aurora 全球資料庫中，為每個區域至少佈建一個執行個體。

您最多可以為 Amazon Aurora 全球資料庫建立五個二級區域。

是。如果您的目標是分析資料庫活動，請考慮改用 Aurora 進階稽核、一般日誌和慢速查詢日誌，以避免影響資料庫的效能。

否。如果您的主區域不可用，可以從 Amazon Aurora 全球資料庫手動移除次要區域，並提升該區域以取得完整讀取和寫入功能。您也需要將應用程式指向新提升的區域。

是，所有 Amazon Aurora 資料庫執行個體都必須在 VPC 中建立。透過 Amazon VPC，您可以定義一個與自己資料中心內執行的傳統網路非常相似的虛擬網路拓撲。這樣一來，您可以完全控制存取您的 Amazon Aurora 資料庫的人員。

是。Amazon Aurora 使用 SSL (AES-256) 保護資料庫執行個體和應用程式之間的連線安全。Amazon Aurora 可讓您使用透過 AWS Key Management Service (AWS KMS) 管理的金鑰加密資料庫。

在以 Amazon Aurora 加密執行的資料庫執行個體上，於基礎儲存中存放的靜態資料，以及其在同一個叢集中的自動備份、快照和複本都會加密。加密和解密的處理完全無縫。如需以 Amazon Aurora 使用 AWS KMS 的詳細資訊，請參閱 Amazon RDS 使用者指南。

目前不支援加密現有未加密的 Aurora 執行個體。若要在現有未加密的資料庫使用 Amazon Aurora 加密，請建立已啟用加密的新資料庫執行個體，再將資料移轉至其中。

您必須透過建立資料庫時輸入的資料庫連接埠存取 Aurora 資料庫。這可為您的資料安全性提供多一層保護。如需連線至 Amazon Aurora 資料庫的逐步說明，請參閱 Amazon Aurora Connectivity 指南。

是的，Aurora 的 MySQL 和 PostgreSQL 相容版本均符合 HIPAA 規範。您可以使用它們建立符合 HIPAA 規範的應用程式及存放醫療保健相關資訊，包括與 AWS 共同履行的商業夥伴合約 (BAA) 下的受保護醫療資訊 (PHI)。如果您已經和 AWS 簽訂 BAA，則您不需要執行進一步動作，就能透過 BAA 涵蓋的帳戶開始使用這些服務。如需有關使用 AWS 建置合規應用程式的詳細資訊，請參閱醫療保健供應商。

您目前可以在以下網頁找到 CVE 清單：Amazon Aurora 安全性更新。

Aurora 與 Amazon GuardDuty 整合，可協助您識別在 Aurora 資料庫中的資料所面臨的潛在威脅。「GuardDuty RDS 防護」可分析並監控您帳號中的登入活動和新設資料庫，並使用量身訂製的 ML 模型偵測 Aurora 資料庫中可疑的登入活動。如需詳細資訊，請參閱透過 GuardDuty RDS 防護監控威脅及 GuardDuty RDS 防護使用者指南。

Aurora Serverless 是 Amazon Aurora 的隨需、自動調整規模組態。 藉助 Aurora Serverless，您可以在雲端中執行資料庫，而無需管理資料庫容量。手動管理資料庫容量可能非常耗時，而且會導致資料庫資源的使用效率不佳。使用 Aurora Serverless，您可以建立資料庫、指定所需的資料庫容量範圍，然後連接應用程式。Aurora 會根據您的應用程式需求在指定的範圍內自動調整容量。

資料庫處於作用中狀態時使用的資料庫容量需按秒付費。進一步了解 Aurora Serverless，在 Amazon RDS 管理主控台中執行幾個步驟即可開始使用。

從開發、測試環境、網站和工作負載，以及具有不頻繁、間歇或不可預測工作負載的應用程式，到需要高度擴展、高可用性的要求最嚴苛的業務關鍵型應用程式，Aurora Serverless v2 支援各種類型的資料庫工作負載。它透過新增更多 CPU 和記憶體來進行適當擴展，而無需將資料庫容錯移轉至更大或更小的資料庫執行個體。因此，即使存在長時間執行的交易、資料表鎖定等，它也可以擴展。

此外，它還能以低至 0.5 個 Aurora 容量單位 (ACU) 的增量擴展資料庫容量，因此您的資料庫容量接近符合您的應用程式需求。

Aurora Serverless v1 為不頻繁、間歇或不可預測的工作負載提供了一種簡便、經濟高效的選擇。它會自動啟動、擴展運算容量以符合您的應用程式的用量，並在不使用時關閉。請瀏覽《Aurora 使用者指南》以進一步了解相關資訊。

Aurora Serverless v2 支援已佈建 Aurora 的所有功能，包括僅供讀取複本、異地同步備份組態、Aurora 全球資料庫、RDS Proxy 和 Performance Insights。

是，您可以開始使用 Aurora Serverless v2 來管理現有 Aurora 資料庫叢集中的資料庫運算容量。同時包含佈建執行個體和 Aurora Serverless v2 的叢集稱為混合組態叢集。您可以選擇在叢集中使用佈建的執行個體和 Aurora Serverless v2 的任何組合。

若要測試 Aurora Serverless v2，請將讀取器新增至 Aurora 資料庫叢集並選取 Serverless v2 作為執行個體類型。一旦讀取器建立並可用，您就可以開始將其用於唯讀工作負載。確認讀取器如預期般工作後，您可以啟動容錯移轉以開始使用 Aurora Serverless v2 進行讀取和寫入。此選項提供了最短停機時間體驗以開始使用 Aurora Serverless v2。

是，您可以從 Aurora Serverless v1 遷移至 Aurora Serverless v2。請參閱《Aurora 使用者指南》以進一步了解相關資訊。

可在此處查看 Aurora Serverless v1 相容性資訊。可以在此處查看 Aurora Serverless v2 相容性資訊。

是，您可以從現有 Aurora 佈建置群集取得的快照，還原到 Aurora Serverless 資料庫叢集 (反之亦然)。

您可以從同一個 VPC 中執行的用戶端應用程式存取 Aurora Serverless 資料庫叢集。您無法為 Aurora Serverless 資料庫提供公有 IP 地址。

雖然 Aurora Serverless 會根據有效的資料庫工作負載而自動擴展，但在某些情況下，容量可能無法快速擴展以滿足突然的工作負載變化，例如大量新事務。在這些情況下，您可以使用 AWS 管理主控台、AWS CLI 或 Amazon RDS API，將容量明確設定為特定的值。

啟動擴展操作後，Aurora Serverless 會嘗試尋找擴展點，該擴展點是資料庫可以安全地完成擴展的時間點。如果您正在進行長時間執行的查詢或事務，或者正在使用臨時表格或表格鎖定，則 Aurora Serverless 可能無法找到擴展點。

在 Aurora Serverless 中，資料庫容量是以 ACU 計算。按每秒 ACU 用量的固定費率付費。在 Aurora Serverless 上執行工作負載的運算成本將取決於您選擇的資料庫叢集組態：Aurora 標準或 Aurora I/O 最佳化。如需有關定價和區域可用性的資訊，請造訪 Aurora 定價頁面。

Amazon Aurora 平行查詢是指將單一查詢運算負載下推並分散到 Aurora 儲存層中數千個 CPU 的能力。不使用平行查詢，針對 Amazon Aurora 資料庫發出的查詢將完全在資料庫叢集的一個執行個體內執行；這與大多數資料庫操作的方式類似。

平行查詢非常適合需要新資料和絕佳查詢效能的分析工作負載使用，即使在大型表格也很適用。這種類型的工作負載本質上通常是可操作的。

平行查詢可帶來更快速的效能，將分析查詢的速度最高提升兩個數量級。還可帶來操作簡便性並持續取得最新的資料，因為您可以在 Aurora 叢集直接對目前的交易資料發出查詢。此外，平行查詢還支援相同資料庫上的交易和分析工作負載，讓 Aurora 在執行並行分析查詢的同時，維持高交易輸送量。

尚未在緩衝集區的大部分大型資料集查詢都可受益於這項功能。平行查詢的最初版本可下推和擴展超過 200 個 SQL 函數、對等連結和投影的處理。

特定查詢的效能提升取決於可將多少的查詢計畫下推到 Aurora 儲存層。客戶已回報超過 1 個數量級的查詢延遲提升。

是，不過我們預期這種情況很少出現。

不需要變更查詢語法。查詢最佳化工具會自動決定是否對特定查詢使用平行查詢。若要檢查查詢是否使用平行查詢，可以執行 EXPLAIN 命令以查看查詢執行計畫。如果您希望略過啟發法並強制執行平行查詢以做測試之用，可使用 aurora_pq_force 工作階段變數。

您可以使用 aurora_pq 參數在全域和工作階段層級動態啟用和停用平行查詢。

否。除了您已支付的執行個體、輸入/輸出和儲存費用之外，無須支付其他費用。

否，查詢的平行查詢 IO 費用在儲存層進行計費，開啟平行查詢功能會產生相同或更高的費用。您所獲得的好處是查詢效能方面的提升。

使用平行查詢可能會產生更高輸入/輸出費用的原因有兩個。第一，即使表格中的部分資料位於緩衝集區，平行查詢還是需要在儲存層掃描所有資料，因此產生更多輸入/輸出。第二，避免緩衝集區發生爭用的副作用，也就是執行平行查詢無法為緩衝集區暖機。因此，連續執行相同的平行查詢會產生大量的輸入/輸出費用。

若要進一步了解平行查詢，請參閱文件。

否。目前，您可以將平行查詢與 R* 執行個體系列中的執行個體搭配使用。

一開始不行。目前，您只能在不是執行無伺服器或恢復功能的資料庫叢集開啟此功能。此外，它不支援與 MySQL 5.7 相容之 Aurora 的專屬功能。

否。雖然我們預期在大多數的情況下平行查詢可改善查詢延遲，但這可能會產生較高的輸入/輸出成本。建議您在啟用和停用該功能的情況下徹底進行工作負載測試。一旦決定平行查詢是正確的選擇，即可仰賴查詢最佳化工具來自動決定哪些查詢要使用平行查詢。當最佳化工具無法做出最佳的決定時，這種情況很少發生，您可以覆寫該設定。

Aurora 平行查詢不是資料倉儲，無法提供這類產品特有的功能。此功能的設計旨在加速關聯式資料庫的查詢效能，適用於操作分析等使用案例，以及當您需要對資料庫的新資料執行快速的分析查詢時。

對於 EB 級雲端資料倉儲，請考慮 Amazon Redshift。

Amazon DevOps Guru for RDS 是 Amazon RDS (包含 Amazon Aurora) 的一項採用 ML 技術的新功能，旨在自動偵測和診斷資料庫效能和操作問題，讓您能夠在幾分鐘而不是幾天內解決問題。

Amazon DevOps Guru for RDS 是 Amazon DevOps Guru 的一項功能，旨在偵測所有 Amazon RDS 引擎和數十種其他資源類型的操作和效能問題。DevOps Guru for RDS 擴展了 DevOps Guru 的功能，以偵測、診斷和修復 Amazon RDS 中與資料庫相關的各種問題 (例如資源過度使用和某些 SQL 查詢的不當行為)。

當出現問題時，Amazon DevOps Guru for RDS 可立即通知開發人員和 DevOps 工程師，並提供診斷資訊、問題程度的詳細資訊和智慧修復建議，以協助客戶快速解決與資料庫相關的效能瓶頸和操作問題。

Amazon DevOps Guru for RDS 旨在消除手動工作，並縮短偵測和解決關聯式資料庫工作負載中難以發現的效能瓶頸的時間 (從幾小時和數天縮短到幾分鐘)。

您可以為每個 Amazon Aurora 資料庫啟用 DevOps Guru for RDS，它會自動偵測工作負載的效能問題，就每個問題向您傳送提醒，解釋問題清單並推薦解決措施。
DevOps Guru for RDS 讓非專家更容易進行資料庫管理，並協助資料庫專家管理更多資料庫。

Amazon DevOps Guru for RDS 使用 ML 來分析由 Amazon RDS 績效詳情 (PI) 收集的遙測資料。DevOps Guru for RDS 不會在其分析中使用您存放在資料庫中的任何資料。PI 測量資料庫負載，該指標可表徵應用程式如何在資料庫中花費時間，以及資料庫產生的選定指標，例如 MySQL 中的伺服器狀態變數和 PostgreSQL 中的 pg_stat 表。

若要開始使用 DevOps Guru for RDS，請確保透過 RDS 主控台啟用績效詳情，然後只需為您的 Amazon Aurora 資料庫啟用 DevOps Guru。使用 DevOps Guru，您可以選擇分析覆蓋範圍作為整個 AWS 帳戶，指定您希望 DevOps Guru 分析的特定 AWS CloudFormation 堆疊，或使用 AWS 標籤建立您希望 DevOps Guru 分析的資源分組。

Amazon DevOps Guru for RDS 有助於識別可能影響應用程式服務品質的各種效能問題，例如鎖定堆積、連線風暴、SQL 迴歸、CPU 和輸入/輸出爭用以及記憶體問題。

Amazon RDS 績效詳情是一項資料庫效能調校和監控功能，可收集和視覺化 Amazon RDS 資料庫效能指標，協助您快速評估資料庫負載，並確定何時何地採取行動。Amazon DevOps Guru for RDS 旨在監控這些指標，偵測您的資料庫何時遇到效能問題，分析指標，然後告訴您發生什麼問題，以及您可以採取什麼措施。

Amazon RDS 藍/綠部署可用於 Amazon Aurora MySQL 相容版本 5.6。請參閱 Aurora 文件，進一步了解可用的版本。

Amazon RDS 藍/綠部署支援全部 AWS 區域（AWS 中國區域除外）和 AWS GovCloud 區域。

在綠色或藍色執行個體上執行您的工作負載所產生的成本相同。在藍色和綠色執行個體上執行工作負載的成本包括，我們的資料庫執行個體的現行標準定價、儲存成本、讀取/寫入 I/O 的成本，以及任何已啟用功能的成本，如備份和 Amazon RDS Performance Insights 的成本。 實際上，在藍/綠部署的使用壽命內，您要支付的費用大約是在資料庫執行個體上執行工作負載成本的 2 倍。

例如，您有 Aurora MySQL 相容版本 5.7 叢集在兩個 r5.2xlarge 資料庫執行個體 (一個主要寫入器執行個體和一個讀取器執行個體) 上執行，它們位於 us-east-1 AWS 區域。每個 r5.2xlarge 資料庫執行個體都設定有 40 GiB 儲存體，每月執行 2,500 萬次 I/O。您要使用 Amazon RDS 藍/綠部署建立藍色執行個體拓撲的複製項目，執行它 15 天 (360 小時)，而每個綠色執行個體在該期間執行 300 萬次 I/O 讀取。然後，您要在成功切換後刪除藍色執行個體。藍色執行個體 (寫入器和讀取器) 的隨需價格為每小時 1.179 美元 (執行個體 + 儲存 + I/O)，所以 15 天的成本為 849.2 美元。綠色執行個體 (寫入器和讀取器) 的隨需價格為每小時 1.167 美元 (執行個體 + 儲存 + I/O)，所以 15 天的成本為 840.40 美元。這 15 天使用藍/綠部署的總成本為 1689.60 美元，是在該期間執行藍色執行個體所產生成本的大約 2 倍。

Amazon RDS 藍/綠部署讓您可以更安全、更輕鬆，並且更快速地執行資料庫變更，例如，主要或次要版本升級、結構變更、執行個體擴展、引擎參數變更和維護更新等。

在 Amazon RDS 藍/綠部署中，藍色環境是您目前的生產環境。綠色環境是您的模擬環境，它將在切換後成為您的新生產環境。

當 Amazon RDS 藍/綠部署啟動切換後，它會同時阻止寫入到藍色和綠色環境，直至切換完成為止。 在切換期間，模擬環境或綠色環境會追趕生產系統，確保模擬環境與生產環境的資料保持一致。生產和模擬環境完成同步後，藍/綠部署會將流量重新引導至新升級的生產環境，使模擬環境成為新的生產環境。Amazon RDS 藍/綠部署的設計允許切換完成後在綠色環境上執行寫入，從而確保切換流程中不會遺失任何資料。

Amazon RDS 藍/綠部署不會刪除您的舊生產環境。如果需要，您可以對它進行存取，以執行額外的驗證和效能/迴歸測試。若不再需要舊生產環境，您可以將其刪除。標準帳單費用包含您將舊生產執行個體刪除為止前的費用。

Amazon RDS 藍/綠部署的切換防護機制會在切換前阻止寫入您的藍色和綠色環境，直至您的綠色環境追趕上進度為止。藍/綠部署還會對您的藍色和綠色環境中的主要和複本執行運作狀態檢查。它還會執行複寫運作狀態檢查。例如，確定複寫是否已停止或是否有錯誤。它們會偵測藍色和綠色環境之間的長時間執行事項。您可以指定最長的容許停機時間，最短為 30 秒，而且當您的持續異動超出此值，切換將會超時。

沒有，Amazon RDS 藍/綠部署不支援 Amazon Aurora 全球資料庫嗎。

不可以，您暫時無法使用 Amazon RDS 藍/綠部署來轉返變更。