背景信息

2015年10月，Oracle正式推出MySQL 5.7。相對于MySQL 5.6，MySQL 5.7具備更出色的性能、更豐富的功能以及更高的安全性，逐漸成為了后續(xù)MySQL版本的首選。2018年，MySQL 8.0發(fā)布，相比MySQL 5.7有了進一步的提升。2023年10月25日，社區(qū)推出MySQL 5.7.44，該版本為最后一個5.7版本，意味著社區(qū)將停止對MySQL 5.7的維護，不再進行缺陷的修復和功能的更新。同時，社區(qū)也鼓勵用戶將MySQL 5.7升級到MySQL 8.0。

MySQL 5.7作為備受信賴的服務版本，目前仍然擁有廣泛的用戶群體。截止至2024年1月，在阿里云RDS MySQL的用戶群中，約有46%的用戶仍然堅持使用5.7作為他們的主要服務版本。然而，隨著生命周期的結束，由于缺乏后續(xù)的更新和支持，MySQL 5.7面臨著各種問題，難以滿足不斷變化的需求。社區(qū)MySQL主要服務版本如下圖所示。

相對于MySQL 5.7版本，MySQL 8.0版本引入了許多強大而實用的特性。

• Atomic DDL：解決了MySQL 5.7版本中DDL中斷導致文件殘留的問題，確保了文件操作的原子性，同時解決了Server層和引擎層數(shù)據(jù)不一致的問題。

• Instant DDL：大大縮短DDL執(zhí)行的時長，快速完成表結構的變更，同時消除了Binlog復制延遲。

• 增強JSON支持：新增了多個與JSON相關的函數(shù)，并對JSON的內存使用進行了優(yōu)化。

• 隱藏索引：可以將索引設置對優(yōu)化器不可見，從而避免潛在的重復刪除和重建索引的操作。

• 克隆插件：相比傳統(tǒng)的復制方式更加高效，直接在源實例上進行授權和克隆，極大地提高了MySQL的可擴展性。

阿里云RDS MySQL 8.0在社區(qū)MySQL 8.0的基礎上進行了深度優(yōu)化，并開發(fā)了許多高級特性，包括：

• Binlog in Redo：在事務提交時將Binlog內容同步寫入到Redo Log中，減少對磁盤的操作，提高數(shù)據(jù)庫性能。

• 通用云盤IO加速：通過擴展InnoDB Buffer Pool，將一部分數(shù)據(jù)頁和溫數(shù)據(jù)緩存，使您在無任何成本變化和業(yè)務改動的情況下，就可以獲得實例IO性能的大幅度提升。

• 冷熱數(shù)據(jù)分離：通過將云盤歸檔數(shù)據(jù)轉存至OSS端，大幅降低存儲成本。

• RTO相關優(yōu)化：通過優(yōu)化Redo應用過程和啟動路徑等，大幅縮短實例啟動時間，提升實例的可用性。

通過架構的持續(xù)演進和內核的不斷優(yōu)化，阿里云RDS MySQL相較社區(qū)版本擁有更高的穩(wěn)定性和安全性、更強的性能和更多的功能，為用戶提供穩(wěn)定可靠、簡單易用的數(shù)據(jù)庫服務。更多RDS MySQL自研的高級特性請參見AliSQL功能概覽。

作為更強大的分支，MySQL 8.0的維護周期將會更長，并且將逐步解決現(xiàn)有問題。長期來看，強烈建議個人用戶和企業(yè)用戶將MySQL 5.7升級至MySQL 8.0。

社區(qū)版MySQL 5.7升級8.0遇到的問題

升級之前需要大量的準備工作

盡管存在許多必須升級的理由，但實際上從MySQL 5.7 升級到8.0并非易事。MySQL 8.0相較于MySQL 5.7，在數(shù)據(jù)字典、存儲引擎和SQL語法等方面發(fā)生了許多重大變化。由于不同版本之間存在差異，在進行升級之前需要充分評估并做好充足的準備工作。MySQL 8.0相較于MySQL 5.7的主要差異如下圖所示，詳情請參見MySQL社區(qū)文檔。

