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） 检查复核，本来轻轻松松收工的验证工作现在变成了紧急修复工作。