一般問題

什麼是 Amazon Aurora?

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

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

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

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 解決 Amazon Aurora 的特定問題。

如何開始使用 Amazon Aurora?

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

Amazon Aurora 的費用為何?

對於已佈建的 Aurora,您可以選擇隨需執行個體並按小時支付資料庫費用,無需長期承諾或預付費用,或者選擇預留執行個體以節省額外費用。或者,Aurora Serverless 可根據應用程式的需要自動啟動、關閉和擴展或縮減容量,您僅需按耗用的容量付費。

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

Amazon Aurora 在三個可用區域間以六種方法複製資料庫磁碟區的每個區塊。這是否表示我的有效儲存價格將是定價頁面上所顯示價格的三或六倍?

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

Amazon Aurora 可在哪些 AWS 區域使用?

AWS 區域設計為與其他 AWS 區域隔離。這種設計實現了最大可能的容錯能力和穩定性。檢視資源時,您只會看到與您指定的 AWS 區域相關聯的資源。這是因為 AWS 區域彼此隔離,我們不會跨 AWS 區域自動複寫資源。

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

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

如果您想從 MySQL 遷移到 Amazon Aurora (反之亦然),您有幾種選擇:

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

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

如何從 PostgreSQL 移轉到 Amazon Aurora?又如何反向進行?

如果您想從 PostgreSQL 遷移到 Amazon Aurora (反之亦然),您有幾種選擇:

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

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

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

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

目前未包含在內。Amazon RDS 的 AWS 免費方案為微型資料庫執行個體提供多種益處;Amazon Aurora 目前不提供微型資料庫執行個體支援。請參閱 Aurora 定價頁面了解最新的定價資訊。
若要試用 Amazon Aurora,請登入 AWS 管理主控台,選取資料庫類別下的 RDS,然後選擇 Amazon Aurora 作為您的資料庫引擎。

Amazon Aurora 的 I/O 是什麼,如何計算?

輸入/輸出是 Aurora 資料庫引擎在其固態硬碟 (SSD) 虛擬儲存層中執行的輸入/輸出操作。每個資料庫頁面讀取操作視為一個輸入/輸出。

Aurora 資料庫引擎發出讀取儲存層請求,以擷取不在快取記憶體中的資料庫頁面:

  • 如果您的查詢流量能完全以記憶體或快取滿足,不會因您自記憶體擷取任何資料頁面而收費。
  • 如果您的查詢流量無法完全以記憶體滿足,會按照需要自儲存區擷取的資料頁面向您收費。

每個資料庫頁面在 Aurora MySQL 相容版本中為 16 KB,在 Aurora PostgreSQL 相容版本中為 8 KB。

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

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

日誌記錄小於 4 KB 的並行寫入操作若常駐在同一個儲存保護群組,可由 Aurora 資料庫引擎併為批次處理,以便最佳化輸入/輸出耗用。有別於傳統資料庫引擎,Aurora 從不將已變更的資料頁面排清至儲存區。

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

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

否,Amazon 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 上的工作負載輸送量,建議您將應用程式建置為可驅動大量並行查詢和交易。

硬體和擴展

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 會自動處理容錯移轉,所以您的應用程式可以盡快恢復資料庫操作,而無須人為管理介入。

  • 如果您在相同或不同可用區域中有一個 Amazon Aurora 複本,當容錯移轉時,Aurora 會翻轉資料庫執行個體的正規名稱記錄 (CNAME) 以指向執行狀態正常的複本,該複本轉而提升成新的主複本。容錯移轉從開始到結束通常可在 30 秒內完成。 
  • 如果您執行的是 Aurora Serverless,且資料庫執行個體或 AZ 無法使用,Aurora 會自動在不同的 AZ 中重新建立資料庫執行個體。 
  • 如果您沒有 Amazon 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 Aurora Multi-Master?

Amazon Aurora Multi-Master 是 Aurora MySQL 相容版本的新功能,加入了跨多個可用區域擴展寫入效能的能力,允許應用程式將讀取/寫入工作負載導向資料庫叢集中的多個執行個體,並以高可用性進行操作。

如何開始使用 Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master 現在已正式上市。您可以參閱 Amazon Aurora 文件進一步了解相關資訊。只要在 Amazon RDS 主控台上按幾下,或下載最新 AWS 開發套件或 CLI,即可建立 Aurora Multi-Master 叢集。

安全性

我是否可以在 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 資料庫?

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

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

是,與 MySQL 和 PostgreSQL 相容的 Aurora 版本符合健康保險流通與責任法案 (HIPAA),因此可用於建立 HIPAA 合規應用程式及存放醫療保健相關資訊,包括與 AWS 共同履行的商業夥伴協議 (BAA) 下的受保護醫療資訊 (PHI)。如果您已經有履行的 BAA,則您不需要進行任何動作,就能透過 BAA 涵蓋的帳戶開始使用這些服務。如需有關在 AWS 上建置合規應用程式的詳細資訊,請參閱醫療保健供應商與保險業者的雲端應用

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

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

無伺服器

什麼是 Amazon Aurora Serverless?

Aurora Serverless 是 Amazon Aurora 的隨需、自動調整規模組態。它可讓您在雲端執行資料庫,無需管理資料庫容量。手動管理資料庫容量需花費寶貴的時間,而且可能導致資料庫資源使用效率不良的情況。使用 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 中,資料庫容量以 Aurora 容量單位 (ACU) 計算。按每秒 ACU 用量的固定費率付費。儲存和 I/O 價格與佈建和無伺服器組態相同。瀏覽 Aurora 定價頁面,以了解有關定價和 AWS 區域可用性的最新資訊。

平行查詢

什麼是 Amazon Aurora 平行查詢?

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

有哪些目標使用案例?

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

平行查詢提供哪些好處?

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

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

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

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

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

效能是否有可能變慢?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 績效詳情 (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 績效詳情有何差異?

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

進一步了解 Amazon Aurora 定價

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