升級 Amazon Aurora 我的SQL資料庫叢集的主要版本 - Amazon Aurora
從 Aurora 升級我的SQL版本 2 到版本 3規劃 Aurora 我的SQL叢集的主要版本升級

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

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

在 Aurora 我的SQL版本號（例如 2.12.1）中，2 代表主要版本。Aurora 我的SQL版本 2 與我的 SQL 5.7 兼容。Aurora 我的SQL版本 3 與我的 SQL 8.0 兼容。

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

內容

從 Aurora 升級我的SQL版本 2 到版本 3

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

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

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

  • 就地升級

  • 藍色/綠色部署

  • 快照還原

    注意

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

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

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

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

為了幫助您決定正確的升級時間和方法，您可以了解 Aurora My SQL 版本 3 和目前環境之間的差異：

您也可以在「我的SQL參考手冊」的「我的 SQL8.0」中的「變更」中找到更多「我的SQL特定升級注意事項」和提示 例如，您可以使用命令mysqlcheck --check-upgrade來分析現有的 Aurora My SQL 資料庫，並識別潛在的升級問題。

注意

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

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

如果您要RDS從「我的」SQL 或「我的社群」轉換SQL，請依照中所述的移轉程序進行將資料遷移到 Amazon Aurora 我的資料SQL庫叢集。在某些情況下，您可能會使用二進位記錄複寫，將資料與 Aurora My Ver SQL sion 3 叢集同步，做為移轉的一部分。如果是這樣，來源系統必須執行與目標資料庫叢集相容的版本。

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

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

注意

就地升級涉及在作業發生時關閉資料庫叢集。Aurora My SQL 執行全新關機並完成未完成的作業，例如還原清除。如果要清除許多還原記錄，則升級可能需要很長時間。我們建議您只在歷史記錄列表長度（HLL）很低之後執行升級。通常可接受的值HLL為 100,000 或更少。如需詳細資訊，請參閱此部落格文章。

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

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

使用下列步驟：

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

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

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

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

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

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

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

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

使用藍綠色升級技術

您也可以建立執行舊叢集和新叢集 side-by-side的藍/綠部署。在這裡，您會將舊叢集的資料複寫到新叢集，直至您準備好接管新叢集。如需詳細資訊，請參閱 使用 Amazon RDS 藍/綠部署進行資料庫更新。