Amazon RDS for MySQL 常見問答集

Amazon Relational Database (Amazon RDS) for MySQL 目前支援 MySQL Community Edition 5.7 和 8.0 版。Amazon RDS 使用者指南會提供支援的次要版本相關資訊。

在 MySQL 環境中，版本編號的編排方式如下：
MySQL 版本 = X.Y.Z

X = 主要版本，Y = 版次級別，Z = 版次系列內的版本編號。
以 Amazon RDS 的觀點而言，如果主要版本或版次級別變更，即視為主要版本變更。範例：從 5.6.X -> 5.7.X。

如果版次內的版本編號有所變更，則視為次要版本變更。範例：從 5.6.27 -> 5.6.29。

是。請參閱 Amazon RDS 常見問答集。

Amazon RDS for MySQL 的時點還原、快照還原，以及與 Amazon Redshift 的零 ETL 整合功能需要可損毀修復的儲存引擎，且僅支援 InnoDB 儲存引擎。雖然 MySQL 支援功能不同的多種儲存引擎，但並非所有引擎都針對損毀修復和資料持久性進行優化。例如，MyISAM 儲存引擎不支援可靠的損毀修復，並且在損毀後重新啟動 MySQL 時可能導致資料遺失或資料損毀，使時間點還原或快照還原無法如預期工作。然而，若您仍選擇搭配使用 MyISAM 與 Amazon RDS，則可在特定情況下遵循這些步驟，以解決資料庫快照還原功能的相關問題。RDS for MySQL 目前不支援聯合儲存引擎。

當您建立新的資料庫執行個體時，您使用的預設主要使用者會獲得特定權限。如需相關權限的清單，請參閱 Amazon RDS 使用者指南中的主要使用者帳戶權限。

RDS for MySQL 僅供讀取複本需要交易處理儲存引擎，且只支援 InnoDB 儲存引擎。非交易處理 MySQL 儲存引擎 (如 MyISAM) 可能會使僅供讀取複本無法按預期方式執行。不過，如果您仍然選擇使用 MyISAM 搭配僅供讀取複本，建議您密切監視 Amazon CloudWatch 的 "Replica Lag" 指標 (透過 AWS 管理主控台或 Amazon CloudWatch API 提供)，並在其因為複寫發生錯誤而落後時重新建立僅供讀取複本。使用臨時表及任何其他非交易處理引擎時，也應考慮上述事項。

您可以為 MySQL 5.6 版和更新版本將二進位日誌格式設定為以資料列為基礎。根據預設，複寫是設定為混合格式 (包含資料列和陳述式複寫)，其應能滿足大多數使用案例的要求。在 MySQL 文件中，會詳細說明混合格式複寫與以資料列為基礎複寫間的差異。

Amazon RDS 藍/綠部署可在 RDS for MySQL 5.7 及更高版本中使用。請參閱 RDS for MySQL 文件，進一步了解可用的版本。

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

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

Amazon RDS 藍/綠部署可讓您進行更安全、更簡單、更快速的資料庫變更。藍/綠部署非常適合主要或次要版本資料庫引擎升級、作業系統更新、綠色環境中的結構描述變更等不會破壞邏輯複寫的使用案例，例如在表末尾新增新欄或資料庫參數設定變更。您可以使用藍/綠部署透過單一轉換同時進行多個資料庫更新。這可讓您隨時掌握安全修補程式的最新資訊、改善資料庫效能，並以短暫且可預測的停機時間存取較新的資料庫功能。

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

例如，您在兩個 r5.2xlarge 資料庫執行個體 (一個主要資料庫執行個體和一個僅供讀取複本) 上執行一個 RDS for MySQL 5.7 資料庫，它們位於 us-east-1 AWS 區域並採用多可用區 (MAZ) 組態。每個 r5.2xlarge 資料庫執行個體均設定為 20 GiB 一般用途 Amazon Elastic Block Store (Amazon EBS)。您要使用 Amazon RDS 藍/綠部署建立藍色執行個體拓撲的複製項目，執行它 15 天 (360 小時)，然後在成功轉換以後刪除藍色執行個體。藍色執行個體的隨需價格為每小時 1.926 美元 (執行個體 + EBS 成本)，所以 15 天的成本為 1,387 美元。這 15 天使用藍/綠部署的總成本為 2,774 USD，是在該期間執行藍色執行個體所產生成本的 2 倍。

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

