共用方式為


適用於 MySQL 的 Azure 資料庫中的主要版本升級

附註

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

本文說明如何在適用於 MySQL 的 Azure 資料庫彈性伺服器中升級 MySQL 主要版本。 此功能可讓客戶執行主要版本升級 (例如,從 MySQL 5.7 升級至 8.0 或從 8.0 升級至 8.4),而無需移動資料或變更應用程式連接字串。

重要事項

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

先決條件

  • 具有舊 MySQL 版本的唯讀副本應在升級主要伺服器之前升級,以確保在不同 MySQL 版本之間的複寫相容性。 閱讀有關 MySQL 版本之間的複寫相容性的更多資訊。
  • 在升級您的生產環境伺服器之前,我們 Azure 入口網站中的內建驗證功能現在更簡單且更有效率。 此工具會預先檢查資料庫架構與目標 MySQL 版本的相容性,突出顯示潛在問題。 雖然我們提供此便利選項,但我們也強烈建議您使用官方 Oracle MySQL 升級檢查工具來測試您的資料庫結構描述相容性,並執行必要的迴歸測試,以驗證應用程式與新 MySQL 版本中已移除/的功能的相容性。
  • 在生產伺服器上執行主要版本升級之前,先觸發 隨選備份 。 升級前建立的備份可用於從完整的隨選備份復原至先前的版本
  • 繼續進行主要版本升級之前,請確定資料庫上沒有作用中或擱置中的 XA 交易,因為進行中的 XA 交易可能會導致升級程序失敗。 首先,若要避免此問題,請執行 XA RECOVER;來檢查任何處於「準備」狀態的 XA 交易。 針對識別的任何交易,請使用 XA ROLLBACK '{xid}';以復原每個交易,並將 {xid} 取代為交易識別碼。 在起始升級以維護交易一致性,並降低升級失敗的風險之前,請確定已認可或復原所有 XA 交易。

附註

當您使用 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 功能。 這些警告不會影響資料庫的功能。

使用 Azure 入口網站,針對可高載 SKU 伺服器,執行計劃性主要版本升級

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

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

  1. Azure 入口網站中,選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。

    重要事項

    建議您先在還原的伺服器複本上執行升級,而不是直接升級生產環境。 請參閱如何執行時間點還原

  2. 在 [概觀] 頁面上的工具列中,選取 [升級]。

    重要事項

    在升級之前,請造訪目標 MySQL 版本中 已移除功能 清單的連結。 使用 Azure 入口網站上的 [伺服器參數] 面板,確認已被棄用的 sql_mode 值,並從您目前的 Azure Database for MySQL 彈性伺服器中將其移除或取消選取,以避免部署失敗。 MySQL 8.0 及更新版本不再支援值為 NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS 和 NO_TABLE_OPTIONS 的sql_mode

    螢幕擷取畫面顯示適用於 MySQL 的 Azure 資料庫彈性伺服器升級。

  3. 結構描述相容性驗證

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

  4. 升級前決策

    升級之前,您必須選擇要升級的計算層,以執行主要版本升級。 根據預設,系統會從可高載 SKU 升級至最基本的一般用途 SKU,但您可以視需要升級至較高的計算層。 請注意,雖然您的伺服器在升級期間在「通用」層中運行,但您只需為此期間實際使用的「通用」資源付費。

  5. 升級後決策

    在升級後,決定是否要保留一般用途 SKU 或還原為可高載 SKU。 這個選擇會在初始升級步驟期間出現。

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

  6. 主要版本升級

    一旦升級計算層,系統就會起始主要版本升級程式。 透過 Azure 入口網站監視升級進度。 升級程序可能需要一些時間,視資料庫的大小和活動而定。 請注意,如果主要版本升級失敗,計算層將不會自動還原為先前的可高載 SKU。 這可讓客戶繼續主要版本升級,而不需要再次執行計算層升級。

  7. 自動還原

    根據您升級前的決策,系統會保留一般用途 SKU,或在升級後自動轉換為彈性 SKU。 如果您自動還原為可高載 SKU,則系統預設會還原為 B2S SKU。

