升級 Amazon Aurora MySQL 資料庫叢集的主要版本 - Amazon Aurora
從 Aurora MySQL 第 2 版升級至第 3 版Aurora 我的SQL主要版本升級路徑Aurora MySQL 就地主要版本升級的運作方式規劃 Aurora MySQL 叢集的主要版本升級

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

升級 Amazon Aurora MySQL 資料庫叢集的主要版本

在 Aurora MySQL 版本編號中，例如 2.12.1，2 代表主要版本。Aurora MySQL 第 2 版與 MySQL 5.7 相容。Aurora MySQL 第 3 版與 MySQL 8.0 相容。

在主要版本之間進行升級，需要比次要版本更廣泛的規劃和測試。該程序可能需要大量時間。升級完成後，您還可能需要進行後續工作。例如，這可能是因為SQL相容性或某些 My SQL相關功能的運作方式不同。或者，可能是因為舊版本和新版本之間的參數設定不同而發生。

內容

從 Aurora MySQL 第 2 版升級至第 3 版

如果您有 MySQL 5.7 相容叢集，並想要將其升級至 My SQL–8.0 相容叢集，您可以透過在叢集本身上執行升級程序來執行。這種升級為就地升級，與之形成對照的是，建立新叢集時所做的升級。這項技術會保留相同的端點和叢集的其他特性。升級速度相對較快，因為不需要將所有資料複製到新的叢集磁碟區。此穩定性有助於將應用程式中的任何組態變更降至最低。此外，還有助於減少已升級叢集的測試量。這是因為資料庫執行個體及其執行個體類別的數目都保持不變。

就地升級機制在操作時涉及關閉您的資料庫叢集。Aurora 會執行正常關閉並完成未完成的操作，例如交易回復和還原清除。如需詳細資訊，請參閱Aurora MySQL 就地主要版本升級的運作方式。

就地升級方法非常便捷，因為執行相關應用程式的組態變更非常簡單，並且可將組態變更降至最低。例如，就地升級會保留叢集的端點和資料庫執行個體集。不過，就地升級所需的時間可能會因結構描述的屬性，以及叢集的忙碌程度而有所差異。因此，視叢集的需求而定，您可以選擇下列升級技術：

  • 就地升級

  • 藍/綠部署

  • 快照還原

    注意

    如果您將 AWS CLI 或 RDSAPI用於快照還原升級方法，則必須執行後續操作，以在還原的資料庫叢集中建立寫入器資料庫執行個體。

如需 Aurora MySQL 第 3 版及其新功能的一般資訊，請參閱 Aurora MySQL 第 3 版與 MySQL 8.0 相容。

如需有關規劃升級的詳細資訊，請參閱 規劃 Aurora MySQL 叢集的主要版本升級 和 就地升級執行方式。

Aurora 我的SQL主要版本升級路徑

並非所有類型的 Aurora MySQL 叢集都可以使用就地升級機制。您可以參閱下表，了解每個 Aurora MySQL 叢集的適當升級路徑。

Aurora MySQL 資料庫叢集的類型 是否可以採用就地升級？ 動作

Aurora MySQL 佈建叢集，第 2 版

是

My 5.7 相容 Aurora MySQL 叢集支援SQL就地升級。

如需有關升級至 Aurora MySQL 第 3 版的資訊，請參閱 規劃 Aurora MySQL 叢集的主要版本升級和 就地升級執行方式。

Aurora MySQL 佈建叢集，第 3 版

不適用

使用次要版本升級程序，在 Aurora MySQL 第 3 版之間升級。

Aurora Serverless v1 叢集

不適用

Aurora Serverless v1 僅第 2 版支援 Aurora MySQL。

Aurora Serverless v2 叢集

不適用

 Aurora Serverless v2 僅第 3 版支援 Aurora MySQL。

Aurora 全域資料庫中的叢集

是

若要將 Aurora MySQL 從第 2 版升級至第 3 版，請遵循在 Aurora 全域資料庫中對叢集執行就地升級的程序。在全域叢集上執行升級。Aurora 會同時升級全域資料庫中的主要叢集和所有次要叢集。

如果您使用 AWS CLI 或 RDS API，請呼叫 modify-global-cluster命令或ModifyGlobalCluster操作，而不是 modify-db-cluster或 ModifyDBCluster。

如果lower_case_table_names參數已開啟，則無法執行從 Aurora MySQL 第 2 版到第 3 版的就地升級。如需詳細資訊，請參閱主要版本升級。

平行查詢叢集

是

您可以執行就地升級。

二進位日誌複寫目標的叢集

也許可以

