一般

什麼是 Amazon Aurora?

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

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

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

Amazon Aurora 與 MySQL 是否相容?

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

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

Amazon Aurora 與 PostgreSQL 是否相容?

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?

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

Aurora 可在哪些 AWS 區域使用?

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

如何從 MySQL 遷移至 Aurora?又如何從 Aurora 遷移至 MySQL?

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

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

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

如何從 PostgreSQL 遷移至 Aurora?又如何從 Aurora 遷移至 PostgreSQL?

如果您想從 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 文件

是否需要變更用戶端驅動程式以使用 Amazon Aurora PostgreSQL 相容版本?

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

效能

「MySQL 的五倍效能」是什麼意思?

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

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

「PostgreSQL 的三倍效能」是什麼意思?

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

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

如何最佳化我的 Amazon Aurora MySQL 相容版本資料庫工作負載?

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

如何最佳化我的 Amazon Aurora PostgreSQL 相容版本資料庫工作負載?

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

計費

Aurora 的費用是多少?

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

Aurora 是否包含在 AWS 免費方案內?

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

Aurora 會跨三個可用區域複寫我的資料。這是否表示我的有效儲存價格將是定價頁面上所顯示價格的三倍?

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

Aurora 中的 I/O 操作是什麼?如何計算?

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 執行個體,然後在監控區段尋找 “VolumeReadIOPs” 和 “VolumeWriteIOPs” 指標。

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

什麼是 Aurora 標準和 Aurora 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 密集型工作負載成本。讀取和寫入 I/O 操作不收取費用,因此 Aurora I/O 最佳化為所有應用程式提供可預測的定價,這使其非常適合具有高 I/O 可變性的工作負載。

何時應該使用 Aurora I/O 最佳化?

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

如何遷移現有的資料庫叢集以使用 Aurora I/O 最佳化?

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

我可以在「Aurora 標準」和「Aurora I/O 最佳化」之間來回切換嗎?

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

Aurora I/O 最佳化是否適用於預留執行個體?

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

使用 Aurora I/O 最佳化功能時,回溯、快照、匯出或持續備份的價格是否會變更?

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

對於使用 Aurora I/O 最佳化的 Aurora 全球資料庫,是否要繼續支付跨區域複製資料所需的 I/O 操作費用?

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

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 的成本是多少?

除了以 Intel 為基礎的 R6id 執行個體和以 Graviton 為基礎的 R6gd 執行個體的價格外,適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 不會收取額外費用。如需詳細資訊,請瀏覽 Aurora 定價頁面

硬體和擴展

Amazon Aurora 資料庫的最低儲存限制和最高儲存限制分別為何?

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

如何擴展與 Amazon Aurora 資料庫執行個體關的運算資源?

有兩種方法可以擴展與我的 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 恢復建立的自動備份)。

是否可和另一個 AWS 帳戶共享快照?

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

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

共享快照是否會計費?

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

是否可以自動共享快照?

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

可以與幾個帳戶共享快照?

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

可以在哪些區域共享 Aurora 快照?

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

是否可以在不同區域間共享 Aurora 快照?

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

是否可以共享加密的 Aurora 快照?

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

高可用性和複寫

Amazon Aurora 如何提高資料庫對磁碟故障的容錯能力?

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

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

Aurora 如何改善資料庫損毀後的恢復時間?

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

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

Aurora 支援哪些類型的複本?

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

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

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

功能 Amazon Aurora 複本
MySQL 複本
複本數量 最多 15 個 最多 5 個
複寫類型 非同步 (毫秒) 非同步 (秒)
對主執行個體的效能影響
複本位置 區域內
跨區域
作為容錯移轉目標 是 (無資料損失) 是 (可能有幾分鐘的資料損失)
自動容錯移轉
支援使用者定義的複寫延遲
支援與主執行個體不同的資料或結構描述

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

Amazon Aurora 是否提供跨區域複本?

是,您可以透過實體複寫或邏輯複寫來設定跨區域 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 複寫為基礎,因此複寫延遲會受到特定所選區域之間網路通訊中的變更/套用速率和延遲的影響。

是否可以在跨區域複本叢集上建立 Aurora 複本?

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

是否可將應用程式從目前的主複本容錯移轉到跨區域複本?

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

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

是否可以選擇特定複本而不是其他複本來做為優先容錯移轉目標?

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

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

執行個體的優先順序方案建立之後是否可以修改?

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

是否可以避免特定複本提升成主執行個體?

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

如何提升單一 Amazon Aurora 資料庫的可用性?

您可以新增 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 會自動偵測主執行個體的問題並觸發容錯移轉。如果您使用的是叢集端點,您的讀取/寫入連線會自動重新導向至將提升成主執行個體的 Amazon Aurora 複本。

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

我的複本會落後主執行個體多久?

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

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

是否可以在我的 Aurora MySQL 相容版本資料庫和外部 MySQL 資料庫之間設定複寫?

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

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