使用 Azure 入口網站針對一般用途和業務關鍵性 SKU 伺服器執行計劃的主要版本升級

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

  1. Azure 入口網站中,選取您現有適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。

    重要事項

    建議您先在還原的伺服器複本上執行升級,而不是直接升級生產環境。 請參閱如何執行時間點還原

  2. 在 [概觀] 頁面上的工具列中,選取 [升級]。

    重要事項

    在升級之前,請造訪目標 MySQL 版本中 已移除功能 清單的連結。 使用 Azure 入口網站上的 [伺服器參數] 面板,確認已被棄用的 sql_mode 值,並從您目前的 Azure Database for MySQL 彈性伺服器中將其移除或取消選取,以避免部署失敗。 MySQL 8.0 及更新版本不再支援值為 NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS 和 NO_TABLE_OPTIONS 的sql_mode

    螢幕擷取畫面顯示適用於 MySQL 的 Azure 資料庫彈性伺服器升級。

  3. 執行升級前驗證

    在繼續升級之前,請選取 驗證 按鈕以檢查伺服器與目標 MySQL 版本的相容性。

    螢幕擷取畫面顯示 [驗證]。

    附註

    目前不支援 8.0 至 8.4 主要版本升級的線上驗證,建議客戶使用 社群工具 執行升級前驗證。 8.0 至 8.4 支援的線上驗證將在不久的將來提供。
    使用「驗證」功能來評估資料庫結構描述是否與目標 MySQL 版本相容時,請注意下列注意事項:

    • 驗證期間的表鎖定:驗證過程涉及鎖定表以準確檢查整個模式。 如果資料庫負載過重,可能會導致查詢逾時。   建議:避免在尖峰工作時間或資料庫處理高流量時執行驗證。 相反地,請在低活動期間排程驗證,以減少對作業的影響。
    • 由於大型結果集而可能停止回應:在某些情況下,特別是對於包含許多物件的複雜資料庫,驗證結果可能會變得過大,而無法在線上工作流程內處理或顯示。 這可能會導致「驗證」作業看起來停止回應或無限期進行中。   建議:如果您遇到此問題,建議您使用 Oracle 的官方用戶端升級檢查工具在本機執行驗證,例如 MySQL Shell 中包含的驗證。 此方法可避免平臺端的結果大小限制,並提供更詳細且可靠的驗證輸出。
    • 在線驗證的建議使用案例:在線「驗證」功能是針對簡單或中等複雜架構所設計。 對於大規模生產環境,例如具有數千個數據表、檢視、例程或其他架構對象的環境,我們強烈建議使用 Oracle 的用戶端升級檢查工具來執行相容性檢查。 這可確保全面分析完整的結構描述,並避免與結果大小或驗證逾時相關的潛在問題。
  4. [升級 ] 側邊欄的 [ 要升級的 MySQL 版本 ] 文字方塊中,驗證您要升級到的主要 MySQL 版本 (例如 8.0 或 8.4)。

    螢幕擷取畫面顯示 [升級]。

    您必須先升級任何相關的讀取副本伺服器,才能升級主要伺服器。 在完成此操作 之前,升級 將被停用。

  5. 在主要伺服器上,選取確認訊息以確認所有複本伺服器都已升級,然後選取 [升級]。

    螢幕擷取畫面顯示 [升級]。

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

使用 Azure CLI 執行計劃的主要版本升級

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

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

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

  2. 登入之後,請執行 az MySQL server upgrade 命令。

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

    {target major version} 替換為您要升級到的版本(例如,8 或 8.4)。

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

使用 Azure 入口網站對讀取副本伺服器進行主要版本升級

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

  1. 選取您現有的適用於 MySQL 的 Azure 資料庫彈性伺服器,並在 Azure 入口網站中讀取複本伺服器。

  2. 在 [概觀] 頁面上的工具列中,選取 [升級]。

    重要事項

    在升級之前,請造訪目標 MySQL 版本中 已移除功能 清單的連結。 使用 Azure 入口網站上的 [伺服器參數] 面板,確認已被棄用的 sql_mode 值,並從您目前的 Azure Database for MySQL 彈性伺服器中將其移除或取消選取,以避免部署失敗。

  3. [升級] 區段中,選取 [升級] ,將適用於 MySQL 的 Azure 資料庫彈性伺服器僅供讀取複本伺服器升級至目標主要版本。隨即顯示一則通知,確認升級成功。

  4. 在 [概觀] 頁面上,確認適用於 MySQL 的 Azure 資料庫彈性伺服器讀取複本伺服器正在執行目標版本。

  5. 前往您的主伺服器並執行主要版本升級。

使用讀取複本執行最小化停機時間的主要版本升級

若要使用僅供讀取複本伺服器執行適用於 MySQL 的 Azure 資料庫彈性伺服器的主要版本升級,並將停機時間降至最低,請執行下列步驟。

  1. 在 Azure 入口網站中選取您現有的適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。

  2. 從主要伺服器建立讀取複本

  3. 將您的讀取副本升級至目標主要版本。

  4. 確認複本伺服器正在執行目標版本之後,請停止應用程式連線到主要伺服器。

  5. 檢查複寫狀態,以確保複本已趕上主要複本,因此所有資料都同步,且不會在主要複本上執行任何新作業。

  6. 在複本伺服器上以 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值為 0 之後,可以放心地停止複寫。

  7. 藉由停止複寫,將您的讀取複本升階為主要複本。

  8. 將伺服器參數 read_only 設定為 0 (OFF),開始在升級後的主伺服器上進行寫入。

  9. 將應用程式指向執行目標版本的新主要 (先前複本) 版本。 每部伺服器都具有唯一的連接字串。 更新應用程式以指向 (先前) 複本,而非來源伺服器。

    附註

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