mysql frm idb_mysql/mariadb的数据恢复。没有libdata1，只有frm和idb文件的innodb的数据恢复...

由于服务器系统原因，在更新完成系统后发现新版的linux并不兼容老的硬件，导致系统崩溃，而我又未备份系统(唯独这次)，导致系统无法正常启动，相当于启动不了，然后就是数据库和服务全炸了。好在进入单用户模式下将数据库拷贝出来了。拷贝的数据库直接是全部的包，里面未包含libdata文件，只有数据库文件的frm以及idb，由于场景原因采用了innodb引擎的缘故。数据直接放在一个正常的机器下无法使用。应该是已经损坏。好在进行了之前的数据备份，所以不用在做frm的表导出操作。至于不会的直接参照下面

具体的方案作者已经说明，这里不在进行说明。我主要将下数据恢复的过程。

准备工作：

windows(或linux)

navicat for mysql

frm文件以及idb文件

安装mysql数据库，创建数据库数据编码必须一致

还原步骤：

1.    恢复原始的备份数据，主要是要表结构。

2.    原始数据恢复完成后将表空间卸载(innodb)。操作语句 alter table `要恢复的表名称` discard tablespace

3.    删除当前数据下面刚才卸载表空间的表文件(idb文件)

4.     将要恢复的文件复制到刚才删除文件的位置。

5.    执行表空间加载 alter table `要恢复的表名称` import tablespace; 、

此时就在打开表就可以看到恢复的数据了。

恢复过程中可能会有以下的问题

1.数据恢复出现错误 mysql err 1808 (ERROR 1808)，出现此类错误大部分情况下是由于当前恢复的数据版本与要恢复的数据之前的数据库运行版本不一致导致的，如mysql5.5 到 mysql 5.7之间恢复，或mariadb10.0与mariadb 10.3等。解决方法 第一种：更换数据库版本与损坏数据库版本一致，进行恢复操作即可。第二种：重新导入表结构，在创建表的时候加上 row_format=compact 这句话即可。然后再使用恢复方法进行回复即可。

2.表不存在The storage engine for the table doesn't support repair无法修复，或1932 - Table 'XXX' doesn't exist in engine等错误提示不存在。解决方法：检查表的idb的权限是否满足，在linux中必须是可读写权限，否则无法发现和修复数据。

3.恢复出的innodb数据乱码。这个是最容易产生的情况，我在恢复数据的时候发现数据中的时间全部是 “0000-00-00 00:00:22”，还有一些中文产生了乱码。找了大量的资料没有，只有自己来摸索研究。

解决办法：

第一种情况，数据库版本不匹配，重新安装数据库版本即可，

第二种情况，windows的环境下或者linnux的出现的，检查下是否是操作系统环境有问题，建议在恢复的时候安装在同等的操作环境下。

第三种情况，数据库的编码错误，创建数据库表的时候用的是gbk而恢复的数据是utf-8等这样类似的情况都属于编码错误导致。

4.    本人也有看别人说采用innodb_force_recovery 等操作方案，经过我的测试，本次恢复无效，恢复出来是大量的错误数据，大概有70%的正常数据，其他的全部是错误的。不建议采用。引用下：https://my.oschina.net/ion/blog/526649

注意以下几点就放弃恢复了，或者说本方法不适合恢复工作。

1.    数据库为共享数据库，可以查下共享数据库的概念。此时的恢复必须有lbdata才可以恢复。

2.    idb文件损坏，此时文件是无法被使用的，建议在备份后设置为只读模式进行恢复工作。

3.    表中含有大量的索引和外键约束，此时恢复的数据只可以看不能将恢复的表直接用于生产环境，修复、验证后才可以进行生产环境的替换。

4.     其他未知问题，(我没发现，还请自行留意)

=========================================================================================

写在最后，别没事就升级系统或者断电，先备份数据才是关键。