什麼是 Amazon Aurora 全球資料庫?

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

如何建立 Amazon Aurora 全球資料庫?

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

Amazon Aurora 全球資料庫可以有多少個二級區域?

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

如果我使用 Amazon Aurora 全球資料庫,是否也可以在主要資料庫上使用邏輯複寫 (binlog)?

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

Aurora 是否會自動容錯轉移到 Amazon Aurora 全球資料庫的次要區域?

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

安全性

我是否可以在 Amazon Virtual Private Cloud (Amazon VPC) 使用 Amazon Aurora?

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

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 加密,請建立已啟用加密的新資料庫執行個體,再將資料移轉至其中。

如何存取我的 Amazon Aurora 資料庫?

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

Amazon Aurora 是否可搭配需要 HIPAA 合規的應用程式使用?

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

我要到哪裡才能存取「常見漏洞和入侵程式」(CVE) 項目,以查看眾所已知的 Amazon Aurora 版本網路安全漏洞?

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

我可以偵測到針對我的 Aurora 資料庫的安全威脅嗎?

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

無伺服器

什麼是 Amazon Aurora Serverless?

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

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

Aurora Serverless v2 與 v1 之間有何差異?

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

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

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

Aurora Serverless v2 支援哪些 Aurora 功能?

我是否可以開始將 Aurora Serverless v2 與現有 Aurora 資料庫叢集中的佈建執行個體搭配使用?

是,您可以開始使用 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 Serverless v1 遷移至 Aurora Serverless v2。請參閱《Aurora 使用者指南》以進一步了解相關資訊。

Aurora Serverless 支援哪些版本的 Amazon Aurora?

是否可以將現有的 Aurora 資料庫叢集遷移至 Aurora Serverless?

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

如何連接到 Aurora Serverless 資料庫叢集?

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

我可以明確設定 Aurora Serverless 叢集的容量?

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

為什麼我的 Aurora Serverless 資料庫叢集無法自動擴展?

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

Aurora Serverless 如何計費?

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

平行查詢

什麼是 Amazon Aurora 平行查詢?

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

有哪些目標使用案例?

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

平行查詢提供哪些好處?

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

平行查詢可增強哪些特定的查詢?

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

我可以預期哪些效能提升?

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

效能是否有可能變慢?

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

若要利用平行查詢,必須對查詢進行哪些變更?

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

如何開啟或關閉平行查詢功能?

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

使用平行查詢是否需支付其他費用?

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

由於平行查詢會降低輸入/輸出,開啟該功能是否可降低 Aurora IO 費用?

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

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

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

所有執行個體類型是否都能使用平行查詢?

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

哪些 Amazon Aurora 版本支援平行查詢?

平行查詢適用於與 MySQL 5.7 和 MySQL 8.0 相容的 Amazon Aurora 版本。

平行查詢是否與所有其他 Aurora 功能相容?

平行查詢與 Aurora Serverless v2 和回溯相容。

如果平行查詢可以加速查詢,且只會在極少數的情況下發生效能損失,我是否應該全天候開啟此功能?

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

Aurora 平行查詢是否可取代資料倉儲?

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

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

Optimized Reads

什麼是適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads?

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 是一項全新的衡量價格效能比的選項,相較於沒有執行個體,可改善高達 8 倍的查詢延遲,並節省高達 30% 的成本。這項功能非常適合具有大型資料集,且超過資料庫執行個體的記憶體容量的應用程式。

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 如何改善查詢效能?

Amazon Aurora Optimized Reads 執行個體使用以 NVMe 為基礎的本機 SSD 區塊層級儲存 (可用於以 Graviton 為基礎的 r6gd 和 Intel r6id 執行個體),以改善資料集超過資料庫執行個體記憶體容量的應用程式的查詢延遲。Optimized Reads 包括效能增強功能,例如分層快取和臨時物件。

分層快取可改善高達 8 倍的查詢延遲,並節省高達 30% 的成本,適用於高讀取量、I/O 密集型應用程式,例如操作儀表板、異常偵測,以及以向量為基礎的相似性搜尋。快取資料可自動從記憶體資料庫緩衝區快取移至本機儲存,以加快該資料的後續存取速度,進而實現這些優勢。分層快取僅適用於搭載 Aurora I/O 優化組態的 Amazon Aurora PostgreSQL 版本。

臨時物件可將 Aurora PostgreSQL 產生的臨時資料表置於本機儲存,藉此改善涉及排序、雜湊彙總、高負載聯結和其他資料密集型操作的查詢效能,以實現更快的查詢處理。

何時應使用適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads?

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 為客戶 (使用延遲敏感應用程式和大型工作集) 提供令人驚歎的價格效能替代方案,以滿足他們的業務 SLA,並使用其執行個體進行更多操作。

哪些資料庫執行個體類型支援適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads? 在哪些區域可以使用?

