您的位置:

关于mysql单表ibd文件恢复的信息

本文目录一览:

如何从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 变量,想法破灭。