ApsaraDB RDS：升級資料庫版本

選擇升級方式

方式一：通過控制台直接升級資料庫版本與方式二：通過資料移轉DTS升級資料庫版本支援MySQL 5.5升級至5.6、5.6升級至5.7、5.7升級至8.0、8.0升級至8.4。在升級資料庫前，您需要通過以下內容選擇合適的升級方式：

• 執行個體規格符合以下四種類型，且執行個體配置滿足對應類型的要求，建議通過方式一：通過控制台直接升級資料庫版本。

  說明

  • Serverless執行個體不支援通過控制台直接升級，建議使用方式二：通過資料移轉DTS升級資料庫版本。

  叢集系列（ESSD雲端硬碟、高效能雲端硬碟）

  • 組複製限制：不支援使用組複製（MGR）的叢集系列執行個體升級。

  • 資料庫代理限制（如有）：5.7升級至8.0時，資料庫代理小版本不低於1.13.41；8.0升級至8.4時，資料庫代理小版本不低於2.25.11。

  • 執行個體狀態限制：執行個體狀態為執行中，主備節點狀態健康且無延遲。

  • 引擎節流：資料庫及所有庫表都為InnoDB引擎。

  • 不屬於已下線的歷史規格。

  高可用系列（ESSD雲端硬碟、高效能雲端硬碟）

  • 資料庫代理限制（如有）：5.7升級至8.0時，資料庫代理小版本不低於1.13.41；8.0升級至8.4時，資料庫代理小版本不低於2.25.11。

  • 執行個體狀態限制：執行個體狀態為執行中，主備節點狀態健康且無延遲。

  • 引擎節流：資料庫及所有庫表都為InnoDB引擎。

  • 不屬於已下線的歷史規格。

  高可用系列（高效能本地碟）

  • 加密限制：未開啟TDE加密功能（TDE開啟後不支援關閉，如已開啟TDE，請選擇方式二：通過資料移轉DTS升級資料庫版本進行升級）。

  • 資料庫代理限制（如有）：5.7升級至8.0時，資料庫代理小版本不低於1.13.41；8.0升級至8.4時，資料庫代理小版本不低於2.25.11。

  • 執行個體狀態限制：執行個體狀態為執行中，主備節點狀態健康且無延遲。

  • 表數量限制：不超過100萬張。

  • 引擎節流：資料庫及所有庫表都為InnoDB引擎。

  • 規格限制：升級後的資料庫版本必須支援原執行個體規格（含主執行個體和唯讀執行個體），且不屬於已下線的歷史規格，詳情請參見RDS MySQL主執行個體規格。

  基礎系列（ESSD雲端硬碟、高效能雲端硬碟）

  • 執行個體狀態限制：執行個體狀態為執行中。

  • 引擎節流：資料庫及所有庫表都為InnoDB引擎。

  • 不屬於已下線的歷史規格。

• 執行個體規格不符合以上四種類型或已經開啟TDE加密功能，請使用方式二：通過資料移轉DTS升級資料庫版本。

• 執行個體規格符合以上四種類型，但執行個體配置不滿足相關要求，您可以參考下表方案修改配置後，使用方式一：通過控制台直接升級資料庫版本，或使用方式二：通過資料移轉DTS升級資料庫版本。

  問題	解決方案
  執行個體處於其它狀態（如重啟中）	等待任務結束後再發起資料庫版本升級任務。
  高可用系列高效能本地碟執行個體表數量超過100萬張	在升級前清理冗餘表。
  部分庫表未使用InnoDB引擎	使用ALTER TABLE <表名> engine=InnoDB;命令轉換為InnoDB引擎。
  執行個體規格為歷史規格	進行規格升級後再升級資料庫版本，更多資訊請參見變更配置。
  資料庫代理小版本不符合要求	升級資料庫小版本至1.13.41及以上，詳情請參見升級資料庫代理核心小版本。
  執行個體儲存類型為SSD雲端硬碟	將SSD雲端硬碟升級為ESSD雲端硬碟後，再升級資料庫版本。

其它引擎升級資料庫版本請參見：

• RDS PostgreSQL升級資料庫大版本

• RDS SQL Server升級資料庫大版本

方式一：通過控制台直接升級資料庫版本

方式二：通過資料移轉DTS升級資料庫版本

對於不支援通過控制台直接升級的執行個體，您可以建立一個高資料庫版本的新執行個體，通過DTS資料移轉任務將原執行個體資料移轉至新執行個體中，實現資料庫的間接升級，相關步驟如下：

1. 建立新執行個體

2. 資料移轉至新執行個體

3. 釋放原執行個體

舉例：您有一個開啟了TDE功能的MySQL 5.7執行個體，其不能通過控制台直接升級資料庫版本。此時，您可以建立一個資料庫版本為MySQL 8.0的新執行個體，然後將原執行個體中的資料移轉至新執行個體，最後釋放原執行個體，實現資料庫版本的間接升級。