MySQL 5.7升級到MySQL 8.0是通過inplace upgrade的方式進行的，即直接使用MySQL 8.0的二進制文件來啟動MySQL 5.7的實例，升級程序將自動進行相關的檢查和升級。

升級前的準備工作實際上是為了消除升級程序中無法自動處理的“不兼容的”變化。主要工作包括：

• MySQL 8.0引入了全新的數(shù)據(jù)字典用于保存數(shù)據(jù)庫中的元信息，Server層和InnoDB層共享一份元數(shù)據(jù)。MySQL 8.0的information_schema中的視圖全部源自于數(shù)據(jù)字典表，與InnoDB相關的視圖被重命名（INNODB_SYS_XXX重命名為INNODB_XXX）。若用戶的應用依賴于這些視圖，需要確保應用已做出相應的修改。在升級前需要確認業(yè)務是否依賴于MySQL 8.0中刪除的系統(tǒng)表（如mysql.proc、mysql.event等），若存在則需使用新的訪問方式去獲取所需的數(shù)據(jù)。此外，對于和MySQL 8.0系統(tǒng)表同名的用戶表（如catalogs、routines等），需要手動執(zhí)行RENAME/DROP TABLE操作。

• RDS MySQL 8.0不再支持部分舊版本數(shù)據(jù)類型。如果表中字段含有MySQL 8.0不支持的數(shù)據(jù)類型，需要在升級前通過REPAIR TABLE或邏輯導出+導入的方式修復。更多信息請參見準備升級安裝。

• MySQL 8.0中，分區(qū)表的處理已由Server層下沉至引擎層，MySQL Server不再支持通用分區(qū)。Non-native的分區(qū)表在MySQL 8.0中被廢棄，因此需要將這類分區(qū)表改為Native類型（如InnoDB引擎）或是刪除該分區(qū)表。

• 較早版本的MySQL 5.7（5.0.17之前的版本）的觸發(fā)器（Triggers）不支持DEFINER屬性，因此在MySQL 5.7實例中可能會存在缺失DEFINER屬性的觸發(fā)器，這些觸發(fā)器會導致升級MySQL 8.0失敗。在升級前您需要重新創(chuàng)建這些缺失DEFINER屬性的觸發(fā)器。

• MySQL 8.0中，外鍵約束的長度存在限制，如果外鍵約束過長，在升級過程中可能會導致錯誤和失敗。因此，在進行升級之前，需要將問題外鍵修改為長度小于64個字符的約束。

• MySQL 8.0之前版本，視圖的列名長度上限為255個字符，而在MySQL 8.0版本中，視圖的列名長度上限縮短至64個字符。因此，在進行升級之前，需要將視圖中過長的列名修改為長度小于64個字符的列名。

• MySQL 8.0中，單個ENUM和SET列元素的長度不得超過255個字符或1020個字節(jié)，因此在升級之前需要修改超出限制的ENUM和SET。

• 如果.frm文件和InnoDB數(shù)據(jù)字典表元數(shù)據(jù)信息不一致，那么會導致升級錯誤。因此，在進行升級之前，需要對數(shù)據(jù)進行邏輯導出和導入。若存在游離的.frm文件（即不含.ibd文件僅有.frm文件），則需要進行相應清理。

• MySQL 8.0廢棄了部分空間函數(shù)。如果生成列中包含了已刪除的函數(shù)（新引入的空間函數(shù)以"ST"和"MBR"開頭），則需要在升級前對相應的列進行修改。

• 在進行升級前，必須確保MySQL 5.7的實例已經進行了正確的關閉，即需要確保在升級前不存在待應用的REDO日志和等待回滾的事務。