Amazon Aurora Optimized Reads 適用於以 Intel 為基礎的 R6id 執行個體和以 Graviton 為基礎的 R6gd 執行個體。您可以在此處查看 Aurora 的區域可用性。

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 支援哪些 Amazon Aurora 引擎版本?

Amazon Aurora Optimized Reads 適用於 R6id 和 R6gd 執行個體上的 Aurora 的 PostgreSQL 相容版本。在 Aurora PostgreSQL 上支援的引擎版本為 15.4 以上版本及 14.9 以上版本。

是否可以搭配 Aurora Serverless v2 使用適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads?

Amazon Aurora Optimized Reads 不適用於 Aurora Serverless v2 (ASv2)。

是否可以搭配 Aurora 標準 Aurora I/O 優化組態使用適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads?

是,Amazon Aurora Optimized Reads 適用於這兩種組態。使用這兩種組態時,啟用 Optimized Reads 的執行個體會自動將臨時資料表映射至以 NVMe 為基礎的本機儲存,以改善分析查詢和索引重建的效能。

若是高讀取量 I/O 密集型工作負載,Aurora PostgreSQL 上啟用 Optimized Reads 的執行個體會設定為使用 Aurora I/O 優化,自動將快取資料從記憶體移至以 NVMe 為基礎的本機儲存,以改善高達 8 倍的查詢延遲,並節省高達 30% 的成本,這適用於所用大型資料集超過資料庫執行個體記憶體容量的應用程式。

如何開始使用適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads?

客戶可透過 AWS 管理主控台、CLI 和 SDK 開始使用 Amazon Aurora Optimized Reads。依預設,所有 R6id 和 R6gd 執行個體都可使用 Optimized Reads。若要使用此功能,客戶只需修改現有的 Aurora 資料庫叢集,以包括 R6id 和 R6gd 執行個體,或使用這些執行個體來建立新的資料庫叢集。請參閱 Amazon Aurora Optimized Reads 文件以開始使用。

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 可用的本機儲存有多少?

R6id 和 R6gd 執行個體上約 90% 的可用本機儲存可用於 Optimized Reads,Aurora 保留 10% 的 NVMe 儲存,以減少 SSD 寫入放大的影響。可用儲存的配置取決於啟用哪些 Optimized Reads 功能。

若同時搭配臨時物件和分層快取功能使用 Optimized Reads,本機儲存中臨時物件的可用空間相當於這些資料庫執行個體上可用記憶體大小的兩倍。這與 Aurora PostgreSQL 上的臨時物件儲存的目前大小相符。剩餘的本機儲存磁碟空間可用於快取資料。

若僅搭配臨時物件功能使用 Optimized Reads,所有可用的本機儲存磁碟空間都可用於臨時物件。例如,搭配臨時物件和分層快取功能使用 r6gd.8xlarge 執行個體時,會為臨時物件保留 534 GiB (2 倍記憶體容量),而 1054 GiB 則用於分層快取。

若本機儲存失敗會發生什麼?

如果本機儲存失敗,Aurora 會自動執行主機取代。在多節點資料庫叢集中,這會觸發區域內容錯移轉。

在發生資料庫容錯移轉時,適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 如何影響查詢延遲?

在發生資料庫容錯移轉的情況下,容錯移轉之後的查詢延遲會暫時增加。這種延遲增加會隨著時間的推移而減少,並最終追回到容錯移轉之前的查詢延遲。啟用叢集快取管理 (CCM) 可加速此追趕時間。使用 CCM,客戶可將特定的 Aurora PostgreSQL 資料庫執行個體指定為容錯移轉目標。

啟用 CCM 後,指定容錯移轉目標的本機儲存快取會緊密反映主要執行個體的本機儲存快取,從而縮短容錯移轉後的追趕時間。然而,如果指定的容錯移轉目標也正用於提供與寫入器執行個體的工作負載分開的讀取工作負載,則啟用 CCM 可能會影響本機儲存快取的長期有效性。

因此,客戶若執行需要將讀取器指定為待命容錯移轉的工作負載,必須讓 CCM 增加容錯移轉後快速恢復查詢延遲的可能性。客戶若在其指定的容錯移轉目標上執行單獨的工作負載,可能希望平衡容錯移轉後立即復原延遲的需求,與啟用 CCM 之前快取效能的長期有效性。

生成式 AI

什麼是 pgvector?

pgvector 是 PostgreSQL 的開放原始碼延伸,由 Amazon Aurora PostgreSQL 相容版本提供支援。

pgvector 為 Aurora PostgreSQL 實現了哪些功能?

您可以使用 pgvector 在資料庫中存放、搜尋、索引和查詢從機器學習 (ML) 和人工智慧 (AI) 模型中產生的數十億個內嵌項目,例如 Amazon BedrockAmazon SageMaker 中的模型。向量內嵌是一種數字呈現,表示文字、影像和影片等內容的語義含義。
 
