• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    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)使用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数据库升级的资料请关注脚本之家其它相关文章!

    您可能感兴趣的文章:
    • MySQL 5.7.30 安装与升级问题详细教程
    • Docker版的MySQL5.7升级到MySQL8.0.13,数据迁移
    • phpstudy2018升级MySQL5.5为5.7教程(图文)
    • CentOS 7中升级MySQL 5.7.23的坑与解决方法
    • 升级到MySQL5.7后开发不得不注意的一些坑
    • 实战MySQL升级的最佳方法
    • phpStudy中升级MySQL版本到5.7.17的方法步骤
    • Win下Mysql5.6升级到5.7的方法
    • Windows(x86,64bit)升级MySQL 5.7.17免安装版的详细教程
    上一篇:简述MySql四种事务隔离级别
    下一篇:MySQL百万级数据量分页查询方法及其优化建议
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    MySQL数据库升级的一些陷阱 MySQL,数据库,升级,的,一些,