• MySQL 8.0中引入了一些新的保留字，其中大多數(shù)禁止用作表名、列名等，因此需要對MySQL 5.7中包含的MySQL 8.0引入的新保留字做處理。

• 在升級前，需要將廢棄的sql_mode變量內容（例如NO_AUTO_CREATE_USER等）修改為MySQL 8.0支持的模式，以避免導致實例無法啟動。

• 較新版本的MySQL 8.0實例（8.0.13及之后的版本），共享表空間（系統(tǒng)表空間和通用表空間）中不允許存在InnoDB類型的分區(qū)表，因此在進行升級前需要將共享表空間移動至獨立表空間。

• MySQL 8.0實例中，GROUP BY子句不支持ASC或DESC排序規(guī)則，因此，在進行升級前，需要修改或刪除包含相應句法的存儲過程。

• 在MySQL 5.7中，lower_case_table_names是一個可修改的值，但在MySQL 8.0中，lower_case_table_names是一個初始化參數(shù)，一旦實例初始化完成，就無法在后續(xù)進行修改。在進行升級時，若需要將該參數(shù)值修改為1，請確保升級前庫表名稱為小寫，以避免出現(xiàn)升級錯誤。

• MySQL 5.7和MySQL 8.0的字符集（character set）和排序規(guī)則（collation）的配置可能存在差異，這可能導致索引失效、查詢報錯等問題，例如：

  • MySQL 8.0默認字符集為utf8mb4，使用1~4字節(jié)存儲一個字符，MySQL 5.7默認字符集為utf8mb3，使用1~3字節(jié)存儲一個字符，因此字段和索引長度會受到影響。在REDUNDANT或者COMPACT行格式下，InnoDB引擎所允許的最大索引長度為767字節(jié)，對應在5.7中索引允許的最大字符數(shù)是255，而在8.0中則無法創(chuàng)建超過191字符的索引。

  • 當在MySQL 5.7中使用了utf8mb3字符集創(chuàng)建表，如果升級MySQL 8.0后默認使用的字符集為utf8mb4，新建表在沒有指定character set時默認使用 utf8mb4。當新表（utf8mb4）和遷移表（utf8mb3）相關字段發(fā)生JOIN時，會因為JOIN兩端字符集類型不一致導致索引失效。

  • 當在MySQL 5.7中使用了utf8mb4_general_ci排序規(guī)則創(chuàng)建表，如果升級到MySQL 8.0后，默認使用的排序規(guī)則為utf8mb4_0900_ai_ci，新建表在沒有指定collation時默認使用utf8mb4_0900_ai_ci。由于utf8mb4_general_ci和utf8mb4_0900_ai_ci優(yōu)先級相同（無法選擇排序規(guī)則），當新表和遷移表相關字段發(fā)生JOIN時，會因為JOIN兩端排序規(guī)則不兼容導致報錯。

  為避免出現(xiàn)字符集引發(fā)的問題，在升級前需要檢查MySQL中的字符集和排序規(guī)則使用情況，您也可以通過下述SQL來修改庫、表、字段的字符集和排序規(guī)則。

  # 修改庫的字符集和排序規(guī)則
  ALTER DATABASE database_name CHARACTER SET = charset COLLATE = collation;
  # 修改表的字符集和排序規(guī)則
  ALTER TABLE table_name CONVERT TO CHARACTER SET charset COLLATE collation;
  # 修改字段的字符集和排序規(guī)則
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET charset COLLATE collation;

  重要

  • 修改列的charset時，MySQL會嘗試映射數(shù)據(jù)值，但如果修改前后charset不兼容，可能會發(fā)生數(shù)據(jù)丟失。

  • 在阿里云RDS MySQL中，各版本默認字符集均使用utf8mb3，默認排序規(guī)則均使用utf8mb3_general_ci，如果沒有手動修改過字符集和排序規(guī)則，大版本升級前后不會出現(xiàn)此類問題。

  • 更多信息可參考：調整實例character_set_server參數(shù)和collation_server參數(shù)和MySQL 社區(qū)字符集配置。

