当前位置: 首页 > 编程笔记 >

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

宰父劲
2023-03-14
本文向大家介绍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)使用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数据库升级的资料请关注小牛知识库其它相关文章!

 类似资料:
  • 问题内容: 我已经在Google Store中有一个应用程序。我正在使用具有3个表的内置数据库,并在应用程序首次启动时将其复制。现在,我想升级到该应用程序并添加另一个表。下面是我的代码。 我想问几个问题。上面的代码未升级。 现在,如果我是该应用程序的新用户,是否需要编辑旧数据库并制作另一个CKRecording表,并用放置在资产中的当前数据库替换该数据库,或者上述代码也适用于新用户? 问题答案:

  • 问题内容: 我一直在研究数据库的升级过程,特别是SQLite类型的数据库。 我被程序如何知道的困扰,“嘿。这个表不存在,让我们创建它吧!” 或“嘿,它确实存在,但后面有三个版本,让我们对其进行更新!” 我的意思是,我可以为每个表的每个版本编写特定的代码(基本上列出了其中的哪些列…),然后将其全部转储到每个表的大型if语句中,或类似的傻事,但这会疯了。-真的很疯狂。 (我会包含该代码,以便你们指出如

  • 升级、备份和恢复 数据库升级 数据库升级的推荐方案是,老版本的数据库的数据备份成 SQL 脚本的方式,在新版本的数据库上执行这些 SQL 来恢复数据。 使用 Script 工具备份数据 备份数据库有多种方式。如可以直接拷贝数据库文件,但是不建议在数据库在使用的时候去拷贝文件,另外数据库文件是二进制的,不能直接读懂,并且数据库文件可能会比较大,推荐的备份方式是创建压缩的 SQL 脚本文件,并且 H2

  • 2.10.1. 从5.0版升级 2.10.2. 升级授权表 2.10.3. 将MySQL数据库拷贝到另一台机器 做为一般原则,我们建议从一个发布系列升级到另一个发布系列时,你应当先升级到它的下一个系列而不要跳过。例如,如果你目前正运行MySQL 3.23,想要升级到较新的系列,要升级到MySQL 4.0而不要升级到5.0或5.1。 下面的项列出了升级时的相关信息: ·从MySQL 5.0升级到5.

  • 如何连接MySQL数据库中的某个表? 我曾经尝试过: 但这给了我一个错误:- 但是我已经创建了一个名为的表。是否有任何PHP代码连接到我的表在同一个数据库中,有多个数据库? 创建多个数据库是否足够明智 完整代码:

  • 本文向大家介绍Mysql数据库表类型有哪些?相关面试题,主要包含被问及Mysql数据库表类型有哪些?时的应答技巧和注意事项,需要的朋友参考一下 MyISAM、InnoDB、HEAP、BOB,ARCHIVE,CSV等。 MyISAM:成熟、稳定、易于管理,快速读取。一些功能不支持(事务等),表级锁。 InnoDB:支持事务、外键等特性、数据行锁定。空间占用大,不支持全文索引等。