升級 Aurora MySQL 資料庫叢集的次要版本或修補程式層級

您可以使用下列方法來升級資料庫叢集的次要版本或修補資料庫叢集：

• 透過修改引擎版本升級 Aurora MySQL (適用於 Aurora MySQL 第 2 版和第 3 版)

• 啟用次要 Aurora MySQL 版本之間的自動升級

如需零停機時間修補如何在升級程序期間減少中斷的相關資訊，請參閱使用零停機時間修補。

在執行次要版本升級之前

建議您執行下列動作，以減少次要版本升級期間的停機時間：

• Aurora 資料庫叢集維護應在低流量期間執行。使用 Performance Insights 識來識別這些時段，以便正確設定維護時段。如需 Performance Insights 的詳細資訊，請參閱使用 Amazon RDS 上的 Performance Insights 監控資料庫負載。如需資料庫叢集維護時段的詳細資訊，請參閱調整偏好的資料庫叢集維護時段.

• 使用支援指數輪詢和抖動的 AWS SDK 做為最佳實務。如需詳細資訊，請參閱指數輪詢和抖動。

Aurora MySQL 的次要版本升級預先檢查

當您開始次要版本升級時，Amazon Aurora 會自動執行預先檢查。

系統會強制執行這些前置檢查，您無法選擇略過這些檢查。前置檢查提供以下優勢：

• 升級期間可避免非預期的停機時間。

• 如果有不相容的問題，Amazon Aurora 會阻止升級，並提供日誌供您了解這些問題。然後，您可以透過減少不相容性，使用記錄來準備資料庫以進行升級。如需移除不相容性的詳細資訊，請參閱 MySQL 說明文件中的準備安裝以進行升級。

前置檢查會在系統將資料庫執行個體停止以進行升級前執行，意即前置檢查執行期間不會造成任何停機時間。如果預先檢查發現不相容，Aurora 會在資料庫執行個體停止之前自動取消升級。Aurora 也會產生不相容的事件。如需有關 Amazon Aurora 事件的詳細資訊，請參閱使用 Amazon RDS 事件通知。

Aurora 會在記錄檔PrePatchCompatibility.log中記錄每個不相容性的詳細資訊。在多數情況下，日誌項目包含修正不相容的 MySQL 文件連結。如需檢視日誌檔案的詳細資訊，請參閱檢視並列出資料庫日誌檔案。

根據前置檢查的特性，這些檢查作業會分析資料庫中的物件。此分析會耗用資源，並增加升級完成的時間。

透過修改引擎版本升級 Aurora MySQL

升級 Aurora MySQL 資料庫叢集的次要版本會將其他修正程式和新功能套用至現有叢集。

這種升級適用於 Aurora MySQL 叢集，其中原始版本和升級版本都具有相同的 Aurora MySQL 主要版本，無論是 2 或 3。此程序既快速又直接，因為它不涉及 Aurora MySQL 中繼資料的任何轉換或資料表資料的重組。

您可以使用、或 RDS API 修改資料庫叢集的引擎版本 AWS Management Console AWS CLI，以執行這種升級。例如，如果您的叢集執行 Aurora MySQL 2.x，請選擇較高的 2.x 版本。

如果要針對 Aurora 全域資料庫執行次要升級，請先升級所有次要叢集，再升級主要叢集。

注意

若要執行次要版本升級至 Aurora MySQL 3.03.* 版及更新版本，或 2.12 * 版，請遵循下列操作：

1. 從全域叢集移除所有次要區域。請遵循 從 Amazon Aurora 全域資料庫中移除叢集 中的步驟。

2. 將主要區域的引擎版本升級至 3.03.* 或更新版本，或 2.12.* 版 (如適用)。請遵循 To modify the engine version of a DB cluster 中的步驟。

3. 將次要區域新增至全域叢集。請遵循 將 AWS 區域 新增到 Amazon Aurora 全域資料庫 中的步驟。

修改資料庫叢集的引擎版本

