適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中的主要版本升級

發行項
08/15/2024

適用於：適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

注意

本文包含「從屬」一詞的參考，Microsoft 已不再使用該字詞。從軟體中移除該字詞時，我們也會將其從本文中移除。

本文說明如何在適用於 MySQL 的 Azure 資料庫 - 彈性伺服器中就地升級您的 MySQL 主要版本。此功能可讓客戶能夠將他們的 MySQL 5.7 伺服器就地升級到 MySQL 8.0，而不必移動任何資料或變更任何應用程式連接字串。

重要

停機的持續時間會根據資料庫執行個體的大小及其包含的資料表數目而有所不同。
透過 Rest API 或 SDK 起始適用於 MySQL 的 Azure 資料庫彈性伺服器的主要版本升級時，請避免在相同的要求中修改服務的其他屬性。系統不允許同時進行變更，而且可能會導致未預期的結果或要求失敗。請在升級完成後，再透過單獨作業進行屬性修改。
某些工作負載從 5.7 升級至 8.0 之後，可能不會表現出增強效能。建議您先建立複本伺服器 (作為測試伺服器)，再將其升級為獨立伺服器，然後在測試伺服器上執行工作負載，再於實際執行環境中實作升級，進而評估工作負載的效能。
升級主要 MySQL 版本是無法復原的。如果驗證識別伺服器已設定為已移除或已淘汰的任何功能，您的部署可能會失敗。您可以在伺服器上進行必要的組態變更，然後重試升級。

必要條件

使用 MySQL 5.7 版的讀取複本應在主要伺服器之前升級，以便複寫能在不同的 MySQL 版本之間相容，請進一步閱讀：MySQL 版本之間的複寫相容性。
在升級您的生產環境伺服器之前，我們 Azure 入口網站中的內建驗證功能現在更簡單且更有效率。此工具會預先檢查您的資料庫結構描述與 MySQL 8.0 的相容性，並醒目提示潛在問題。雖然我們提供這個方便的選項，但我們也強烈建議您使用官方 Oracle MySQL 升級檢查程式工具來測試資料庫結構描述相容性，並執行必要的迴歸測試，以驗證與新 MySQL 版本中已移除/已淘汰功能的應用程式相容性。

注意

當您使用 Oracle 的官方工具來檢查結構描述相容性時，可能會遇到一些警告，指出預存程序中存在未預期的權杖，例如：mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode 您可以放心地忽略這些警告。它們指的是以 mysql. 為前置詞的內建預存程序，可用於支援 Azure MySQL 功能。這些警告並不會影響資料庫的功能。
在生產伺服器上執行主要版本升級之前，請先觸發隨選備份，這可用來從所建立的完整隨選備份中復原為 5.7 版。

使用適用於高載 SKU 伺服器的 Azure 入口網站，執行從 MySQL 5.7 到 MySQL 8.0 的計劃性主要版本升級

針對適用於 MySQL 的 Azure 資料庫高載 SKU 計算層級執行主要版本升級需要特製化的工作流程。這是因為主要版本升級需要大量資源，需要大量的 CPU 和記憶體。以額度為基礎的高載 SKU 執行個體可能會難以滿足這些需求，進而導致升級程序失敗。因此，升級高載 SKU 時，系統會先將計算層升級至一般用途 SKU，以確保有足夠的資源可供升級使用。

若要使用 Azure 入口網站執行適用於 MySQL 的 Azure 資料庫高載 SKU 計算層的主要版本升級，請遵循下列步驟：

在 Azure 入口網站中，選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器。

重要

建議您先在還原的伺服器複本上執行升級，而不是直接升級生產環境。請參閱如何執行時間點還原。
在 [概觀] 頁面上的工具列中，選取 [升級]。

重要

在升級之前，請先造訪 MySQL 8.0 中已移除的功能清單的連結。使用 Azure 入口網站上的 [伺服器參數] 刀鋒視窗，確認已淘汰的 sql_mode 值，並從目前適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器中移除/取消選取這些值，以避免部署失敗。 MySQL 8.0 不再支援具有 NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS 和 NO_TABLE_OPTIONS 值的 sql_mode。
結構描述相容性驗證