使用 pgvector,您可以查詢 Aurora PostgreSQL 資料庫中的內嵌項目,以便對這些資料類型 (以向量表示、與 Aurora 中的其他表格資料結合) 執行有效的語意相似性搜尋。這可讓您將生成式 AI 和其他 AI/ML 系統用於新的應用程式類型,例如根據類似文字描述或影像提供個人化建議、根據面試備註、機器人進行候選人比對,根據成功的文稿或聊天工作階段對話方塊提供客服的下一個最佳行動建議,等等。 
 
請閱讀我們 向量資料庫功能部落格,了解如何在 Aurora PostgreSQL 資料庫中使用 pgvector 延伸來存放內嵌項目、建立互動式問題回答聊天機器人,以及使用 pgvector 與 Aurora 機器學習之間的原生整合進行情緒分析。

pgvector 是否與 Aurora 機器學習搭配使用?

是。Aurora 機器學習 (ML) 將 ML 模型公開為 SQL 函數,允許您使用標準 SQL 來呼叫 ML 模型,將資料傳遞給它們,並將預測做為查詢結果傳回。pgvector 要求將向量內嵌項目存放在資料庫中,這需要在來源文字或影像資料上執行 ML 模型才能產生內嵌項目,然後將批次內嵌項目移至 Aurora PostgreSQL 中。

Aurora ML 可定期呼叫 Amazon BedrockAmazon SageMaker,這會傳回模型中的最新內嵌項目,讓此成為即時程序,使內嵌項目在 Aurora PostgreSQL 中保持最新狀態。

適用於 Aurora PostgreSQL 的 Aurora Optimized Reads 如何改善 pgvector 效能?

Amazon Aurora PostgreSQL Optimized Reads 使用 pgvector,在超過可用執行個體記憶體的工作負載中,每秒進行向量搜尋的查詢可增加高達 9 倍。由於 Optimized Reads 提供分層快取功能,可自動將快取資料從記憶體資料庫緩衝區快取移至本機儲存,以加速該資料的後續存取。

零 ETL 整合

何時應使用 Aurora 與 Amazon Redshift 的零 ETL 整合?

若您需要近乎即時地存取交易資料,則應使用 Amazon Aurora 與 Amazon Redshift 的零 ETL 整合。此整合可讓您透過簡單的 SQL 命令,充分利用 Amazon Redshift ML 的優勢。

哪些 Aurora 引擎和版本支援零 ETL 整合?

Aurora MySQL 與 Amazon Redshift 的零 ETL 整合可在以下區域適用於 Aurora MySQL 3.05 以上版本 (與 MySQL 8.0.32 相容) 的 Aurora MySQL 相容版本提供:美國東部 (俄亥俄)、美國東部 (維吉尼亞北部)、美國西部 (奧勒岡)、亞太區域 (新加坡)、亞太區域 (雪梨)、亞太區域 (東京)、歐洲 (法蘭克福)、歐洲 (愛爾蘭) 和歐洲 (斯德哥爾摩) 區域。Aurora 與 Amazon Redshift 的零 ETL 整合適用於美國東部 (俄亥俄) 區域中 Aurora PostgreSQL 15.4 的 Aurora PostgreSQL 相容版本。

零 ETL 整合提供哪些優勢?

Aurora 與 Amazon Redshift 的零 ETL 整合可移除建置和維護複雜資料管道的需求。您可以將單一或多個 Aurora 資料庫叢集的資料整合至單一 Amazon Redshift 資料庫叢集,並使用 Amazon Redshift 對 Aurora 的 PB 級交易資料執行近乎即時的分析和 ML 處理。 

零 ETL 整合是否與 Aurora Serverless v2 相容?

Aurora 與 Amazon Redshift 的零 ETL 整合與 Aurora Serverless v2 相容。同時使用 Aurora Serverless v2Amazon Redshift Serverless 時,您可以針對交易資料產生近乎即時的分析,而無需管理任何資料管道的基礎設施。

如何開始零 ETL 整合?

您可以使用 Amazon RDS 主控台,並指定 Aurora 來源和 Amazon Redshift 目的地來建立零 ETL 整合,即可開始使用。建立整合後,Aurora 資料庫會複寫到 Amazon Redshift,您即可在初始植入完成後開始查詢資料。如需詳細資訊,請參閱 Aurora 與 Amazon Redshift 的零 ETL 整合入門指南。

零 ETL 整合的費用是多少?

免費提供零 ETL 整合和持續處理資料變更。您需要為使用現有的 Amazon RDS 和 Amazon Redshift 資源,建立和處理做為零 ETL 整合一部分而產生的變更資料付費。這些資源可能包括:

  • 藉由啟用增強的 binlog 使用的額外 I/O 和儲存
  • 初始資料匯出至做為 Amazon Redshift 資料庫種子的快照匯出成本
  • 用於儲存複寫資料的額外 Amazon Redshift 儲存
  • 將資料從來源移至目標的跨可用區域資料傳輸成本