當 Amazon RDS 藍/綠部署啟動轉換時，它會同時阻止寫入到藍色和綠色環境，直至轉換完成為止。轉換期間，預備環境或綠色環境將追趕藍色環境進度，確保藍色和綠色環境之間資料的一致性。一旦藍色和綠色環境完成同步，藍/綠部署會透過將流量重新引導至綠色環境，使綠色環境成為新的藍色環境。藍/綠部署的設計允許轉換完成後在綠色環境上執行寫入，確保轉換流程中不會遺失任何資料。

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

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

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

不，Amazon RDS 藍/綠部署不支援 Amazon RDS Proxy、跨區域僅供讀取複本或串聯僅供讀取複本。

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

MySQL 透過在記憶體中以 16 KiB 頁面大小將資料寫入到耐久儲存兩次 (先到「雙寫緩衝」，然後再寫入表格儲存)，保護使用者免於資料遺失。Amazon RDS Optimized Writes 利用 AWS Nitro System 的寫入損壞防護功能，在一個步驟中以可靠而持久的方式直接將您的 16 KiB 資料頁面直接寫入到您的資料檔案。

Amazon RDS Optimized Writes 適用於 MySQL 主要版本 8.0.30 及更新版本。

Amazon RDS Optimized Writes 可在 db.r6i 和 db.r5b 執行個體中使用。目前在所有提供這些執行個體的區域中皆可使用，但 AWS 中國區域除外。

所有 RDS for MySQL 使用者應實作 Amazon RDS Optimized Writes，最多可將寫入交易輸送量增加 2 倍。此項功能對有大量寫入工作負載的應用程式 (如數位支付、金融交易和線上遊戲應用程式) 非常有幫助。

不支援。Amazon Aurora MySQL 相容版本已不再使用「雙寫緩衝」。 反之，Aurora 會在三個可用區域 (AZ) 間六向複寫資料，採用以 quorum 為基礎的方法持久寫入數據，並在其後正確地讀取。

此最初版本目前不支援為您的現有資料庫執行個體啟用 Amazon RDS Optimized Writes，即便執行個體類別支援 Optimized Writes 也不支援。

RDS for MySQL 客戶可使用 Amazon RDS Optimized Writes，無需支付額外費用。

使用 MySQL 中的臨時物件處理查詢的工作負載可從 Amazon RDS Optimized Reads 中受益。Optimized Reads 會將臨時物件置放在資料庫執行個體的 NVMe 型執行個體儲存體，而非 Amazon EBS 磁碟區。這將使複雜的查詢處理速度加快高達 50%。

Amazon RDS Optimized Reads 適用於 MySQL 版本 8.0.28 及更新版本上的 RDS for MySQL。

Amazon RDS Optimized Reads 在所有提供 db.r5d、db.m5d、db.r6gd、db.m6gd、X2idn 和 X2iedn 執行個體的區域中皆可使用。如需詳細資訊，請參閱 Amazon RDS 資料庫執行個體類別文件。

客戶應在有需要複雜查詢，一般用途分析，或需要繁瑣分組、排序、雜湊彙總、高負載聯結和通用資料表運算式 (CTE) 的工作負載時使用 Amazon RDS Optimized Reads。這些使用案例會引發建立臨時表格，使 Optimized Reads 能夠加快您的工作負載查詢處理。

是的，客戶可以透過移動您的工作負載至啟用優化讀取的執行個體，將他們的現有 Amazon RDS 資料庫轉換為使用 Amazon RDS Optimized Reads。預設也會套用 Optimized Reads 到所有支援的執行個體類別。如果在 db.r5d、db.m5d、db.r6gd、db.m6gd、X2idn 和 X2iedn 執行個體上執行工作負載，您可以立即受惠於 Optimized Reads。

當您想要移除建置和管理複雜資料管道的需求時，應該使用 Amazon RDS for MySQL 與 Amazon Redshift 的零 ETL 整合。一旦資料位於 Amazon Redshift 中，您就可以在來自 RDS for MySQL 的交易資料上存取近乎即時分析和機器學習 (ML) 功能。

在支援的 AWS 區域中，RDS for MySQL 與 Amazon Redshift 的零 ETL 整合適用於 MySQL 8.0.32 版和更高版本。

RDS for MySQL 與 Amazon Redshift 的零 ETL 整合可對 PB 級交易資料啟用近乎即時分析和機器學習 (ML) 功能，並讓您無需建置和管理複雜的資料管道。將資料寫入 RDS for MySQL 的數秒後，它就會複製到 Amazon Redshift。您可以將來自多個資料庫和資料表的資料，從 RDS for MySQL 合併至 Amazon Redshift。根據您的分析需求，特定資料庫和資料表的資料篩選可協助您選擇性地將資料帶入 Amazon Redshift 中。