繼續進行升級之前，請執行 Oracle 的官方 MySQL 升級檢查工具，以驗證目前的資料庫結構描述是否與 MySQL 8.0 相容。此步驟對於確保順暢的升級程序至關重要。
升級前決策

在繼續進行升級之前，您必須選擇要升級的計算層來執行主要版本升級。根據預設，系統會從高載 SKU 升級至最基本的一般用途 SKU，但您可以視需要選擇升級至較高的計算層。

注意

當您的伺服器在升級期間在「一般用途」層中運作時，您只需為在此期間使用的實際「一般用途」資源支付費用。
升級後決策

決定是否要在升級後保留一般用途 SKU 或還原為高載 SKU。在初始升級步驟期間，系統將會提示此選擇。

系統會自動將計算層從高載 SKU 升級至選取的一般用途 SKU，以支援主要版本升級。
主要版本升級

升級計算層之後，系統會起始主要版本升級程序。透過 Azure 入口網站監視升級進度。升級程序可能需要一些時間，視資料庫的大小和活動而定。

注意

如果主要版本升級失敗，計算層將不會自動還原為先前的高載 SKU。這可讓客戶繼續進行主要版本升級，而不需要再次執行計算層升級。
自動還原

根據您的升級前決策，系統將會保留一般用途 SKU，或在升級完成後自動還原為高載 SKU。

注意

如果您選擇自動還原為高載 SKU，系統預設會還原為 B2S SKU。

使用適用於一般用途和業務關鍵 SKU 伺服器的 Azure 入口網站，執行從 MySQL 5.7 到 MySQL 8.0 的計劃性主要版本升級

若要使用 Azure 入口網站來執行適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器的主要版本升級，請執行下列步驟。

在 Azure 入口網站中，選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器。

重要

建議您先在還原的伺服器複本上執行升級，而不是直接升級生產環境。請參閱如何執行時間點還原。
在 [概觀] 頁面上的工具列中，選取 [升級]。

重要

在升級之前，請先造訪 MySQL 8.0 中已移除的功能清單的連結。使用 Azure 入口網站上的 [伺服器參數] 刀鋒視窗，確認已淘汰的 sql_mode 值，並從目前適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器中移除/取消選取這些值，以避免部署失敗。 MySQL 8.0 不再支援具有 NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS 和 NO_TABLE_OPTIONS 值的 sql_mode。
執行升級前驗證

繼續升級之前，請按一下 [驗證] 按鈕，檢查您的伺服器與 MySQL 8.0 的相容性。

重要

當您使用「驗證」功能來檢查資料庫結構描述是否與 MySQL 8.0 相容時，請注意其會涉及鎖定資料表以正確評估整個結構描述。此流程可能會導致查詢逾時。因此，建議您不要在尖峰上班時間或資料庫遇到高流量時執行驗證。選擇低活動期間進行驗證，將有助於將作業的影響降到最低。
在 [升級] 側邊欄中，在 [要升級的 MySQL 版本] 文字方塊中，確認您要升級的主要 MySQL 版本，即 8.0。

在升級主要伺服器之前，您必須先升級任何相關聯的讀取複本伺服器。在完成此作業之前，會停用升級。
在主要伺服器上，選取確認訊息以確認所有複本伺服器都已升級，然後選取 [升級]。

在讀取複本和獨立伺服器上，依預設會啟用升級。

使用 Azure CLI，執行從 MySQL 5.7 到 MySQL 8.0 的計劃性主要版本升級

若要使用 Azure CLI 來執行適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器的主要版本升級，請執行下列步驟。

安裝適用於 Windows 的 Azure CLI，或在 Azure Cloud Shell 中使用 Azure CLI，以執行升級命令。

此升級需要 2.40.0 版或更新版本的 Azure CLI。若您使用的是 Azure Cloud Shell，即已安裝最新版本。執行 az version 以尋找已安裝的版本和相依程式庫。若要升級至最新版本，請執行 az upgrade。

登入之後，請執行 az mysql server upgrade 命令。

az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version 8

在確認提示下，輸入 y 以確認，或輸入 n 以停止升級程序，然後按 Enter 鍵。

使用 Azure 入口網站，在讀取複本伺服器上執行從 MySQL 5.7 至 MySQL 8.0 的主要版本升級