如果二進位日誌複寫來自 Aurora MySQL 叢集，您可以執行就地升級。如果二進位日誌複寫來自 RDS for MySQL 或內部部署 MySQL 資料庫執行個體，則無法執行升級。在這種情況下，您可以使用快照還原機制進行升級。

具有零資料庫執行個體的叢集

否

您可以使用 AWS CLI 或 RDS 建立 Aurora MySQL 叢集API，而不需要任何連接的資料庫執行個體。同樣地，您也可以從 Aurora MySQL 叢集中移除所有資料庫執行個體，同時保持叢集磁碟區中的資料完整。雖然叢集具有零資料庫執行個體，但您無法執行就地升級。

升級機制需要叢集中的寫入器執行個體，才能對系統資料表、資料檔案等執行轉換。在此情況下，請使用 AWS CLI 或 RDSAPI為叢集建立寫入器執行個體。然後可以執行就地升級。

啟用恢復的叢集

是

您可以為使用 Backtrack 功能的 Aurora MySQL 叢集執行就地升級。不過升級之後，您無法將叢集恢復到升級前的時間。

Aurora MySQL 就地主要版本升級的運作方式

Aurora MySQL 會以多階段程序執行主要版本升級。您可以檢查升級的目前狀態。某些升級步驟也會提供進度資訊。隨著每個階段的開始，Aurora MySQL 會記錄事件。您可以在 RDS主控台的事件頁面上檢查事件發生的情況。如需使用事件的資訊，請參閱使用 Amazon RDS 事件通知。

重要

程序開始後即會執行，直至升級成功或失敗為止。升級進行中時，無法取消升級。如果升級失敗，Aurora 會復原所有變更，且您的叢集具有相同的引擎版本、中繼資料等，與之前一樣。

升級程序包含三個階段：

  1. Aurora 會在開始升級程序之前執行一系列預先檢查。Aurora 在執行這些檢查時，叢集會持續執行。例如，叢集不能有任何處於預備狀態的 XA 交易，或正在處理任何資料定義語言 （DDL） 陳述式。例如，您可能需要關閉提交特定類型SQL陳述式的應用程式。或者，您可以直接等到某些長時間執行的陳述式完成。然後再次嘗試升級。某些檢查會測試無法阻止升級，但可能會使升級需要很長時間的條件。

    如果 Aurora 偵測到不符合任何必要條件，請修改事件詳細資訊中識別的條件。請遵循 Aurora 疑難排解我的SQL就地升級 中的指引。如果 Aurora 偵測到可能導致升級緩慢的條件，請規劃長期監控升級。

  2. Aurora 會使叢集離線。然後 Aurora 會執行類似的一組測試，如上一階段，以確認關閉程序中沒有出現任何新問題。如果此時 Aurora 偵測到任何可能阻止升級的條件，Aurora 會取消升級並使叢集恢復線上狀態。在這種情況下，請確認條件何時不再適用，然後再次開始升級。

  3. Aurora 會建立叢集磁碟區的快照。假設您在升級完成後，發現相容性或其他類型的問題。或者，假設您想要同時使用原始叢集和升級的叢集來執行測試。在這種情況下，您可以從此快照還原，以建立具有原始引擎版本和原始資料的新叢集。

    提示

    此快照為手動快照。不過，即使您已達到手動快照的配額，Aurora 也可以建立快照並繼續進行升級程序。在您刪除快照之前，此快照會永久保留 （如有需要）。完成所有升級後測試之後，您可以刪除此快照，將儲存費用降至最低。

  4. Aurora 會複製您的叢集磁碟區。複製是一個快速操作，不涉及複製實際的資料表資料。如果在升級期間 Aurora 遇到問題，它會從複製的叢集磁碟區還原為原始資料，並使叢集恢復線上狀態。升級期間暫時複製的磁碟區不受單一叢集磁碟區複製數目的一般限制。

  5. Aurora 會執行寫入器資料庫執行個體的正常關閉。在正常關閉期間，進行下列操作的進度事件每 15 分鐘記錄一次。您可以在 RDS主控台的事件頁面上檢查事件發生的情況。

    • Aurora 會清除舊版本資料列的還原記錄。

    • Aurora 會復原任何未遞交的交易。

  6. Aurora 會升級寫入器資料庫執行個體上的引擎版本：

    • Aurora 會在寫入器資料庫執行個體上安裝新引擎版本的二進位檔。

    • Aurora 使用寫入器資料庫執行個體，將資料升級至 MySQL 5.7 相容格式。在此階段，Aurora 會修改系統資料表，並執行其他會影響叢集磁碟區中資料的轉換。特別是，Aurora 會將系統資料表中的分割區中繼資料升級為與 MySQL 5.7 分割區格式相容。如果叢集中的資料表具有大量的分割區，此階段可能需要很長時間。

      如果在此階段發生任何錯誤，您可以在我的SQL錯誤日誌中找到詳細資訊。在此階段開始之後，如果升級程序因任何原因失敗，Aurora 會從複製的叢集磁碟區還原該原始資料。

  7. Aurora 會升級讀取器資料庫執行個體上的引擎版本。

  8. 升級程序已完成。Aurora 會記錄最終事件，以指示升級程序已順利完成。現在，您的資料庫叢集正在執行新的主要版本。