您需要為使用 RDS for MySQL 和 Amazon Redshift 資源，建立及處理做為零 ETL 整合一部分而建立的變更資料付費。 這些資源包括植入及重新同步 Amazon Redshift 資料倉儲的 Amazon RDS 快照匯出成本、持續將資料變更從來源複寫至目標的變更資料擷取 (CDC) 資料傳輸成本、用來處理變更資料的一般 RDS I/O 和儲存空間，以及複製資料的一般 Amazon Redshift 儲存和運算成本。如需詳細資訊，請參閱 RDS for MySQL 定價頁面。

例如：您有一個 RDS for MySQL 8.0.32 資料庫和一個 Amazon Redshift 資料倉儲，執行於美國東部 (維吉尼亞北部) 區域。此 RDS for MySQL 資料庫執行個體目前使用 50 GB 的一般用途 SSD (gp3) 儲存容量，其中包含已佈建的基準 IOPS、已啟用自動備份，且已啟用 MySQL 二進位記錄。

當您為 RDS for MySQL 資料庫執行個體建立與 Amazon Redshift 的零 ETL 整合時，系統建立了資料快照 (50 GB)，並將其匯出以植入 Amazon Redshift 資料倉儲。第二天，您變更了 RDS for MySQL 資料庫執行個體中的資料表主索引鍵，這導致快照匯出重新同步至 Amazon Redshift。在 30 天內，資料庫處理了 5 GB 的資料變更。

在此範例中，30 天內在美國東部 (維吉尼亞北部) 區域使用 RDS for MySQL 與 Amazon Redshift 的零 ETL 整合的成本為 50 GB x (0.10 USD/GB) 初始匯出，加上 50 GB x (0.10 USD/GB) 重新同步成本，加上 5 GB x (2.00 USD/GB) CDC 資料傳輸，總計為 20.00 USD。除了這些零 ETL 整合的成本以外，您還需支付正常使用 Amazon RDS 和 Amazon Redshift 以處理複寫資料的費用 (例如 I/O、儲存和運算成本)。

可以，若要降低主要執行個體的資源消耗，您可以使用 Amazon RDS 讀取複本，作為來源 Amazon RDS 執行個體，與 Amazon Redshift 進行零 ETL 整合。

是的，您可以使用 AWS CloudFormation，管理和自動化 RDS for MySQL 與 Amazon Redshift 的零 ETL 整合所需資源的設定和部署。如需詳細資訊，請造訪 AWS CloudFormation 使用者指南。

RDS for MySQL 與 Amazon Redshift 的零 ETL 整合會以原子方式複寫交易，以確保來源 RDS for MySQL 資料庫與目標 Amazon Redshift 叢集之間的資料一致性。

以下是有關整合交易原子性的一些關鍵點：

• 唯有 RDS for MySQL 中已提交的交易才會複寫至 Amazon Redshift。不會套用未提交或回復的交易。
• 整合使用兩階段提交程序，以原子方式將每個交易套用至 Amazon Redshift。正常情況會套用交易中的所有資料變更，但若發生錯誤，則不會套用任何資料變更。
• 來源與目標之間會保持交易一致性。複寫後，RDS for MySQL 和 Amazon Redshift 中的給定交易資料會保持一致。
• 透過 DDL 或 DML 的結構描述變更也會以原子方式套用以維持完整性。
• 以原子方式套用交易可確保資料庫之間不會發生部分交易或不一致的資料狀態。

RDS for MySQL 與 Amazon Redshift 的零 ETL 整合會維持來源 RDS for MySQL 資料庫與目標 Amazon Redshift 叢集之間的完整交易一致性。

以下是關於如何處理結構描述變更的一些關鍵點：

• CREATE TABLE、ALTER TABLE、DROP TABLE 之類的 DDL 陳述式會自動從 RDS for MySQL 複製到 Amazon Redshift。
• 整合會針對複寫的結構描述變更，在 Amazon Redshift 表格中進行必要的檢查和調整。例如，在 RDS for MySQL 中新增一欄時，Amazon Redshift 中也會新增該欄。
• 複寫和結構描述同步近乎即時自動發生，如此來源與目標資料庫之間的延遲最低。
• 即使 DML 變更與 DDL 變更同時發生，也會保持結構描述的一致性。