这篇文章主要介绍“MySQL数据库升级的坑有哪些”,在日常操作中,相信很多人在MySQL数据库升级的坑有哪些问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答“MySQL数据库升级的坑有哪些”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
一般来说,升级MySQL有两类可行方案,一类是直接升级数据字典,在本机完成,整个过程会有离线操作,会对业务有中断,第二种是通过高可用切换平滑实现,原理是搭建低版本到高版本的数据复制关系,这种方案优势比较明显,对于业务的侵入性比较低,而且还可以提前验证,更甚还可以做到平滑回退,当然第二种方案要做很多前期的准备工作。
今天处理的一套环境基于存储和时长等因素使用的是第一种方法,整个流程如下:
1), mysqldump备份数据库,备份文件大约为120克
2)停止MySQL 5.5数据库
3)修改数据库端口重新启动数据库,比如从4308调整正为4318年,使得迁移过程中避免其他业务连接的影响,验证无误后停库
4)修改mysql_base路径为5.7版本,修改/usr/bin/MySQL等环境变量配置
5)替换配置文件为5.7版本,在5.7模式下启动数据库
6)使用升级模式升级数据字典,命令如下:
mysql_upgrade——套接字=/数据/mysql_4306/tmp/MySQL。袜子——端口=4308 -uroot, -pxxxx
7)检查复核
整个过程看上去还好,实际操作的时候漏洞百出。
1),, mysqldump备份数据库,备份文件大约为120克,为了快速在线备份采用,mysqldump,但是异常情况下的恢复效率是硬伤,所以此处不建议使用,mysqldump备份,而是建议使用物理备份,甚至如果条件允许,直接使用冷备模式
2)停止MySQL 5.5数据库
3)修改数据库端口重新启动数据库,比如从4308调整正为4318年,使得迁移过程中避免其他业务连接的影响,验证无误后停库
4)修改mysql_base路径为5.7版本,修改/usr/bin/MySQL等环境变量配置
5)替换配置文件为5.7版本,在5.7模式下启动数据库,这里没有注意ibdata的配置,运气不好,碰上了一个奇葩配置,如下:
innodb_data_file_path =, ibdata1:1000M; ibdata2:100M: autoextend
而原本的规范配置都是一个ibdata文件,如下:
innodb_data_file_path =, ibdata1:1G: autoextend,
导致数据库启动时报错,提示ibdata文件已经被损坏了。
6)使用升级模式升级数据字典,命令如下:
mysql_upgrade ——套接字=/数据/mysql_4306/tmp/mysql.sock ——端口=4308,-uroot -pxxxx
升级这个命令的实现提示不够友好,抛出了一大堆的错误,但是最后竟然安慰我说,升级成功。问题到了这个阶段的时候,其实已经比较难收场了,因为数据字典文件损坏,导致升级数据字典的操作完全不可能,现在数据库连里面的表都desc不出来了
7)检查复核,本来轻轻松松收工的验证工作现在变成了紧急修复工作。
<强>后续的第一波补救措施如下:
8)使用已有的凌晨固定的物理备份恢复数据,大约为1个小时,,mysqldump恢复果断放弃,印象中至少得6个小时以上。
9)使用物理备份模式备份当前数据库
10)重新升级数据库,尤其注意ibdata的配置,如果升级失败则使用物理备份快速回退
11)升级过程再次受阻,这一次是sql_mode,系统数据字典升级成功,但是数据库的表检测中,主要因为sql_mode的数据格式校验,导致很多数据表的格式校验失败,需要执行类似,alter table测试。xxxxx力这样的重构操作。
12)因为恢复过程中未知原因,InnoDB的重做日志也受到一些影响,日志开始抛错,所以当前恢复的数据库就算升级字典成功,本身也有一些硬伤。
<强>后续的第二波补救措施如下:
13)使用,mysqldump备份当前数据库,仅仅备份指定的数据库,不使用所有数据库选项,权限单独导出。
14)部署MySQL 5.7的实例,不同的端口,如4390年端口
15) sql_mode和5.5版本通配,修改其他参数等
16)导入,mysqldump数据至4390年的5.7实例
17)建立主从复制关系
18)切换数据库端口,使5.7的新版本服务生效