除了上述的準備工作外，版本間存在的驅動、錯誤碼、參數(shù)、優(yōu)化器差異等也需要業(yè)務上做適配。對于自建用戶，在進行MySQL 5.7到MySQL 8.0的大版本升級前，可以利用MySQL Shell、mysqlcheck工具和社區(qū)的升級檢查文檔檢查準備工作。MySQL 5.7升級到MySQL 8.0變化和檢查細節(jié)請參見MySQL社區(qū)文檔。

經常升級失敗并且難以分析失敗原因

盡管社區(qū)提供了相應的檢查工具和幫助文檔，以幫助用戶進行升級前的檢查和問題解決。然而在實際操作中經常會遇到升級失敗的情況，出現(xiàn)各種各樣的錯誤，并且很難從日志信息中逐一分析升級失敗的原因。升級失敗分析困難的原因包括但不限于以下幾點：

1. 報錯不明確。不同原因導致的錯誤，在日志中可能會記錄為相同或相似的錯誤。用戶需要投入大量時間和精力來排查錯誤的根本原因，這增加了升級的難度。

2. 報錯不完整。在問題出現(xiàn)后，針對性地解決后發(fā)現(xiàn)重復的問題再次導致失敗。這是因為升級程序在首次檢測到某一類錯誤時就提前退出，導致相同問題無法一次性全部被檢測到。用戶需要進行多次嘗試和排查，這增加了升級的復雜性和時間成本。

3. 部分錯誤只提供了錯誤提示，卻沒有相應的解決方案。用戶需要自行查找解決方案或向社區(qū)尋求幫助，這增加了升級過程中的困惑和不確定性。

4. 部分MySQL 5.7或更早版本存在的問題已經得到修復，但對存量實例的處理仍然存在不足。

在解決大版本升級問題中發(fā)現(xiàn)，由于版本差異以及更老的MySQL 5.x版本信息殘留，大版本升級涉及的問題瑣碎繁多，升級失敗的根源大多集中在數(shù)據(jù)字典上。

使用RDS MySQL輕松升級到RDS MySQL 8.0

阿里云RDS MySQL擁有大量正在使用的實例，每個月都有一些實例從5.7版本升級到8.0版本。在這一過程中，阿里云RDS團隊積累了豐富的經驗，建立了完善的預檢查邏輯，并對多個大版本升級相關的Bug進行了分析和修復。

阿里云RDS MySQL團隊致力于提前發(fā)現(xiàn)升級問題，保障升級平穩(wěn)進行，提升大版本升級成功率，使用戶獲得更順暢的升級體驗。升級后用戶可以享受到阿里云RDS MySQL 8.0帶來的高性能和可靠性。此外，RDS將延長對不同版本的MySQL的支持期限，為用戶提供更充裕的緩沖時間。社區(qū)MySQL和阿里云RDS MySQL生命周期如下：

在自建MySQL 5.7升級至8.0的過程中，除了前期繁瑣的檢查工作外，根據(jù)報錯信息逐步進行修復可能需要多次進行，并且可能會遇到難以修復的問題，導致無法完成升級的情況。升級過程中停機時間長，返工次數(shù)多，耗費時間和精力。

與自行升級用戶相比，用戶進行阿里云RDS MySQL的大版本升級時，無需進行繁瑣的檢查，也無需反復核查錯誤日志并逐一解決問題，僅需點擊控制臺上的升級按鈕，所有升級動作將在后臺自動完成。

• 針對線上常見的大版本升級失敗問題，阿里云RDS MySQL內核已進行修復工作。當用戶的實例存在修復覆蓋下的問題時，升級過程將不會失敗，從而可實現(xiàn)無感升級。

