MySQL数据库升级的一些坑

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