请教mysql冷备问题:Can't find file: 'table' 和 Table 'tx' doesn't exist

yqhzh

请教mysql冷备问题：ERROR 1017 (HY000): Can't find file: 'table' (errno: 2) 和 ERROR 1146 (42S02): Table 'tx' doesn't exist
-----------------------------------------------------------------------------------------------------------------------------

现在在 mysql 迁移上 遇到一个 问题，都查阅资料一整天了还是没有解决 ，请教各位有没有好的办法：

以下是环境配置：
两台物理机器，
A 是 Ubuntu 10 Server ，文件系统是 ext4 , 数据库 版本 是：mysql  Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (i686) using readline 6.1
B机是 SUSE 11 SP1，文件系统是 ext3, 数据库 版本是 ：mysql  Ver 14.12 Distrib 5.0.67, for suse-linux-gnu (x86_64) using readline 5.2

目标：将 A 机上的 mysql 数据库迁移到 B机，并且保证在B机上正确运行  。

由于数据量极大，ibdata文件大约20G，frm,MYI,MYD大约12G，所以采用以下操作步骤 和现象：
1，停掉A机和B机上的数据库。
2，将A机上 /var/lib/mysql　文件夹下的所有文件scp 到B机的 /var/lib/mysql 后。
3，重启 B机 数据库 service mysql start，发现 一些表 出现ERROR，具体信息例如：
mysql.general_log
ERROR: Can't find file: 'general_log' (errno: 2)
error:  Corrupt
大约有1/4的表，19个表出现如此现象。
4，接下来启动数据库，在数据库中select 查看。发现错误，例如 ：
ERROR 1017 (HY000): Can't find file: 'general_log' (errno: 2)
ERROR 1017 (HY000): Can't find file: 'slow_log' (errno: 2)
ERROR 1017 (HY000): Can't find file: 'tx' (errno: 2)
也有一次出现：
ERROR 1146 (42S02): Table 'tx' doesn't exist
ERROR 1146 (42S02): Table 'a.log' doesn't exist

google了一下资料，但是解决方法都不对路（以下操作全部是service mysql stop之后执行的）：
有的说这个表 '***.frm'  不存在，但是我看了数据库实际是存在的；
有的说是权限问题，但是我的数据库中frm,MYI,MYD文件属主和组都是mysql:mysql，甚至我全部更改了一次 chown -R mysql:mysql  /var/lib/mysql，任然无效 ；
有的说是大小写问题，但是我是从ubuntu linux 迁移到 SuSE 上的，检查了大小写绝对没有问题；
有的说是没有安装成功，于是我用光盘再次安装了，还是不行；
甚至下载了最新的mysql版本，安装之后还是不行；
重启mysql服务，不行；
重启SuSE，不行；

我也不敢按照有些建议的drop table之后重新create，这样数据全没有了，肯定不行。
原来在SuSE之间通过copy备份没有问题，在Ubuntu之间copy备份没有问题。但是现在在Ubuntu和SuSE之间copy备份就有问题了。
折磨了我一天了，还请各位多多指教，小白在此先谢谢了。

yqhzh

再补充一点貌似相关的信息：
在google上又发现一个貌似相关的文章：innodb、myisam通过frm文件恢复表结构。

按照所述的修复方法修复 innodb 引擎相关的表的时候：在其他数据库创建表结构，再从其他数据库copy表结构到损坏的数据库，
show create table mysql.tx 时，仍然出现：
ERROR 1146 (42S02): Table 'mysql.tx' doesn't exist

按照上述方法 修复 myisam 引擎相关的表的时候：
create database repair;
然后将info的 MYI, MYD 文件copy到相关的文件夹下。
repair TABLE info USE_FRM;
出现 ：
+-------------------+--------+----------+-----------------------------------------+
| Table             | Op     | Msg_type | Msg_text                                |
+-------------------+--------+----------+-----------------------------------------+
| repair.info | repair | Error    | Table 'repair.info' doesn't exist |
| repair.info | repair | error    | Corrupt                                 |
+-------------------+--------+----------+-----------------------------------------+