• 針對內核側無法直接修復的問題，阿里云 RDS MySQL 管控側主動進行了多項兼容性檢測。在實例觸發(fā)大版本升級動作前，提前發(fā)現(xiàn)問題并進行提示，用戶在無需重復啟停的情況下就能夠解決大部分問題。同時，對于升級失敗的節(jié)點會自動回滾到升級前的狀態(tài)，不會影響業(yè)務運行。

自建MySQL 5.7升級到 8.0和阿里云RDS MySQL 5.7升級到8.0流程對比如下：

經過一系列的治理，2023年至2024年期間，阿里云RDS MySQL 5.7成功升級至8.0的比例高達97.3%以上。阿里云RDS MySQL 5.7升級8.0的部分治理工作如下表所示：

升級方法

關于RDS MySQL的升級，詳細信息請參見升級數(shù)據(jù)庫版本。

升級案例

案例一：Server層與InnoDB字段、索引大小寫不一致導致升級失敗

• 自建MySQL升級失敗：

  [ERROR] [MY-012071] [InnoDB] Column name mismatch: From InnoDB: id_c From Server: Id_c
  [ERROR] [MY-010767] [Server] Error in fixing SE data for test.t3
  [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自動修正引擎元數(shù)據(jù)，升級成功：

  [Warning] [MY-012071] [InnoDB] Column name case mismatch: From InnoDB: id_c From Server: Id_c, DD will be consistent with Server one.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

案例二：表、字段、索引和存儲過程包含亂碼導致升級失敗

• 自建MySQL升級失敗：

  [ERROR] [MY-013140] [Server] Comment for table 'test.t4' contains an invalid utf8mb3 character string: '\xF0\x9F\x90'.
  [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自動清除表、字段和索引注釋的亂碼，升級成功：

  [Warning] [MY-025076] [Server] Clear utf8mb3 character strings: '\xF0\x9F\x90' in comment of table 'test.t4'.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

案例三：5.x 老版本臨時表殘留導致升級失敗

• 自建MySQL升級失敗：

  [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: '/tmp/#sql1dc6f_2_0.ibd' OS error: 71
  [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自動清理殘留的元信息，升級成功：

  [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: '/tmp/#sql8947_1_0.ibd' OS error: 71
  [Warning] [MY-025078] [InnoDB] Skip orphaned tablespace during upgrade, space_id: 7, filepath: /tmp/#sql8947_1_0.ibd.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

當然，阿里云RDS MySQL團隊并未完全解決MySQL 5.7升級到8.0過程中的所有問題，在場景和方案上仍然存在需要完善的地方。

• 當前，在大版本升級過程中，為了確保用戶實例不受影響，升級過程首先會在源實例的克隆實例上進行。當克隆實例完成升級后，再將用戶實例進行切換，并釋放舊版本實例。這個過程難免會消耗更多的時間和資源，因此有必要探索更好、更快的解決方案。

• 目前的治理手段無法覆蓋所有的升級失敗場景，無法保證100%的升級成功率。同時，用戶行為導致升級失敗的情況，通常需要用戶介入進一步處理，無法實現(xiàn)完全的全自動升級。因此，進一步降低用戶干預的比例是需要持續(xù)努力的方向。

總結

在進行大版本升級時，必須進行詳細的升級前檢查，逐步解決升級過程中出現(xiàn)的問題，并且完成升級后的驗證和測試工作。大版本升級失敗問題的解決并非一蹴而就。阿里云RDS MySQL團隊一直在進行相關問題的修復和建設，提供了簡便和高效的大版本升級機制。隨著8.0版本的穩(wěn)定推進，大版本升級的問題會逐步得到解決，直至完全消除。

相關文檔

• 您可以將自建MySQL或第三方云數(shù)據(jù)庫MySQL遷移至RDS MySQL，利用RDS輕松升級到MySQL 8.0。數(shù)據(jù)遷移請參見數(shù)據(jù)遷移方案。

• 更多MySQL的信息，請參見MySQL。