• 使用主控台 – 修改叢集的屬性。在 Modify DB cluster (修改資料庫叢集) 視窗中，變更 DB engine version (資料庫引擎版本) 方塊中的 Aurora MySQL 引擎版本。如果您不熟悉修改叢集的一般程序，請遵循 使用主控台、CLI 和 API 修改資料庫叢集 中的指示。

• 使用 AWS CLI — 呼叫修改-db-cluster AWS CLI 命令，並指定選項的資料庫叢集名稱，並指定--db-cluster-identifier選項的引擎版本。--engine-version

  例如，若要升級至 Aurora MySQL 2.12.1 版，請將--engine-version5.7.mysql_aurora.2.12.1選項設定為。指定 --apply-immediately 選項以立即更新資料庫叢集的引擎版本。

• 使用 RDS API – 呼叫 ModifyDBCluster API 操作，並在 DBClusterIdentifier 參數中指定資料庫叢集的名稱，在 EngineVersion 參數中指定引擎版本。將 ApplyImmediately 參數設為 true，以立即更新資料庫叢集的引擎版本。

啟用次要 Aurora MySQL 版本之間的自動升級

對於 Amazon Aurora MySQL 資料庫叢集，您可以指定 Aurora 會自動將資料庫叢集升級為新的次要版本。您可以透過設定資料庫叢集的AutoMinorVersionUpgrade屬性 (中的自動次要版本升級 AWS Management Console) 來完成此作業。

自動升級會在維護時段期間進行。如果資料庫叢集中的個別資料庫執行個體維護時段不同於叢集維護時段，則會優先考慮叢集維護時段。

自動次要版本升級不適用於下列類型的 Aurora MySQL 叢集：

• 屬於 Aurora 全域資料庫一部分的叢集

• 具有跨區域複本的叢集

中斷持續時間視工作負載、叢集大小、二進位記錄資料的數量，以及 Aurora 是否可使用零停機時間修補 (ZDP) 功能而定。Aurora 會重新啟動資料庫叢集，因此在繼續使用叢集之前，您可能會遇到短暫無法使用的狀況。特別是二進位日誌資料的數量會影響復原時間。資料庫執行個體會在復原期間處理二進位記錄資料。因此，大量的二進位記錄資料會增加復原時間。

注意

Aurora 只會在資料庫叢集中的所有資料庫執行個體都啟用此AutoMinorVersionUpgrade設定時執行自動升級。如需如何設定，以及在叢集和執行個體層級套用時如何運作的資訊，請參閱 Aurora 資料庫叢集的自動次要版本升級。

然後，如果將資料庫叢集執行個體的升級路徑存在為已AutoUpgrade設定為 true 的次要資料庫引擎版本，則會進行升級。此AutoUpgrade設定是動態的，由 RDS 設定。

自動次要版本的升級會執行至預設次要版本。

您可以使用下列 CLI 命令來檢查 Aurora MySQL 叢集中所有資料庫執行個體的AutoMinorVersionUpgrade升級設定狀態。

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

此命令會產生類似下列的輸出：

