对于商业数据库而言，数据库升级是一个优先级很高的事情，有版本升级路线图，有相应的补丁，而且对于方案还有一系列的演练，显然是一场硬仗。而在MySQL方向上，升级这件事情就被淡化了许多，好像只能证明它的存在而已，当然正是由于这种不重视，也让我今天走了不少弯路。
一般来说，升级MySQL有两类可行方案，一类是直接升级数据字典，在本机完成，整个过程会有离线操作，会对业务有中断，第二种是通过高可用切换平滑实现，原理是搭建低版本到高版本的数据复制关系，这种方案优势比较明显，对于业务的侵入性最低，而且还可以提前验证，更甚还可以做到平滑回退，当然第二种方案要做很多前期的准备工作。
今天处理的一套环境基于存储和时长等因素使用的是第一种方法，整个流程如下：
1） mysqldump备份数据库，备份文件大约为120G
2） 停止MySQL 5.5数据库
3） 修改数据库端口重新启动数据库，比如从4308调整正为4318,使得迁移过程中避免其他业务连接的影响，验证无误后停库
4）修改mysql_base路径为5.7版本，修改/usr/bin/mysql等环境变量配置
5）替换配置文件为5.7版本，在5.7模式下启动数据库
6）使用upgrade模式升级数据字典,命令如下：
mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx
7) 检查复核
整个过程看上去还OK，实际操作的时候漏洞百出。
1） mysqldump备份数据库，备份文件大约为120G，为了快速在线备份采用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）使用upgrade模式升级数据字典,命令如下：
mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx
upgrade这个命令的实现提示不够友好，抛出了一大堆的错误，但是最后竟然安慰我说，升级成功。问题到了这个阶段的时候，其实已经比较难收场了，因为数据字典文件损坏，导致升级数据字典的操作完全不可能，现在数据库连里面的表都desc不出来了
7) 检查复核，本来轻轻松松收工的验证工作现在变成了紧急修复工作。
后续的第一波补救措施如下：
8）使用已有的凌晨固定的物理备份恢复数据，大约为1个小时，mysqldump恢复果断放弃，印象中至少得6个小时以上。
9）使用物理备份模式备份当前数据库
10）重新升级数据库，尤其注意ibdata的配置，如果升级失败则使用物理备份快速回退
11）升级过程再次受阻，这一次是sql_mode,系统数据字典升级成功，但是数据库的表检测中，主要因为sql_mode的数据格式校验，导致很多数据表的格式校验失败，需要执行类似 alter table test.xxxxx force这样的重构操作。
12）因为恢复过程中未知原因，InnoDB的redo log也受到一些影响，日志开始抛错，所以当前恢复的数据库就算升级字典成功，本身也有一些硬伤。
后续的第二波补救措施如下：
13）使用mysqldump备份当前数据库，仅仅备份指定的数据库，不使用all-databases选项，权限单独导出。
14）部署MySQL 5.7的实例，不同的端口，如4390端口
15）sql_mode和5.5版本通配，修改其他参数等
16）导入mysqldump数据至4390的5.7实例
17）建立主从复制关系
18）切换数据库端口，使5.7的新版本服务生效
整个过程也是一波多折，见招拆招，发现想走捷径，最后发现一个坑都没有拉下，而这也给了我深刻的教训，千万不能掉以轻心，不能带着试运气的态度处理问题。
以上就是MySQL数据库升级的一些"陷阱"的详细内容，更多关于MySQL数据库升级的资料请关注脚本之家其它相关文章！