如需詳細資訊,請瀏覽 Aurora 定價頁面

Amazon DevOps Guru for RDS

什麼是 Amazon DevOps Guru for RDS?

Amazon DevOps Guru for RDSAmazon 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 工程師,並提供診斷資訊、問題程度的詳細資訊和智慧修復建議,以協助客戶快速解決與資料庫相關的效能瓶頸和操作問題。

為什麼應使用 DevOps Guru for RDS?

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

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

Amazon DevOps Guru for RDS 如何運作?

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

如何開始使用 Amazon DevOps Guru for RDS?

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

Amazon DevOps Guru for RDS 可以偵測哪些類型的問題?

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

DevOps Guru for RDS 與 Amazon RDS Performance insights 有何差異?

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

Data API

何時應搭配使用 Data API 與 Aurora,而非資料庫驅動程式?

您應該對新的現代應用程式使用 Data API,尤其是那些採用 AWS Lambda 建置,而且需要在請求/回應模型中存取 Aurora 的現代應用程式。當現有應用程式與資料庫驅動程式高度耦合、有長時間執行的查詢,或者當開發人員想要利用臨時資料表等資料庫功能或使用工作階段變數時,您應該使用資料庫驅動程式而非 Data API,並且管理持久性資料庫連線。

哪些 Aurora 引擎和版本支援 Data API?

您可以在我們的文件中,查閱針對 Aurora Serverless v2 和 Aurora 佈建執行個體的 Data API AWS 區域和資料庫版本可用性相關資訊。若客戶目前使用適用於 Aurora Serverless v1 的 Data API,我們建議他們遷移至 Aurora Serverless v2,以便利用重新設計的 Data API 和更精細的 Aurora Serverless v2 擴展。

Data API 提供哪些好處?

Data API 將讓您簡化與加快現代應用程式開發。Data API 是一種簡單易用且安全的 HTTP 型 API,可消除部署資料庫驅動程式的必要性,管理客戶端連線集區或在應用程式和資料庫之間設定複雜的 VPC 聯網。Data API 還透過自動建立資料庫連線集區並進行共用來提高可擴展性,從而幫助需頻繁開啟和關閉連線的應用程式減少運算開銷。 

Data API 是否支援 Aurora 全球資料庫或 Aurora Serverless v1?

針對 Aurora 的 PostgreSQL 相容版本和 MySQL 相容版本,現有適用於 Aurora Serverless v1 的 Data API 將繼續做為 Aurora Serverless v1 的一項功能。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體不支援 Aurora Serverless v1。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體支援 Aurora 全球資料庫寫入器執行個體。

如何以採用 Data API 的資料庫進行身分驗證?

使用者只有在得到授權時才能調用 Data API 操作。管理員可以透過附加定義使用者權限的 AWS Identity and Access Management (IAM) 政策授予其使用 Data API 的許可。如果您使用 IAM 角色,也可以對某個角色附加政策。呼叫 Data API 時,您可以透過在 AWS Secrets Manager 中使用機密為 Aurora 資料庫叢集傳送憑證。 

Data API 的費用是多少?

Aurora Serverless v1 仍可使用 Data API,而不會產生額外費用。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體依 API 請求量定價,如 Aurora 定價頁面上所述。適用於 Aurora Serveless v2 的 Data API 和 Aurora 佈建執行個體使用 AWS CloudTrail 資料平面事件而非管理事件來記錄活動,這與適用於 Aurora Serverless v1 的 Data API 相同。

如果您想要追蹤此活動,可以透過 CloudTrail 主控台、CLI 或 SDK 啟用資料事件記錄。這樣做將產生費用,詳細資訊請見 CloudTrail 定價頁面。此外,使用 AWS Secrets Manager 也會產生費用,請參閱 AWS Secrets Manager 以了解更多資訊。 

為什麼 AWS 開始對 Data API 使用資料平面事件,而不是 CloudTrail 管理事件?

AWS CloudTrail 會將 AWS API 活動擷取為管理事件或資料事件。CloudTrail 管理事件 (又稱為「控制平面操作」) 顯示在 AWS 帳戶中的資源上執行的管理操作,例如建立、更新和刪除某項資源。CloudTrail 資料事件 (又稱為「資料平面操作」) 顯示在 AWS 帳戶中的資源上或資源內執行的資源操作。

Data API 會執行資料平面操作,因為它會對 Aurora 資料庫中的資料執行查詢。因此,我們會將 Data API 活動記錄為資料事件,因為這是正確的事件分類。如果您啟用資料事件記錄,只有 CloudTrail 資料事件才會產生費用。

Data API 是否有免費方案?

是的,Data API 免費方案包括第一年每個月一百萬個請求,這是跨所有 AWS 區域的彙總用量。 一年後,客戶將開始按 Aurora 定價頁面所述支付 Data API 費用。

