本文目录一览：
- 1、如何从ibd文件中恢复数据
- 2、mysql怎么通过frm和ibd文件还原数据
- 3、MySQL恢复数据为什么这么慢
- 4、mysql数据库怎么恢复单个表啊？
- 5、mysql数据库被破坏，只剩下ibd文件时如何恢复
- 6、系统崩溃后，关于MYSQL恢复数据库的问题！求救啊！
如何从ibd文件中恢复数据
在使用独立表空间的情况下,如果不慎使得innodb存储引擎的元数据文件ibdata损坏,我们还可以挽救宝贵的数据.因为在innodb使用独立表空间的情况下,ibdata文件会记录每个innodb表的id,只要使得ibd中的表id和ibdata文件中记录的表id相同,就能够打开表,读取到数据.
#创建表
CREATE TABLE `ibdtest` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`fid` int(11) NOT NULL COMMENT '表b中的id',
`content` char(255) NOT NULL COMMENT '操作内容,系统生成',
`mark` char(255) NOT NULL COMMENT '备注',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
#添加数据
INSERT ibdtest (fid,content,mark) VALUES (1,'1','1'),(2,'2','2');
SELECT * FROM ibdtest;
关闭MySQL将ibdtest.ibd copy出来,放到其他数据库中来模拟灾难.
[root@localhost ~]#/opt/soft/mysql/bin/mysqladmin -p123456 shutdown
120130 18:31:50 mysqld_safe mysqld from pidfile /opt/soft/mysql/60137.localdomain.pid ended
[1]+ Done /opt/soft/mysql/bin/mysqld_safe--defaults-file=/opt/soft/mysql/config/my.cnf --user=mysql
[root@localhost ~]# cd /home/soft/mysql/data/test/
[root@localhost test]# ll
total 1296
-rw-rw----. 1 mysql mysql 8612 Jan 18 00:06 a.frm
-rw-rw----. 1 mysql mysql 98304 Jan 18 00:24 a.ibd
-rw-rw----. 1 mysql mysql 8624 Jan 30 08:34 area.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 08:36 area.ibd
-rw-rw----. 1 mysql mysql 8642 Jan 18 00:05 b.frm
-rw-rw----. 1 mysql mysql 98304 Jan 18 00:08 b.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 18:27 ibdtest.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 18:28 ibdtest.ibd
-rw-rw----. 1 mysql mysql 8728 Jan 6 16:23 testa.frm
-rw-rw----. 1 mysql mysql 98304 Jan 10 04:10 testa.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 14:30 testmc.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 14:30 testmc.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 13:54 testme.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 13:55 testme.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 14:40 testmm.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 14:45 testmm.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 13:40 testmu.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 13:40 testmu.ibd
-rw-rw----. 1 mysql mysql 8693 Jan 30 11:08 testmv.frm
-rw-rw----. 1 mysql mysql 98304 Jan 30 11:10 testmv.ibd
-rw-rw----. 1 mysql mysql 8694 Jan 4 21:55 testuser.frm
-rw-rw----. 1 mysql mysql 98304 Jan 4 22:04 testuser.ibd
-rw-rw----. 1 mysql mysql 8644 Jan 14 21:55 user.frm
-rw-rw----. 1 mysql mysql 98304 Jan 14 21:55 user.ibd
[root@localhost test]# cp ibdtest.ibd /home/download/
[root@localhost test]# cd /home/download/
#vim打开ibd,使用16进制查看
[root@localhost download]# vim -b ibdtest.ibd
:%!xxd
从下图中能看到 此表在 当前mysql数据库中的id为0x10,即16.
此时,我们假设灾难发生,ibdata损坏…
只剩下了ibdtest.ibd文,我们跳转到另一个mysql服务器上,用同样的建表语句创建ibdtest表.
这时我们打开这个mysql服务器下的ibdtest.ibd看看:
这个表的id为0x16,即为22,那么,我们只需将原有的ibdtest.ibd表id修改为0x16即可.
出保存的时候一定要记得使用:%!xxd -r
退出保存.
并将修改好的文件覆盖掉新的ibdtest.ibd即可,
此mysql服务器会认为该表损毁,无法打开,没关系,修改innodb_force_recovery = 6,
重启mysql服务:
Select下,就知道数据是否恢复了没有:
此时,无法执行写操作,应尽快将数据dump出来,修改innodb_force_recovery = 0,重启服务,创建新表后,把数据倒回去就ok了.恢复数据就不演示了.
mysql怎么通过frm和ibd文件还原数据
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。 1. check table 和 repair table 登陆mysql 终端： mysql -uxxx...
MySQL恢复数据为什么这么慢
MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。
mysql数据库怎么恢复单个表啊？
Navicat Premium 上 可以备份单张表，备份出来的sql文件是 一些列的 insert into 语句。然后 你可以通过 date source（可能是这样的，你百度下吧，很久之前用的了 忘记了） 这个命令在 mysql 命令 里面 将单张表恢复。整个 数据库备份也差不多。
记得采纳啊
mysql数据库被破坏，只剩下ibd文件时如何恢复
在使用独立表空间的情况下,如果不慎使得innodb存储引擎的元数据文件ibdata损坏,我们还可以挽救宝贵的数据.因为在innodb使用独立表空间的情况下,ibdata文件会记录每个innodb表的id,只要使得ibd中的表id和ibdata文件中记录的表id相同,就能够打开表,读取到数据.
#创建表
CREATE TABLE `ibdtest` ( `id` int(11) NOT NULL AUTO_INCREMENT, `fid` int(11) NOT NULL COMMENT '表b中的id', `content` char(255) NOT NULL COMMENT '操作内容,系统生成', `mark` char(255) NOT NULL COMMENT '备注', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8
#添加数据INSERT ibdtest (fid,content,mark) VALUES (1,'1','1'),(2,'2','2');SELECT * FROM ibdtest;
系统崩溃后，关于MYSQL恢复数据库的问题！求救啊！
MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。