直接在原有表上修复出现：

use section;
repair TABLE info USE_FRM;
+------------------+--------+----------+------------------+
| Table            | Op     | Msg_type | Msg_text         |
+------------------+--------+----------+------------------+
| section.info | repair | Error    | Can't open table |
| section.info | repair | error    | Corrupt          |
+------------------+--------+----------+------------------+

总之，还是没有办法搞定。。。晕。。。
还有什么CVS引擎的表也坏了。。。看来这种修复方法很可能不搭界啊。

Coolriver

查看mysql error－log，
从现象来看，很有可能是你的两台机器的my.cnf配置不一致造成的。

yqhzh

原因找到了：
mysql 5.0 版本到 5.1 版本有很大的改动，所以从 5.1 版本降级到 5.0 版本可能导致“表储存格式可能不兼容”。

《MySQL 5.1参考手册》 中也有这样的说明：
2.11. 降级MySQL
如果你在同一发布系列(例如，从 5.0.13 到5.0.12)内降级，一般规则是只需要在旧版本的顶部安装新的二进制。不需要对数据库进行任何操作。.......  如果你从一个发布系列降级到另一个发布系列，表储存格式可能不兼容。......  表格式不向下兼容的一般迹象是降级时不能打开表。

仔细回忆了我当时数据库冷备的操作：
数据库最初使用的是从官网下载的社区 5.5.12 版本，然后安装 Ubuntu Server 10.04 之后，冷备到 Ubuntu 10.04 机器上使用的是系统自带的默认的  5.1.49 版本，但是可能由于 5.5.12 和 5.1.49 版本降级表储存格式兼容，所以并未发现问题。
然后我又做了一次迁移，从 5.1.49 迁移到 SLES 10 SP1 上默认的 5.0.67 版本，这次迁移可能因为 5.0 版本到 5.1 版本有很大的改动且涉及到表储存结构，所以就发现很多表不能打开，虽然表实际存在但是会报错 ERROR 1017 (HY000): Can't find file: 'table' (errno: 2) 和 ERROR 1146 (42S02): Table 'tx' doesn't exist

《MySQL 5.1参考手册》 中确实提到了这样的情况，而且给出了解决方法：
在这种情况下，你可以在降级嵌使用mysqldump来转储表。降级后，使用mysql或mysqlimport重载转储文件来重新创建表。
表格式不向下兼容的一般迹象是降级时不能打开表。在这种情况下，使用下面的过程：
1.    停止你想要降级到的旧的MySQL服务器。
2.    重新启动将被降级的新的MySQL服务器。
3.    使用mysqldump创建一个dump（转储）文件来转储不能被旧服务器访问的所有表。
4.    停止新MySQL服务器，重新启动旧MySQL服务器。
将dump（转储）文件重载入旧服务器。表应当可访问。

但是我的解决方法更加简洁：
卸载 5.0.67 版本的数据库，
在社区下载最新的 5.5.15 版本数据库装上，一切OK。
除了在5.5.15 版本 'general_log' 和 'slow_log' 等不再使用的表之外，其余表全部恢复正常，嗨皮啊～～～

jinguanding

二位问题：

1.操作系统、文件系统不一样；
2.数据库的版本也差别太大；

建议mysqldump 的方式备份吧，先做成主从复制的方式，这样就可以减少对业务的影响

yqhzh

二位问题：

1.操作系统、文件系统不一样；
2.数据库的版本也差别太大；

建议mysqldump 的方式备份吧 ...
jinguanding 发表于 2011-09-07 13:36

个人认为，操作系统和文件系统不会造成以上问题。
因为迁移仅仅是copy，而非dd方式的包括文件系统的复制，只要是Linux可以识别的文件系统，均会自动按目的磁盘对应的文件系统方式写入目的机器。
如果能有这方面的实例，大家了解当然更好。

本次冷备的关键在于数据库版本差别太大，而且是降级使用，而不是向前兼容的升级。

mysqllog

哈哈，我一看两个mysql的版本不一致，而且还是高从低迁移，一般来说是低往高迁移~~