Amazon RDS 藍/綠部署

Amazon RDS 藍/綠部署支援哪些版本?

Amazon Aurora MySQL 相容版本 5.6 及更高版本,以及 Amazon Aurora PostgreSQL 相容版本 11.21 及更高版本、12.16 及更高版本、13.12 及更高版本、14.9 及更高版本和 15.4 及更高版本中均提供 Amazon RDS 藍/綠部署。請參閱 Aurora 文件,進一步了解可用的版本。

Amazon RDS 藍/綠部署支援哪些區域?

Amazon RDS 藍/綠部署可在所有適用的 AWS 區域和 AWS GovCloud 區域使用。

何時應使用 Amazon RDS 藍/綠部署?

Amazon RDS 藍/綠部署可讓您進行更安全、更簡單、更快速的資料庫變更。藍/綠部署非常適合主要或次要版本資料庫引擎升級、作業系統更新、綠色環境中的結構描述變更等不會破壞邏輯複寫的使用案例,例如在表末尾新增新欄或資料庫參數設定變更。

您可以使用藍/綠部署透過單一轉換同時進行多個資料庫更新。這可讓您隨時掌握安全修補程式的最新資訊、改善資料庫效能,並以短暫且可預測的停機時間存取較新的資料庫功能。如果您只想在 Aurora 上執行次要版本升級,我們建議您使用 Aurora Zero Downtime Patching (ZDP)

使用 Amazon RDS 藍/綠部署需要多少費用?

在綠色或藍色執行個體上執行您的工作負載所產生的成本相同。在藍色和綠色執行個體上執行的成本包括我們的資料庫執行個體的目前標準定價、儲存成本、讀取/寫入 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 藍/綠部署啟動轉換後,它會同時阻止寫入到藍色和綠色環境,直至轉換完成為止。 在轉換期間,綠色環境 (或稱預備環境) 會追趕上生產系統,確保預備環境與生產環境的資料保持一致。生產和預備環境完成同步後,藍/綠部署會將流量重新引導至新升級的生產環境,使預備環境成為新的生產環境。

Amazon RDS 藍/綠部署的設計允許轉換完成後在綠色環境上執行寫入,從而確保轉換流程中不會遺失任何資料。

Amazon RDS 藍/綠部署轉換完成後,我的舊生產環境將會如何?

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

Amazon RDS 藍/綠部署的轉換防護機制會檢查哪些內容?

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

我具有藍色資料庫作為自我管理邏輯複本的訂閱用戶/發布者時,是否可以使用藍/綠部署?

如果您的藍色環境是自我管理邏輯複本或訂閱用戶,我們將封鎖轉換。我們建議您先停止複寫至藍色環境,繼續轉換,然後繼續複寫。相反,如果您的藍色環境是自我管理邏輯複本或發布者的來源,您可以繼續轉換。但是,您將需要更新自我管理複本,以在轉換後從綠色環境進行複寫。

Amazon RDS 藍/綠部署是否支援 Amazon Aurora 全球資料庫、Amazon RDS Proxy 或跨區域僅供讀取複本?

否,Amazon RDS 藍/綠部署不支援 Amazon Aurora 全球資料庫、Amazon RDS Proxy 或跨區域僅供讀取複本。

我可以使用 Amazon RDS 藍/綠部署來轉返變更嗎?

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

Trusted Language Extensions for PostgreSQL

為什麼我應該使用 Trusted Language Extensions for PostgreSQL?

Trusted Language Extensions (TLE) for PostgreSQL 可讓開發人員建立高效能 PostgreSQL 延伸模組,並在 Amazon Aurora 上安全執行該模組。這樣一來,TLE 可縮短您的上市時間,並減輕資料庫管理員在驗證用於生產資料庫工作負載的自訂和第三方程式碼方面的負擔。一旦確定延伸模組符合您的需求,就能繼續進行。獨立軟體開發廠商 (ISV) 採用 TLE 後,即可向在 Aurora 上執行的客戶提供全新 PostgreSQL 延伸模組。

在 PostgreSQL 中執行延伸模組的傳統風險有哪些?TLE for PostgreSQL 如何降低這些風險?

PostgreSQL 擴展在相同的程序空間執行以獲得高效能。然而,擴展可能存在可導致資料庫崩潰的軟體缺陷。
 
TLE for PostgreSQL 可提供多層保護來降低這種風險。TLE 的設計可限制對系統資源的存取。 rds_superuser 角色可確定允許誰安裝特定擴展。不過,這些變更只能透過 TLE API 進行。TLE 的設計可限制擴展缺陷對單一資料庫連線的影響。除了這些保護措施之外,TLE 的設計還可為 rds_superuser 角色中的 DBA 提供細粒度線上控制,以控制誰可以安裝擴展,並且他們可以建立執行這些擴展的許可模型。使用者只有具有足夠的許可,才能在 TLE 擴展上使用「CREATE EXTENSION」命令來執行和建立。DBA 還可將更複雜的擴展所需的「PostgreSQL 掛鉤」列入允許清單,這些擴展可修改資料庫的內部行為,並且通常需要提升的許可。

