本文主要介绍“MySQL数据库升级有哪些坑”。在日常操作中，相信很多人对MySQL数据库升级的坑有所怀疑。边肖查阅了各种资料，整理出简单易用的操作方法，希望能帮你解答“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)使用升级模式升级数据字典。命令如下:
MySQL _ upgrade-socket=/data/MySQL _ 4306/tmp/MySQL . sock-port=4308-uroot-pxxx
7)检查和再检查。
整个过程看起来还可以，实际操作中有很多漏洞。
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=ibdata 1:1000m；Ibdata2:100m3360自动扩展，但原始规范配置是Ibdata文件，如下所示:
innodb _ data _ file _ path=ibdata 1:1g 3360 auto extend，这将在数据库启动时导致错误，表明ibdata文件已损坏。
6)使用升级模式升级数据字典。命令如下:
MySQL _ upgrade-socket=/data/MySQL _ 4306/tmp/MySQL。sock-port=4308-uroot-pxxxupgrade，这个命令的实现提示不够友好，抛出了很多错误，但最后还是安慰我升级成功了。问题到了这个阶段，其实很难结束。因为数据字典文件损坏，完全不可能升级数据字典。现在数据库里面连desc这个表都没有。
7)检查和再检查。原本容易收工的核查工作，现在变成了抢修工作。
后续的第一波补救措施如下：
8)凌晨利用现有的固定物理备份恢复数据大概需要1个小时，mysqldump果断放弃，印象中至少需要6个小时。
9)使用物理备份模式备份当前数据库。
10)再次升级数据库，尤其注意ibdata的配置。如果升级失败，请使用物理备份快速回滚。
11)升级过程再次受阻，这次是sql_mode，系统数据字典升级成功。但是在数据库的表检查中，很多数据表的格式检查失败主要是因为sql_mode的数据格式检查，需要执行类似的alter table测试xxxxx
像force这样的重构操作。
12)由于恢复过程中原因不明，InnoDB的重做日志也受到了影响，日志开始抛出错误，所以即使字典升级成功，目前恢复的数据库本身也有一些严重的损伤。
后续的第二波补救措施如下：
13)使用mysqldump备份当前数据库，只备份指定的数据库，不使用all-databases选项，单独导出权限。
14)部署一个带有不同端口的MySQL 5.7实例，比如端口4390。
15)sql_mode和5.5版本常用匹配，其他参数修改。
16)将mysqldump数据导入4390的5.7实例。
17)建立主从复制关系。
18)切换数据库端口，使新版本的5.7服务生效。
至此，“MySQL数据库升级有哪些坑”的研究结束，希望能解决大家的疑惑。理论和实践的结合可以更好的帮助大家学习，所以赶紧试试吧！如果你想继续学习更多的相关知识，请继续关注网站，边肖会继续努力，给大家带来更多实用的文章！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/53572.html