附錄一：MySQL 8.0升級MySQL 8.4的優勢

• 增強長期穩定性。MySQL 8.4是LTS版本，適合生產環境長期使用，後續8.4.x以穩定性、安全修複和相容維護為主。

• 增強認證能力。支援WebAuthn/FIDO2認證，Enterprise Edition可使用安全密鑰、生物識別技術等認證方式；Windows上支援SASL LDAP/GSSAPI/Kerberos認證。

• 增強GTID能力。支援Tagged GTID，可使用UUID:TAG:NUMBER區分不同業務域、管理操作或資料操作，並提供TRANSACTION_GTID_TAG許可權控制。

• 改進複製可用性。多線程applier支援SQL_AFTER_GTIDS，副本追趕指定GTID集時可以繼續利用並行複製能力。

• 增強relay log恢複能力。支援清理relay log尾部未完成事務及相關殘留檔案，降低異常宕機後relay log不一致帶來的恢複風險。

• 增強Group Replication營運能力。8.4 LTS系列內支援跨版本群組成員和原地降級，切主流程對DDL/DCL的等待更完整，並支援single-primary模式下的認證資訊預清理，降低記憶體和切主風險。

• 改進統計資訊能力。Histogram支援自動或手動更新控制，有助於提升最佳化器統計資訊維護的可控性。

• 增強執行計畫診斷能力。EXPLAIN FORMAT=JSON支援格式版本選擇，支援EXPLAIN FORMAT=JSON INTO寫入使用者變數，並支援EXPLAIN FOR SCHEMA和FOR DATABASE，便於診斷跨schema的SQL。

• 增強TLS認證校正能力。支援更嚴格的TLS認證校正，提高加密串連安全性。

• 改進Clone能力。同一major或minor系列內clone不再要求point release完全一致，便於8.4.x之間做執行個體初始化、恢複和擴容。

• 增強審計和防火牆能力。Enterprise Firewall支援周期性重載cache，也支援自訂內部對象schema，營運靈活性更高。

• 改進密鑰管理遷移能力。支援從keyring component遷移到keyring plugin，提升加密能力遷移和相容情境的靈活性。

• 改進升級可觀測性。資料目錄維護JSON格式的mysql_upgrade_history，記錄安裝和升級歷史，便於審計和問題排查。

• 提升SQL和最佳化器演化能力。新增TABLESAMPLE、QUALIFY、PARALLEL等關鍵字，為後續SQL能力和最佳化器擴充提供基礎。

附錄二：MySQL 5.7升級MySQL 8.0的優勢

• 提高了安全性，並在帳號管理中實現了更大的靈活性。

• 支援資源群組的建立和管理。

• InnoDB儲存引擎的功能增強。

• 新增字元集、資料類型、文法、新型備份鎖、optimizer_switch標誌等支援。

• JSON、XML增強。

• Optimizer最佳化器功能增強。

• 複製效能增強。

• 支援建立多值索引、派生條件下推最佳化。

• 支援讀取MySQL授權表。

• 支援資源分派控制。

附錄三：MySQL 5.6升級MySQL 5.7的優勢

• 增加密碼管理、帳號鎖定、加密串連等功能，提高資料庫的安全性。

• 支援線上DDL操作。例如RENAME INDEX重新命名索引等。

• 改進了InnoDB引擎的可擴充性和暫存資料表的效能，實現更快的資料載入速度。

• 支援JSON。

• 支援針對分區表的索引條件下推（ICP），以及全新的InnoDB空間索引。

• 最佳化了大部分解析器、最佳化器和成本模型，提高資料庫的可維護性、可擴充性和效能。

• 擴充支援的字元集，包括中國國家標準規定的GB18030字元集。

• 提供ngram全文解析器外掛程式，支援中文、日文和韓文。

• 最佳化源轉儲線程，減少鎖的爭用，提高了源輸送量。

• 大幅改進了複寫延遲問題。

• 新增sys系統庫，提供多個監控項並減少儲存空間佔用，顯著提高資料庫的易用性。

附錄四：MySQL 8.4和MySQL 8.0版本功能差異列表

附錄五：MySQL 8.0和MySQL 5.7版本功能差異列表

附錄六：MySQL 5.7和MySQL 5.6版本功能差異列表

附錄七：MySQL 5.5和MySQL 5.6版本功能差異列表

常見問題

• Q：升級過程中，為什麼會出現執行個體切換？是否會有其他嚴重風險？

  A：為保證業務穩定，高效能本地碟執行個體升級採用先備後主的方式，備執行個體升級完成後，業務自動切換至備執行個體。ESSD雲端硬碟執行個體升級採用建立節點的方式，新節點升級完成後，業務自動切換至新節點。無其他嚴重風險。主備切換的影響請參見主備切換的影響。