TLE for PostgreSQL 如何與其他 AWS 服務建立關聯/搭配使用?

TLE for Aurora PostgreSQL 可用於 Amazon Aurora PostgreSQL 相容版本 14.5 以上版本。TLE 本身以 PostgreSQL 延伸模組形式實作,您可從與 Arora 上支援的其他延伸模組相似的 rds_superuser 角色將其啟動。

我可以在哪些版本的 PostgreSQL 中執行 TLE for PostgreSQL?

您可在 Amazon Aurora 中執行 PostgreSQL 14.5 以上版本的 TLE for PostgreSQL

Trusted Language Extensions for PostgreSQL 可用於哪些區域?

TLE for PostgreSQL 目前可用於所有 AWS 區域 (不包括 AWS 中國區域) 和 AWS GovCloud 區域。

執行 TLE 需要多少費用?

TLE for PostgreSQL 可供 Aurora 客戶免費使用。

TLE for PostgreSQL 與目前 Amazon Aurora 和 Amazon RDS 上可用的延伸模組有何不同?

AuroraAmazon RDS 支援超過 85 個經策管的 PostgreSQL 擴展集。AWS 在 AWS 共同責任模式下管理每個擴展的安全風險。實作 TLE for PostgreSQL 的延伸套件包含在這個集合中。您編寫或從第三方來源獲得並安裝在 TLE 中的擴展,會被視為應用程式的程式碼的一部分。您須對使用 TLE 擴展的應用程式的安全負責。

我可以使用 TLE for PostgreSQL 執行哪些擴展範例?

您可以建置開發人員功能,例如點陣圖壓縮和差分隱私權 (如保護個人隱私權的可公開存取的統計查詢)。

我可以使用哪些程式設計語言開發 TLE for PostgreSQL?

TLE for PostgreSQL 目前支援 JavaScript、PL/pgSQL、Perl 和 SQL。

如何部署 TLE for PostgreSQL 延伸套件?

一旦 rds_superuser 角色啟用 TLE for PostgreSQL,即可使用來自任何 PostgreSQL 用戶端 (例如 psql) 的 SQL CREATE EXTENSION 命令部署 TLE 擴展。這種方式類似於建立以程序語言 (例如 PL/pgSQL 或 PL/Perl) 編寫的使用者定義函數。您可以控制哪些使用者具有部署 TLE 擴展並使用特定擴展的許可。

TLE for PostgreSQL 擴展如何與 PostgreSQL 資料庫通訊?

TLE for PostgreSQL 透過 TLE API 來專門存取您的 PostgreSQL 資料庫。TLE 支援的受信任語言包括 PostgreSQL 伺服器程式設計介面 (SPI) 的所有函數,以及對 PostgreSQL 掛鉤的支援,包括檢查密碼掛鉤。

在哪裡可以進一步了解有關 TLE for PostgreSQL 開放原始碼專案的資訊?

您可以前往官方 TLE GitHub 頁面,進一步了解有關 TLE for PostgreSQL 專案的資訊。

Amazon RDS 延伸支援

是否可以將 RDS 延伸支援與任何次要版本搭配使用?

否,Amazon RDS 延伸支援僅適用於某些次要版本。詳情請參閱 Aurora 使用者指南。 

如何估計我的 RDS 延伸支援費用?

Amazon RDS 延伸支援的費用取決於三個因素:1. 執行個體上執行的 vCPU 或 ACU 數目,2.AWS 區域,以及 3. 標準支援結束後的年數。

若要估算費用,請確定執行個體上的 vCPU 數目,以及引擎版本適用的行事曆年定價。如果您的版本採用 1-2 年定價,且您正在使用佈建執行個體,則會根據您選擇的區域依每小時用量按 #vCPUs x 1 年和 2 年定價計費。如果您的版本採用 3 年定價,且您正在使用佈建執行個體,則會根據您選擇的區域依每小時用量按 #vCPUs x 3 年定價計費

例如,如果您於 2024 年 12 月 30 日在維吉尼亞北部執行 Aurora MySQL 相容版本 2 的 db.r5.large 執行個體,且在 RDS 延伸支援的第一年內,則您需要支付每小時 0.200 美元或 2 個 vCPU x 每小時 0.100 美元的費用。

Amazon Aurora 何時開始依 RDS 延伸支援計費?

在 Aurora MySQL 相容版本的主要版本標準支援結束日期後的第二天,您將開始收到 Amazon RDS 延伸支援的費用。這將是執行個體生命週期產生的執行個體、儲存、備份及/或資料傳輸費用以外的費用。