規劃 Aurora MySQL 叢集的主要版本升級

為了協助您決定正確的時間和升級方法，您可以了解 Aurora MySQL 第 3 版與目前環境之間的差異：

您也可以在我的參考手冊 中的 MySQL 8.0 變更中找到更多 My SQL特定的升級考量和秘訣。 SQL 例如，您可以使用 命令mysqlcheck --check-upgrade來分析現有的 Aurora MySQL 資料庫，並識別潛在的升級問題。

注意

我們建議您在使用就地升級或快照還原技術升級至 Aurora MySQL 第 3 版時，使用較大的資料庫執行個體類別。範例為 db.r5.24xlarge 和 db.r6g.16xlarge。這有助於升級程序更快地完成，方法是使用資料庫執行個體上大多數的可用CPU容量。您可以在主要版本升級完成後變更為所需的資料庫執行個體類別。

完成升級本身後，您可以按照 Aurora 的升級後清理我的SQL版本 3 中的升級後程序來操作。最後，測試應用程式的功能和效能。

如果您要RDS從 MySQL 或社群 My 轉換SQL，請遵循 中說明的遷移程序將資料遷移到 Amazon Aurora 我的資料SQL庫叢集。在某些情況下，您可能會使用二進位日誌複寫，將資料與 Aurora MySQL 第 3 版叢集同步，作為遷移的一部分。如果是這樣，來源系統必須執行與您的目標資料庫叢集相容的版本。

若要確保在主要版本之間升級叢集之後，您的應用程式和管理程序可以順利運作，請進行一些預先規劃和準備。若要查看要更新 AWS CLI 指令碼或 RDS API型應用程式的管理程式碼類型，請參閱 就地升級如何影響叢集的參數群組。另請參閱Aurora MySQL 版本之間的叢集屬性變更。

若要了解升級期間可能遇到的問題，請參閱 Aurora 疑難排解我的SQL就地升級。對於可能導致升級需要很長時間的問題，您可以預先測試這些條件並進行更正。

注意

就地升級涉及在執行操作時關閉資料庫叢集。Aurora MySQL 會執行乾淨的關機，並完成未完成的操作，例如復原清除。如果有許多復原記錄需要清除，則升級可能需要很長的時間。我們建議僅在歷史記錄清單長度 （HLL） 很短之後才執行升級。的普遍可接受值HLL為 100，000 或更少。如需詳細資訊，請參閱此部落格文章 。

透過複製資料庫叢集來模擬升級

您可以針對升級的叢集檢查應用程式相容性、效能、維護程序和類似考量。若要這樣做，您可以在進行真正的升級之前執行升級的模擬。此技術對於生產叢集特別有用。在此，務必將停機時間降至最低，並在升級完成後立即準備好升級的叢集。

使用下列步驟：

  1. 建立原始叢集的複製。請遵循 複製 Amazon Aurora 資料庫叢集的一個磁碟區 中的程序。

  2. 設定與原始叢集相似的一組寫入器和讀取器資料庫執行個體。

  3. 執行複製叢集的就地升級。請遵循 就地升級執行方式 中的程序。

    建立複製後立即開始升級。如此一來，叢集磁碟區仍與原始叢集的狀態相同。如果複製在進行升級之前閒置，Aurora 會在後台執行資料庫清除程序。在這種情況下，複製的升級並非正確的升級原始叢集模擬。

  4. 使用複製的叢集測試應用程式相容性、效能、管理程序等。

  5. 如果您遇到任何問題，請調整升級計劃以解決這些問題。例如，調整任何應用程式的程式碼，以便與更高版本的功能集相容。根據叢集中的資料量，估計升級可能需要多長時間。您還可以選擇在叢集不忙碌的時間排程升級。

  6. 在您對應用程式和工作負載適當地使用測試叢集感到滿意之後，即可執行生產叢集的就地升級。

  7. 在主要版本升級期間，努力將叢集的總停機時間降到最低。若要這樣做，請確定叢集上的工作負載在升級時很低或為零。特別是，請確定在您啟動升級時，沒有長時間執行的交易正在進行。

藍/綠部署

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