Mysql 5.0 升级到 5.1

最新推荐文章于 2021-03-23 12:27:29 发布

zl5897

最新推荐文章于 2021-03-23 12:27:29 发布

阅读量1.1k

点赞数

文章标签： mysql schema 引擎 table 数据库服务器服务器

本文链接：https://blog.csdn.net/zl5897/article/details/5825533

版权

如果仅仅是一个小数据量的schema，我想最简单的应用是使用mysqldump这种逻辑备份形式，更具有迁移性，但涉及到大量数据的时候，mysqldump需要花费大量的时间，另外导入也需要很多时间。

一台已经使用了近3年的测试Mysql数据库服务器，已经存储了大量的schema ，而且一些schema内的表引擎有Innodb、MyISAM、MEMORY这几种引擎，数据量也比较大。昨晚公司突然停电，早上上班后发现系统已经点不亮了，找人弄了台配置一模一样的机器接入原先的硬盘，经过漫长的文件系统检测修复后，顺利进入了系统。修改了网卡的udev配置后，又可以继续使用 eth0这个设备号。

对于mysql 5.0和 5.1间的差异导致的问题，我吃过几次亏，借此机会，我尝试升级这台服务器的相关服务组件，尽可能和生产环境的相似。由于数据量较大，以及本着学习的精神，探索一下一个合理的升级方案以备日后存在更大的数据库需要升级时提供些经验。

我开始认为从5.0 到5.1的升级应该不算复杂，版本号差异不大，应该可以完全通过拷贝文件的形式进行升级。然而这个实验我失败了，日志中提示授权表异常信息，我只能好好琢磨一下Mysql的帮助文档以求解决问题。其实5.0 和5.1 是两个差异很大的版本，对于大版本间的升级，Mysql官方总是会给出升级说明 ,虽然描述的不是那么的清楚，但总算个指导手册。

安装官方的说明，想从5.0升级到5.1，首先需要在5.0的环境下执行针对5.1的权限升级脚本"mysql_fix_privilege_tables.sql"。完成后可以使用mysqldump导出后再倒入到5.1的mysql中；也可以在相同浮点格式的不同架构之间拷贝MyISAM表的文件，对于Innodb和MEMORY这类引擎，就没有这么幸运了，今天花费了不少时间来实验和寻找解决办法。

其实在5.0的环境中执行了"mysql_fix_privilege_tables.sql"前，还有一些很重要的工作需要处理的(如果现实的环境允许的话)，那就是备份、和检查所有的schema内的表是否正常，并进行修复。前面我提到过这台测试服务器是经历过突然断电的，开始我太理所当然的觉得不会有问题，仅仅是对整个mysql 5.0做了备份。但在升级的过程中发现，大量的表存在非正常关闭、受损的问题，为此我又切回到mysql 5.0的环境下先对这些表进行修复。今天庆幸做了两件正确的事情：

做了备份
同时在服务器上保留了两套mysql环境(为他们设置不同的目录，专门为他们准备不同的my.cnf配置文件和启动控制脚本)

当我在5.0的环境中完成了表的修复，"mysql_fix_privilege_tables.sql"的升级后，关闭5.0的服务。拷贝相应的表文件、innodb文件、innodb日志到5.1的环境下。mysql 5.1能顺利启动了，出于安全起见，我又自行了一次表检查，并发现了innodb和memory引擎表的问题(我开始又理所当然的觉得他们应该是不会有问题的了)。检测命令：
$MYSQL5.1_BIN_PATH/mysqlcheck -A –check-upgrade -s
-s参数能屏蔽那些正常的表的信息，通过这条命令，我发现有问题的都是innodb、memory引擎的表，提示我需要执行REPAIR TABLE或者dump/restore来修复这些表。这种情况下REPAIR TABLE命令是不管用了" The storage engine for the table doesn’t support repair "，dump/restore又跟我的初衷相违背。google上找到一些解决思想 ,通过ALTER TABLE tbl ENGINE=INNODB来重建，以符合当前的mysql版本。所以，对于此次的升级，较为合理的顺序将是：