例如,Aurora MySQL 相容版本 2 標準支援將於 2024 年 11 月 30 日結束。如果您於 2024 年 11 月 30 日之後執行 Aurora MySQL 相容版本 2 的執行個體,則需支付該執行個體上的 RDS 延伸支援費用。

是否是否需要為資料庫快照上的 RDS 延伸支援付費?

否,Amazon RDS 延伸支援定價不適用於資料庫快照。但是,當您將快照還原到使用 RDS 延伸支援上某個版本的新資料庫執行個體時,該執行個體將依 RDS 延伸支援定價計費,直到您升級為標準支援版本或刪除執行個體為止。

何時停止接收 RDS 延伸支援的費用?

將您的執行個體升級至標準支援適用的較新引擎版本,可避免您的執行個體依 RDS 延伸支援定價計費。當您關閉或刪除在標準支援結束日期後執行主要引擎版本的執行個體時,RDS 延伸支援的費用會自動停止。

每個引擎版本都會列出兩種不同的價格。如何知道我被收取哪些費用?

您需要支付的 RDS 延伸支援價格取決於引擎版本、AWS 區域,以及該版本標準支援到期以來的行事曆年數。在標準支援結束後的前兩年,會根據您選擇的區域依每 vCPU-小時按 1 年和 2 年定價計費。如果提供三年期 RDS 延伸支援,則從第三年的第一天開始,根據您選擇的區域 (每 vCPU-小時) 依 3 年定價計費。

例如,Aurora PostgreSQL 相容版本 11 於 2024 年 2 月 29 日終止標準支援。如果您在美國東部 (俄亥俄) 部署,則在 2024 年 4 月 1 日至 2026 年 3 月 31 日期間,每 vCPU-小時將支付 0.100 USD 的費用。從 2026 年 4 月 1 日起,您將需要支付每 vCPU-小時 0.200 USD 的費用。

如何避免產生 RDS 延伸支援收費?

建議您儘早將執行個體升級至標準支援期限內的主要引擎版本。這有助於避免產生 RDS 延伸支援費用。

是否可以使用 Amazon RDS 藍/綠部署,從 RDS 延伸支援版本遷移至標準支援版本?

只要藍/綠部署支援執行個體的引擎、區域和主要版本類型,即可使用 Amazon RDS 藍/綠部署,藉由 RDS 延伸支援遷移執行個體。藍/綠部署適用於 Aurora MySQL 相容版本。如需有關可用版本的資訊,請參閱藍/綠部署文件

預留執行個體折扣是否適用於 RDS 延伸支援?

否,RDS 延伸支援費用與執行個體費用無關。因此,預留執行個體折扣不適用於 RDS 延伸支援費用。

如果從 RDS for MySQL 5.7 遷移至 Aurora MySQL 2 (以 MySQL 5.7 為基礎),是否需要支付 RDS 延伸支援費用?

如果您於 2024 年 2 月 29 日前從 RDS for MySQL 5.7 遷移至 Aurora MySQL 2,則無需支付 RDS 延伸支援費用。如果您於 2024 年 2 月 29 日之後和 2024 年 11 月 30 日之前進行遷移,則需要支付 RDS 延伸支援費用,並依您在 Amazon RDS 上執行 MySQL 5.7 的時數計費。

如果您於 2024 年 11 月 30 日之後移轉,或在 2024 年 11 月 30 日之後使用 Aurora MySQL 相容版本 2,您也需要支付在 Aurora 資料庫上使用 RDS 延伸支援的費用。如需其他詳細資訊,請參閱 Amazon AuroraAmazon RDS 文件

當我在不再使用標準支援的版本上建立的資料庫快照時,會發生什麼情況? 我是否需要為此支付 RDS 延伸支援費用?

否,資料庫快照不會依 RDS 延伸支援定價計費。但是,當您在標準支援結束後,若將資料庫快照還原至新的資料庫執行個體,則需依該執行個體的 RDS 延伸支援定價付費。

例如,如果您於 2024 年 11 月 30 日之後將資料庫快照還原至 Aurora MySQL 相容版本 2 上的新資料庫執行個體,則該執行個體將依 Aurora MySQL 相容版本 2 的 RDS 延伸支援定價計費,直到您將其升級至 Aurora MySQL 相容版本 3 或更新版本,或者刪除該執行個體為止。

如果我在主要版本引擎到達標準支援結束日期後,在主要版本引擎上建立新執行個體,是否需要支付 RDS 延伸支援費用?

是,如果您建立執行個體,或將資料庫快照還原至執行於已到達標準支援結束日期的版本的執行個體,則除了執行個體、儲存、備份和資料傳輸費用外,還需依 RDS 延伸支援定價付費。

進一步了解 Amazon Aurora 定價

瀏覽定價頁面
準備好開始建置了嗎?
開始使用 Amazon Aurora
還有其他問題嗎?
聯絡我們