若要使用 Azure 入口網站，在讀取複本上執行適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器至 MySQL 8.0 的主要版本升級，請執行下列步驟。

在 Azure 入口網站中，選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 讀取複本伺服器。
在 [概觀] 頁面上的工具列中，選取 [升級]。

重要

在升級之前，請先造訪 MySQL 8.0 中已移除的功能清單的連結。使用 Azure 入口網站上的 [伺服器參數] 刀鋒視窗，確認已淘汰的 sql_mode 值，並從目前適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器中移除/取消選取這些值，以避免部署失敗。

在 [升級] 區段中，選取 [升級]，以將適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 讀取複本伺服器升級至 MySQL 8.0。

出現一則通知，確認升級成功。
在 [概觀] 頁面上，確認適用於 MySQL 的 Azure 資料庫彈性伺服器讀取複本伺服器正在執行 8.0 版。
現在，移至主要伺服器，並在其上執行主要版本升級。

使用讀取複本，執行從 MySQL 5.7 至 MySQL 8.0 最短停機的主要版本升級

若要使用讀取複本伺服器，執行從適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器至 MySQL 8.0 的主要版本升級 (具有最短停機時間)，請執行下列步驟。

在 Azure 入口網站中，選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器 5.7 伺服器。
從主要伺服器建立讀取複本。
將您的讀取複本升級至 8.0 版。
確認複本伺服器正在執行 8.0 版之後，請停止讓應用程式連線到主要伺服器。
檢查複寫狀態，以確保複本已趕上主要伺服器，讓所有資料都處於同步狀態，而且主要複本上不會執行任何新作業。
在複本伺服器上以 show replica status 命令進行確認，以檢視複寫狀態。
```
 SHOW SLAVE STATUS\G
```
如果 Slave_IO_Running 和 Slave_SQL_Running 的狀態皆為 yes，且 Seconds_Behind_Master 的值為 0，則複寫可以運作良好。 Seconds_Behind_Master 會指出複本的延遲時間。若該值不是 0，則代表複本仍然正在處理更新。確認 Seconds_Behind_Master 的值為 **** 之後，可以放心地停止複寫。
藉由停止複寫，將您的讀取複本升階為主要複本。
將伺服器參數 read_only 設定為 0 (OFF)，以開始在升級的主要複本上寫入。
將您的應用程式指向執行伺服器 8.0 的新主要複本 (先前稱為複本)。每部伺服器都具有唯一的連接字串。更新應用程式以指向 (先前) 複本，而非來源伺服器。

注意

此情節範例只會在步驟 4 到 7 期間導致停機。

常見問題集

這是否會造成伺服器的停機，如果是的話，停機時間多久？

若要在升級期間將停機時間降到最小，請按照以下所提的步驟進行：使用讀取複本執行從 MySQL 5.7 到 MySQL 8.0 的最低停機時間主要版本升級。在升級過程中伺服器將無法使用，因此建議您在計劃性維護期間執行這項作業。預估的停機取決於資料庫大小、佈建的儲存體大小 (已佈建 IOP) 和資料庫上的資料表數目。升級時間與伺服器上的資料表數量成正比。若要預估伺服器環境的停機，建議您先在伺服器的還原複本上執行升級。
升級後我的備份會發生什麼事？

在主要版本升級之前，所有已進行的備份 (自動/隨選) (當用於還原時)，一律會還原為舊版 (5.7) 的伺服器。在主要版本升級之後，所有已進行的備份 (自動/隨選)，都會還原為升級版 (8.0) 的伺服器。強烈建議先進行隨選備份，再執行主要版本升級以輕鬆復原。
我目前使用可高載 SKU，Microsoft 是否計劃在未來針對此 SKU 支援主要版本升級？

高載 SKU 無法支援主要版本升級，原因是此 SKU 的效能限制。

如果您需要在適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體上執行主要版本升級，而且目前使用高載 SKU，一個暫時的解決方案是升級至一般用途或業務關鍵 SKU，執行升級後再切換回高載 SKU。

請注意，升級至較高的 SKU 可能會涉及定價變更，並可能導致部署成本增加。不過，由於升級流程預期不需要很長的時間，因此增加的成本應該不多。

下一步

針對您的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體，深入了解如何設定排程維護。
了解 MySQL 8.0 版的新功能。

共用方式為