[
  {
      "DBInstanceIdentifier": "db-t2-medium-instance",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-t2-small-original-size",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "instance-2020-05-01-2332",
      "DBClusterIdentifier": "cluster-57-2020-05-01-4615",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

在此範例中，資料庫叢集 cluster-57-2020-06-03-6411 的啟用自動次要版本升級已關閉，因為叢集的其中一個資料庫執行個體已關閉此功能。

使用零停機時間修補

執行資料 Aurora MySQL 資料庫叢集的升級牽涉到資料庫關閉和升級時發生中斷的可能性。根據預設，如果您在資料庫忙碌時開始升級，則會遺失資料庫叢集正在處理的所有連線和交易。如果您要等到資料庫閒置才執行升級，就可能必須等待很長時間。

零停機時間修補 (ZDP) 功能以最佳作法為基礎，試圖在整個 Aurora MySQL 升級過程維持用戶端正常連線。如果 ZDP 成功完成，即可保留應用程式工作階段，資料庫引擎也會在升級期間重新啟動。資料庫引擎重新啟動可能會導致輸送量下降，持續時間為數秒到一分鐘左右。

ZDP 不適用於下列項目：

• 作業系統 (OS) 修補程式與升級

• 主要版本升級

ZDP 適用於所有受支援的 Aurora MySQL 版本和資料庫執行個體類別。

Aurora Serverless v1 或 Aurora 全球資料庫不支援 ZDP。

注意

建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需詳細了解 T 執行個體類別，請參閱 使用 T 執行個體類別進行開發和測試。

您可以在 MySQL 錯誤日誌中查看 ZDP 期間重要屬性的指標。您也可以在 AWS Management Console中的 Events (事件) 頁面上，查看 Aurora MySQL 何時使用 ZDP 或選擇不使用 ZDP 的相關資訊。

在 Aurora MySQL 2.10 和更新版本以及版本 3 中，不論是否啟用二進位日誌複寫功能，Aurora 皆可執行零停機時間修補。若啟用二進位日誌複寫功能，Aurora MySQL 會在 ZDP 操作期間自動中斷與 binlog 目標的連線。Aurora MySQL 會在重新啟動完成後，自動重新連線到 binlog 目標並繼續複寫。

ZDP 也可與 Aurora MySQL 2.10 及更高版本中的重新開機增強功能搭配使用。修補寫入器資料庫執行個體會同時自動修補讀取器。執行修補程式之後，Aurora 會恢復寫入器和讀取器資料庫執行個體上的連線。在 Aurora MySQL 2.10 之前，ZDP 僅適用於叢集的寫入器資料庫執行個體。

若有以下情況，ZDP 便可能無法成功完成：

• 長時間執行的查詢或交易正在進行中 如果 Aurora 可以在此情況下執行 ZDP，則會取消任何開啟的交易。

• 暫存資料表或資料表鎖定正在使用中，例如資料定義語言 (DDL) 陳述式執行時。如果 Aurora 可以在此情況下執行 ZDP，則會取消任何開啟的交易。

• 存在擱置中的參數變更。

若因為一或多個上述條件而無執行 ZDP 的合適時段，修補作業會還原至標準行為。

注意

對於低於 2.11.0 的 Aurora MySQL 第 2 版和低於 3.04.0 的第 3 版，當開啟 Secure Socket Layer (SSL) 或 Transport Layer Security (TLS) 連線時，ZDP 可能無法成功完成。

雖然在成功的 ZDP 操作之後連線仍保持不變，但某些變數和功能會重新初始化。下列類型的資訊在零停機修補所造成的重新啟動時不會保留：

• 全域變數。Aurora 會恢復工作階段變數，但它不會在重新啟動後恢復全域變數。

• 狀態變數。特別是，引擎狀態報告的正常執行時間值會在使用 ZDR 或 ZDP 機制的重新啟動之後重設。

• LAST_INSERT_ID.

• 資料表的記憶體內 auto_increment 狀態。記憶體內的自動增量狀態會重新初始化。如需自動增量值的詳細資訊，請參閱 MySQL 參考手冊。

• 來自 INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA 資料表的診斷資訊。這項診斷資訊也會出現在 SHOW PROFILE 和 SHOW PROFILES 等命令的輸出中。

Events (事件) 頁面會報告下列與零停機時間重新啟動相關的活動：

• 嘗試在零停機時間的情況下升級資料庫。

• 嘗試在零停機時間的情況下升級資料庫已完成。事件會報告程序所花費的時間。此事件也會報告重新啟動期間保留的連線數目，以及已中斷的連線數目。您可以查閱資料庫錯誤日誌，瞭解重新啟動期間所發生情況的相關詳細資訊。

替代藍/綠升級技術

在某些情況下，您的首要目標是立即從舊叢集切換至升級的叢集。在這種情況下，您可以使用執行舊叢集和新叢集 side-by-side的多步驟處理序。在這裡，您會將舊叢集的資料複寫到新叢集，直至您準備好接管新叢集。如需詳細資訊，請參閱 使用 Amazon RDS 藍/綠部署進行資料庫更新。