新特性解讀 | MySQL 5.7升級到MySQL 8.0的注意事項
引言
近期項目進行MySQL 5.7.21到MySQL 8.0.13的升級測試,采用邏輯升級,配置文件來自于生產環境。在初始化MySQL 8.0時,初始化命令秒級完成,而數據目錄卻是空的,執行初始化操作的shell窗口也沒有任何的報錯提示。
通過翻閱官方手冊發現MySQL 8.0.13中NO_AUTO_CREATE_USER這種sql_mode已經廢棄,而配置文件的sql_mode有這個配置項,最終導致了實例初始化失敗。為了減少升級過程中出現類似問題,因此對MySQL 5.7到8.0的升級進行部分整理,主要包括:升級對MySQL版本的要求、升級都做了哪些內容、數據庫升級做了哪些步驟以及注意事項。
升級要求
- MySQL 5.7升級到MySQL 8.0,要求MySQL5.7的版本是MySQL 5.7.9或者更高的GA版
- 不支持跨版本升級
升級內容
- 升級數據字典表的版本
- 升級MySQL server 版本,主要包括system表以及其他schema對象
升級步驟
- 升級數據字典,這個階段主要升級MySQL庫的數據字典表。數據字典的升級在數據庫服務啟動過程自動完成。
- 升級MySQL庫的系統表(剩余的非字典表);升級Performance schema、 information schema 、sys schema;升級用戶schema。在MySQL 8.0.16版本之前,需要手動的執行MySQL_upgrade來完成該步驟的升級,在MySQL 8.0.16版本是由MySQLd來完成該步驟的升級。
升級注意事項
- caching_sha2_password認證插件提供更多的密碼加密方式,并且在加密方面具有更好的表現,目前MySQL 8.0選用caching_sha2_password作為默認的認證插件,MySQL 5.7的認證插件是MySQL_native_password。如果客戶端版本過低,會造成無法識別MySQL 8.0的加密認證方式,最終導致連接問題。
- MySQL存儲引擎現在負責提供自己的分區處理程序,而MySQL服務器不再提供通用分區支持,InnoDB和NDB是唯一提供MySQL 8.0支持的本地分區處理程序的存儲引擎。 如果分區表用的是別的存儲引擎,存儲引擎必須進行修改。要么將其轉換為InnoDB或NDB,要么刪除其分區。通過MySQLdump從5.7獲取的備份文件,在導入到8.0環境前,需要確保創建分區表語句中指定的存儲引擎必須支持分區,否則會報錯。
- MySQL 8.0的默認字符集utf8mb4,可能會導致之前數據的字符集跟新建對象的字符集不一致,為了避免新舊對象字符集不一致的情況,可以在配置文件將字符集和校驗規則設置為舊版本的字符集和校驗規則。
- MySQL 8.0啟動使用的lower_case_table_names值必須跟初始化時使用的一致。使用不同的設置重新啟動服務器會引入與標識符的排序和比較方式不一致的問題。
< lower_case_table_names >
https://dev.mysql.com/doc/refman/8.0/en/server-systemvariables.html#sysvar_lower_case_table_names
- 要避免MySQL 8.0上的啟動失敗,MySQL配置文件中的sql_mode系統變量不能包含NO_AUTO_CREATE_USER。
- 從MySQL 5.7.24和MySQL 8.0.13開始,MySQLdump從存儲程序定義中刪除了NO_AUTO_CREATE_USER。 必須手動修改使用早期版本的MySQLdump創建的轉儲文件,以刪除NO_AUTO_CREATE_USER。
- 在MySQL 8.0.11中,刪除了這些不推薦使用的兼容性SQL Mode:DB2,MAXDB,MSSQL,MySQL323,MySQL40,ORACLE,POSTGRESQL,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS。從5.7到8.0的復制場景中,如果語句使用到廢棄的SQL Mode會導致復制異常。
- 在執行到MySQL 8.0.3或更高版本的in-place升級時,BACKUP_ADMIN權限自動授予具有RELOAD權限的用戶。
本文對MySQL 5.7到MySQL 8.0的升級過程中出現部分易出現問題進行整理:升級對MySQL版本的要求、升級都做了哪些內容、數據庫升級做了哪些步驟以及注意事項,希望對大家版本升級有幫助。
原創作者: 郭斌斌