• Q：升級時，主備執行個體會一起升級嗎？

  A：高效能本地碟升級時，系統先行升級備執行個體，再升級主執行個體。

• Q：MySQL 5.7基礎系列SSD雲端硬碟執行個體如何升級？

  A：當前不支援該類型的執行個體升級。如您想升級MySQL 5.7基礎系列SSD雲端硬碟執行個體，您可以先將目標執行個體儲存類型從SSD雲端硬碟變更為ESSD雲端硬碟，然後再升級資料庫版本。

• Q：資料庫版本升級前後，參數模板是否保持一致？

  A：RDS MySQL 5.7升級至RDS MySQL 8.0時，如果升級前執行個體為系統參數模板，升級後執行個體將設定為新版本對應的系統參數模板，如升級前為MySQL_InnoDB_5.7_高可用系列_高績效參數模板，升級後將設定為MySQL_InnoDB_8.0_高可用系列_高績效參數模板；如果升級前執行個體為使用者自訂參數模板，升級後參數模板將不會被保留。

• Q：資料庫版本升級期間，是否能變更執行個體？

  A：資料庫版本升級期間不支援變更執行個體，必須在版本升級完成後，才可以進行其他動作。

• Q：資料庫版本是否支援自動升級？

  A：暫不支援自動升級資料庫版本。

• Q：資料庫版本是否支援降級？

  A：不支援通過控制台直接降級。根據執行個體是否存在業務資料，選擇以下方案：

  • 有業務資料：新購低版本執行個體，通過DTS資料移轉工具將高版本執行個體資料移轉至新購的低版本執行個體，遷移完成後釋放高版本執行個體，間接實現資料庫版本降級。詳情請參見RDS執行個體間資料移轉。

  • 無業務資料：退訂原執行個體後重新購買所需低版本執行個體。訂用帳戶執行個體請參考退款說明進行退訂，隨用隨付執行個體可直接釋放。

• Q：RDS MySQL 5.6升級至RDS MySQL 5.7或RDS MySQL 5.7升級至RDS MySQL 8.0時，升級失敗，提示“當前執行個體有全文索引且小版本低於20221130，請先進行小版本升級後再進行刪除、重建全文索引”或“當前執行個體包含建立在系統資料表空間的全文索引，請刪除並重建相應全文索引後再進行升級操作”，問題原因和解決方案是什嗎？

  A：問題原因和解決方案如下：

  • 問題原因

    由於MySQL的歷史原因，較低版本的MySQL 5.6在建立全文索引（Full-Text Index）時會建立在系統資料表空間（System Tablespace）之上。當升級到5.7或進一步升級到8.0後，建立在系統資料表空間的全文索引有機率會導致資料表空間損壞，因此需要在升級前進行處理，避免執行個體資料損毀和不可訪問等問題。

    說明

    RDS MySQL 5.6 20221130對該問題進行了修複，全文索引將建立在單獨的資料表空間之上。

  • 解決方案

    重要

    老版本RDS MySQL 5.6全文索引會建立在系統資料表空間，因此需要確保升級至RDS MySQL 5.7前的版本是RDS MySQL 5.6 20221130或之後的版本。如您的版本較低，請先升級到最新的RDS MySQL 5.6版本。

    1. 根據提示中的表名，刪除建立在系統資料表空間的全文索引。

       # 刪除全文索引
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. 重新建立全文索引。

       # 重新建立全文索引
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. 建立完索引後，可以使用如下SQL對當前執行個體的全文索引進行檢查。SQL會返回建立在系統資料表空間的全文索引，如查詢結果為空白，則RDS MySQL5.6升級至RDS MySQL5.7的過程中不會因為該問題而導致失敗。

       # 查詢建立在系統資料表空間的全文索引
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• Q：RDS MySQL 5.7升級至RDS MySQL 8.0時，報錯267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='，該如何處理？

  A：請檢查MySQL中的字元集和定序。如果當前使用的是utf8mb4_general_ci，建議通過以下 SQL 陳述式將其修改為utf8mb4_0900_ai_ci。

  # 修改庫的字元集和定序
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # 修改表的字元集和定序
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
  # 修改欄位的字元集和定序
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

  在MySQL 5.7中使用utf8mb4_general_ci定序建立的表，如果升級到MySQL 8.0，系統預設會使用utf8mb4_0900_ai_ci作為定序。如果在查詢中比較一個使用utf8mb4_general_ci的列與一個使用utf8mb4_0900_ai_ci的列，MySQL將無法處理這兩種不同的定序，從而導致錯誤。

• Q：無論是否有隻讀執行個體，升級大版本的閃斷時間都是15秒嗎？

  A：是的，請您盡量在業務低峰期執行升級操作。

相關API