原创作者: 郭斌斌
前 言
本文是由爱可生运维团队出品的「MySQL专栏」系列文章,内容来自于运维团队一线实战经验,涵盖MySQL各种特性的实践,优化案例,数据库架构,HA,监控以及故障分析,有扫雷功效。
有深度的MySQL开源社区持续运营维护的小目标:每周至少推送一篇高质量技术文章
每月研发团队发布开源组件新版
每年1024开源一款优质开源工具
2019年至少25场社区活动
欢迎大家持续关注~
引言
近期项目进行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值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。要避免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版本的要求、升级都做了哪些内容、数据库升级做了哪些步骤以及注意事项,希望对大家版本升级有帮助。
参考文档:
https://dev.mysql.com/doc/refman/8.0/en/upgrade-binary-package.html