mysql undrop_使用undrop-for-innodb工具在无备份的情况下恢复mysql表

最新推荐文章于 2024-06-23 09:42:44 发布
最新推荐文章于 2024-06-23 09:42:44 发布
阅读量189 收藏
点赞数
文章标签： mysql undrop
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39964573/article/details/114766699
版权

背景

最近一个朋友说，程序误删了一张表，但是没有备份。我一心想，这不是凉凉了。因为按照正常的情况，如果误删了表，在有备份的情况下，可以通过备份+binlog的方式找回数据。如果没有备份的话，想找回数据基本是没什么希望了。本着死马当活马医的态度，在网上google了一阵，发现了竟然还有undrop-for-innodb这一个工具。

undrop-for-innodb工具按照描述，是可以实现在无备份的情况下，通过扫描ibdata1文件和磁盘文件，来找回删除表的数据。话不多说，立马实验一下。

恢复步骤

使用undrop-for-innodb工具分两种情况，分别是innodb_file_per_table=OFF和innodb_file_per_table=ON两种情况。innodb_file_per_table参数描述了innodb存储引擎存储数据的方式。如果为OFF，则库表的所有数据都存放在ibdata*的共享表空间内，若为ON，则每个表会生成独立的文件来存储数据。

在如今的 mysql 版本中，innodb_file_per_table参数默认为ON，于是这里来重点讲一下innodb_file_per_table=ON的这种情况。

一：安装undrop-for-innodb工具。

# git clone https://github.com/twindb/undrop-for-innodb.git

# yum install -y make gcc flex bison

# cd undrop-for-innodb

# make

安装完之后，会在undrop-for-innodb目录下生成stream_parser和c_parser文件。

二：模拟mysql表误删操作：

这里我有一个iceny.assets_host_auth，里面存放了一些我自己系统的用户信息，如下：

0e0ee675ea495d580fd60680b22bbde2.png

删除assets_host_auth表：

mysql> drop table assets_host_auth;

Query OK, 0 rows affected (0.01 sec)

三，扫描磁盘页以及ibdata文件

# df -k

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/centos-root 19703808 6701800 13002008 35% /

devtmpfs 922464 0 922464 0% /dev

tmpfs 933524 0 933524 0% /dev/shm

tmpfs 933524 16952 916572 2% /run

tmpfs 933524 0 933524 0% /sys/fs/cgroup

/dev/sda1 201380 123252 78128 62% /boot

tmpfs 186708 0 186708 0% /run/user/0

# ./stream_parser -f /dev/mapper/centos-root -t 19703808k

Opening file: /dev/mapper/centos-root

File information:

ID of device containing file: 5

inode number: 2006

protection: 60660 (block device)

number of hard links: 1

user ID of owner: 0

group ID of owner: 6

device ID (if special file): 64768

blocksize for filesystem I/O: 4096

number of blocks allocated: 0

time of last access: 1533986548 Sat Aug 11 07:22:28 2018

time of last modification: 1533984737 Sat Aug 11 06:52:17 2018

time of last status change: 1533984737 Sat Aug 11 06:52:17 2018

total size, in bytes: 0 (0.000 exp(+0))

Size to process: 20176699392 (18.791 GiB)

Opening file: /dev/mapper/centos-root

File information:

ID of device containing file: 5

inode number: 2006

protection: 60660 (block device)

number of hard links: 1

user ID of owner: 0

group ID of owner: 6

device ID (if special file): 64768

blocksize for filesystem I/O: 4096

number of blocks allocated: 0

time of last access: 1533986548 Sat Aug 11 07:22:28 2018

time of last modification: 1533984737 Sat Aug 11 06:52:17 2018

time of last status change: 1533984737 Sat Aug 11 06:52:17 2018

total size, in bytes: 0 (0.000 exp(+0))

Size to process: 20176699392 (18.791 GiB)

Worker(0): 1.16% done. 2018-08-13 20:20:29 ETA(in 00:06:06). Processing speed: 25.949 MiB/sec

Worker(1): 1.16% done. 2018-08-13 20:22:01 ETA(in 00:07:37). Processing speed: 20.766 MiB/sec

Worker(0): 2.24% done. 2018-08-13 20:20:29 ETA(in 00:06:02). Processing speed: 25.949 MiB/sec

Worker(1): 2.24% done. 2018-08-13 20:25:05 ETA(in 00:10:34). Processing speed: 14.828 MiB/sec

Worker(0): 3.32% done. 2018-08-13 20:23:30 ETA(in 00:08:57). Processing speed: 17.300 MiB/sec

Worker(1): 3.32% done. 2018-08-13 20:20:33 ETA(in 00:05:58). Processing speed: 25.957 MiB/sec

Worker(0): 4.40% done. 2018-08-13 20:22:01 ETA(in 00:07:23). Processing speed: 20.760 MiB/sec

Worker(1): 4.40% done. 2018-08-13 20:20:33 ETA(in 00:05:54). Processing speed: 25.949 MiB/sec

Worker(0): 5.48% done. 2018-08-13 20:20:32 ETA(in 00:05:50). Processing speed: 25.949 MiB/sec

Worker(1): 5.48% done. 2018-08-13 20:22:02 ETA(in 00:07:18). Processing speed: 20.759 MiB/sec

Worker(0): 6.56% done. 2018-08-13 20:22:00 ETA(in 00:07:13). Processing speed: 20.759 MiB/sec

Worker(1): 6.56% done. 2018-08-13 20:20:34 ETA(in 00:05:46). Processing speed: 25.949 MiB/sec

Worker(0): 7.64% done. 2018-08-13 20:20:33 ETA(in 00:05:42). Processing speed: 25.949 MiB/sec

Worker(1): 7.64% done. 2018-08-13 20:20:34 ETA(in 00:05:42). Processing speed: 25.949 MiB/sec

Worker(0): 8.71% done. 2018-08-13 20:19:07 ETA(in 00:04:13). Processing speed: 34.616 MiB/sec

Worker(0): 9.80% done. 2018-08-13 20:16:18 ETA(in 00:01:23). Processing speed: 104.000 MiB/sec

Worker(1): 8.71% done. 2018-08-13 20:19:08 ETA(in 00:04:13). Processing speed: 34.599 MiB/sec

Worker(0): 11.21% done. 2018-08-13 20:15:58 ETA(in 00:01:02). Processing speed: 136.000 MiB/sec

Worker(1): 9.79% done. 2018-08-13 20:19:08 ETA(in 00:04:10). Processing speed: 34.599 MiB/sec

Worker(0): 12.29% done. 2018-08-13 20:20:25 ETA(in 00:05:25). Processing speed: 25.953 MiB/sec

Worker(1): 10.87% done. 2018-08-13 20:19:08 ETA(in 00:04:07). Processing speed: 34.599 MiB/sec

Worker(1): 11.95% done. 2018-08-13 20:19:08 ETA(in 00:04:04). Processing speed: 34.605 MiB/sec

Worker(0): 13.37% done. 2018-08-13 20:23:07 ETA(in 00:08:01). Processing speed: 17.299 MiB/sec

Worker(1): 13.03% done. 2018-08-13 20:19:08 ETA(in 00:04:01). Processing speed: 34.599 MiB/sec

# ./stream_parser -f /opt/data/mysql_3306/ibdata1

扫描完之后，会在当前目录下生成相关的目录：

1ea6f8474c71e44d6662b9d75fcbf6f9.png

四，找出assets_host_auth表数据所在的磁盘页。

1，找出assets_host_auth的表ID：

./c_parser -4Df ./pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t ./dictionary/SYS_TABLES.sql | grep assets

000000002D0A 2A0000017E28FC SYS_TABLES "iceny/assets\_host\_auth" 185 4 33 0 80 "" 178

SET FOREIGN_KEY_CHECKS=0;

LOAD DATA LOCAL INFILE '/tmp/undrop-for-innodb-master/dumps/default/SYS_TABLES000000002D0A 2A0000017E28FC SYS_TABLES "iceny/assets\_host\_auth" 185 4 33 080 "" 178

' REPLACE INTO TABLE `SYS_TABLES` FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '"' LINES STARTING BY 'SYS_TABLES\t' (`NAME`, `ID`, `N_COLS`, `TYPE`, `MIX_ID`, `MIX_LEN`, `CLUSTER_NAME`, `SPACE`);

-- STATUS {"records_expected": 122, "records_dumped": 34, "records_lost": true} STATUS END

表ID为表名后面的那个数字，这里为185。

2，利用找出来的表ID，查找assets_host_auth的磁盘页ID：

# ./c_parser -4Df ./pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t ./dictionary/SYS_INDEXES.sql | grep 185

000000002D0A 2A0000017E27EB SYS_INDEXES 185 335 "PRIMARY" 1 3 178 4294967295

000000001140 2500000139185D SYS_INDEXES 119 207 "PRIMARY" 1 3 105 4294967295

000000002D0A 2A0000017E27EB SYS_INDEXES 185 335 "PRIMARY" 1 3 178 4294967295

000000001140 2500000139185D SYS_INDEXES 119 207 "PRIMARY" 1 3 105 4294967295

SET FOREIGN_KEY_CHECKS=0;

这里可以明细那看到，ID185对应的数值是335，这里的335就是assets_host_auth数据所在的的磁盘页ID。

3，查看扫描的磁盘页中是否存在335的page：

# ll pages-centos-root/FIL_PAGE_INDEX/0000000000000335.page

-rw-r--r-- 1 root root 65536 Aug 13 20:31 pages-centos-root/FIL_PAGE_INDEX/0000000000000335.page

可以看到335page确实存在。

4，创建assets_host_auth.sql文件，内容是assets_host_auth表的数据结构：

# vi iceny/assets_host_auth.sql

CREATE TABLE `assets_host_auth` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`host_ip` varchar(20) NOT NULL,

`password` varchar(100) DEFAULT NULL,

`env` varchar(20) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8;

5，利用存在的磁盘page查看assets_host_auth数据是否还在；

./c_parser -6f pages-centos-root/FIL_PAGE_INDEX/0000000000000335.page -t iceny/assets_host_auth.sql | head -5

-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)

000000002690 DF000001C10110 assets_host_auth 1 "192.168.204.128" "123456" "cmh\_test"

000000002690 DF000001C1011D assets_host_auth 17 "192.168.1.11" "]t;:<8qCLfse+8LZZhK+11" "HB"

000000002690 DF000001C1012A assets_host_auth 19 "192.168.1.12" "]t;:<8qCLfse+8LZZhK+12" "HB"

000000002690 DF000001C10137 assets_host_auth 20 "192.168.1.113" "]t;:<8qCLfse+8LZZhK+113" "HB"

这里可以看到找到了一些相关的数据。

6，导出数据，生成sql导入文件：

# ./c_parser -6f pages-centos-root/FIL_PAGE_INDEX/0000000000000335.page -t iceny/assets_host_auth.sql > dumps/default/assets_host_auth 2> dumps/default/assets_host_auth.sql

# more dumps/default/assets_host_auth.sql

SET FOREIGN_KEY_CHECKS=0;

LOAD DATA LOCAL INFILE '/tmp/undrop-for-innodb-master/dumps/default/assets_host_auth' REPLACE INTO TABLE `assets_host_auth` FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '"' LINES STA

RTING BY 'assets_host_auth\t' (`id`, `host_ip`, `password`, `env`);

-- STATUS {"records_expected": 20, "records_dumped": 20, "records_lost": false} STATUS END

# more /tmp/undrop-for-innodb-master/dumps/default/assets_host_auth

-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)

000000002690 DF000001C10110 assets_host_auth 1 "192.168.204.128" "123456" "cmh\_test"

000000002690 DF000001C1011D assets_host_auth 17 "192.168.1.11" "]t;:<8qCLfse+8LZZhK+11" "HB"

000000002690 DF000001C1012A assets_host_auth 19 "192.168.1.12" "]t;:<8qCLfse+8LZZhK+12" "HB"

000000002690 DF000001C10137 assets_host_auth 20 "192.168.1.113" "]t;:<8qCLfse+8LZZhK+113" "HB"

000000002690 DF000001C10144 assets_host_auth 21 "192.168.1.15" "]t;:<8qCLfse+8LZZhK+15" "HB"

-- Page id: 3, Found records: 5, Lost records: NO, Leaf page: YES

-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)

000000002690 DF000001C10110 assets_host_auth 1 "192.168.204.128" "123456" "cmh\_test"

000000002690 DF000001C1011D assets_host_auth 17 "192.168.1.11" "]t;:<8qCLfse+8LZZhK+11" "HB"

000000002690 DF000001C1012A assets_host_auth 19 "192.168.1.12" "]t;:<8qCLfse+8LZZhK+12" "HB"

000000002690 DF000001C10137 assets_host_auth 20 "192.168.1.113" "]t;:<8qCLfse+8LZZhK+113" "HB"

000000002690 DF000001C10144 assets_host_auth 21 "192.168.1.15" "]t;:<8qCLfse+8LZZhK+15" "HB"

-- Page id: 3, Found records: 5, Lost records: NO, Leaf page: YES

-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)

000000002690 DF000001C10110 assets_host_auth 1 "192.168.204.128" "123456" "cmh\_test"

000000002690 DF000001C1011D assets_host_auth 17 "192.168.1.11" "]t;:<8qCLfse+8LZZhK+11" "HB"

000000002690 DF000001C1012A assets_host_auth 19 "192.168.1.12" "]t;:<8qCLfse+8LZZhK+12" "HB"

000000002690 DF000001C10137 assets_host_auth 20 "192.168.1.113" "]t;:<8qCLfse+8LZZhK+113" "HB"

000000002690 DF000001C10144 assets_host_auth 21 "192.168.1.15" "]t;:<8qCLfse+8LZZhK+15" "HB"

-- Page id: 3, Found records: 5, Lost records: NO, Leaf page: YES

-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)

000000002690 DF000001C10110 assets_host_auth 1 "192.168.204.128" "123456" "cmh\_test"

000000002690 DF000001C1011D assets_host_auth 17 "192.168.1.11" "]t;:<8qCLfse+8LZZhK+11" "HB"

000000002690 DF000001C1012A assets_host_auth 19 "192.168.1.12" "]t;:<8qCLfse+8LZZhK+12" "HB"

000000002690 DF000001C10137 assets_host_auth 20 "192.168.1.113" "]t;:<8qCLfse+8LZZhK+113" "HB"

000000002690 DF000001C10144 assets_host_auth 21 "192.168.1.15" "]t;:<8qCLfse+8LZZhK+15" "HB"

-- Page id: 3, Found records: 5, Lost records: NO, Leaf page: YES

可以看到，我们已经找回了我们所删除的数据，最后要做的，就是把这些数据导入 数据库 中去：

7，把数据导入数据库：

#导入表结构

mysql> use iceny;

Database changed

mysql> source /tmp/undrop-for-innodb-master/iceny/assets_host_auth.sql

Query OK, 0 rows affected (0.21 sec)

导入数据，并查看：

c960ac1b9063e13af78e595d5277e11c.png

对比之前的数据，发现并无差异，至此，我们就通过undrop-for-innodb工具在无备份的情况下找回了数据。

undrop-for-innodb的一些问题(个人猜想)

由于undrop-for-innodb是通过扫描磁盘页来找回数据的，所以在删除表的一定短时间内，来用这种方法来找回数据是可行的。若是时间过长，磁盘页由于大量的IO操作，导致刷新了，有可能数据就被刷新掉了，这时候能不能找回数据，就不一定了。所以，在发现执行了误操作后，应立即停止mysql，把数据磁盘挂载为只读模式，避免数据页被刷新。

weixin_39964573
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql undrop_innodb 表损坏，导致mysqld 重启
weixin_33220360的博客
02-27 880
1. 版本1)操作系统版本cat /proc/versionLinux version 3.10.0-1062.9.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Fri Dec 6 15:49:49 UTC 20192)数...
【MySQL】无备份情况下恢复MySQL误删的表，这样做再也不用怕误删了
keeper42的博客
01-29 1363
本文主要分享在没有备份的情况下，MySQL数据库如何恢复被删除的表。 包含两个主要的场景： 1、drop table后的恢复 2、truncate table后的恢复 正文： 我们都知道，MySQL Server都很多存储引擎，并不是每种都可以进行异常情况之下都恢复，比如drop table/tuncate table/delete table/update table /drop database又或者是ibdata文件损坏之类的。用的最多的就是Myisam和innodb存储引擎。目前基本上都是
undrop-for-innodb
02-22
yum install make gcc flex bison cd /root/undrop-for-innodb-master make 会产生三个文件c_parser innochecksum_changer stream_parser
MySQL · 数据恢复 · undrop-for-innodb
weixin_34192993的博客
11-21 269
简介 undrop-for-innodb 是针对 innodb 的一套数据恢复工具，可以从文件级别恢复诸如：DROP/TRUNCATE table, 删除表中某些记录，innodb 文件被删除，文件系统损坏，磁盘 corruption 等几种情况。本文简单介绍下使用方法和原理浅析。 准备 git clone https://github.com/tw...
探索数据恢复的奇迹：TwinDB 数据恢复工具箱
最新发布
gitblog_00041的博客
06-23 377
探索数据恢复的奇迹：TwinDB 数据恢复工具箱 undrop-for-innodbTwinDB data recovery toolkit for MySQL/InnoDB项目地址:https://gitcode.com/gh_mirrors/und/undrop-for-innodb 在数据的海洋中，每一次意外都可能造成不可估量的损失。然而，有了 TwinDB 数据恢复工具箱（也被称为“Un...
MySQL • 数据恢复 • undrop-for-innodb
京庐空间
12-14 394
简介 undrop-for-innodb 是针对 innodb 的一套数据恢复工具，可以从文件级别恢复诸如：DROP/TRUNCATE table, 删除表中某些记录，innodb 文件被删除，文件系统损坏，磁盘 corruption 等几种情况。本文简单介绍下使用方法和原理浅析。 阿里云服务器幸运卷最后一波，下单记得选择幸运卷有惊喜有优惠哦！下完单记得抽奖哦，基本100%中，
使用undrop-for-innodb恢复Innodb引擎下误删的数据
wk544863858的博客
04-10 1871
使用undrop-for-innodb工具恢复被drop database误删的数据
undrop-for-innodb:适用于MySQLInnoDB的TwinDB数据恢复工具包
05-11
TwinDB数据恢复工具包是一组工具，可在较低级别上与MySQL文件一起使用，并允许在不同的故障情况后恢复InnoDB数据库。 该工具箱也称为InnoDB的UnDrop ，其名称更准确，因为该工具箱可用于InnoDB表。 当备份不可用时...
MySQL异常恢复-drop表恢复.docx
06-24
MySQL 异常恢复-drop 表恢复 MySQL 异常恢复是指在 MySQL 数据库出现异常情况时，恢复数据库的操作。drop 表恢复是指在 MySQL 数据库中删除...使用 undrop-for-innodb 工具可以恢复被删除的表，避免了数据丢失的风险。
UnDROP tool for InnoDB
渔夫数据库笔记
05-03 1657
UnDROP tool for InnoDB TwinDB data recovery toolkit is a set of tools that work with InnoDB tablespaces at low level. Incredible Performance of stream_parser stream_parser is a tool that find
使用undrop-for-innodb工具在无备份的情况下恢复mysql表
weixin_34217711的博客
08-13 785
背景    最近一个朋友说，程序误删了一张表，但是没有备份。我一心想，这不是凉凉了。因为按照正常的情况，如果误删了表，在有备份的情况下，可以通过备份+binlog的方式找回数据。如果没有备份的话，想找回数据基本是没什么希望了。本着死马当活马医的态度，在网上google了一阵，发现了竟然还有undrop-for-innodb这一个工具。    undrop-for-innodb工具按照描述，是可以实...
mysql undrop_UnDROP tool for InnoDB
weixin_33936194的博客
02-27 141
UnDROP tool for InnoDBTwinDB data recovery toolkit is a set of tools that work with InnoDB tablespaces at low level.Incredible Performance of stream_parserstream_parseris a tool that finds InnoDB pag...
mysql undrop_MySQL · 数据恢复 · undrop-for-innodb
weixin_31463861的博客
01-26 218
简介undrop-for-innodb 是针对 innodb 的一套数据恢复工具，可以从文件级别恢复诸如：DROP/TRUNCATE table, 删除表中某些记录，innodb 文件被删除，文件系统损坏，磁盘 corruption 等几种情况。本文简单介绍下使用方法和原理浅析。准备git clone https://github.com/twindb/undrop-for-innodb.gitm...
mysql undrop_undrop-for-innodb恢复drop的表
weixin_35773019的博客
02-27 260
说明：Undrop恢复是通过扫描文件或磁盘设备，然后解析innodb数据页进而恢复丢失的数据，对于drop、truncate进行恢复。目前mysql8.0以后版本暂未提供支持。准备安装完之后，会在undrop-for-innodb目录下生成stream_parser和c_parser文件gcc `/mysql/mysql5.7/bin/mysql_config --cflags` `/mysql/...
MySQL innodb DUL 数据文件离线抽取工具 undrop-for-innodb-windows
Lixora's DB Home
07-14 734
花了一点时间做了一个window版的 undrop for innodb ，用于windows 平台误操作（delete，drop，truncate）数据恢复，同时支持window 平台文件系统损坏时，在底层文件系统上上进行mysql ibd 挖掘，尽可能的恢复mysql 数据； mysql innodb dul for windows 平台 undrop-for-innodb-windows mysql 紧急技术恢复服务热线：1565865544 7 ...
undrop for innodb 怎么使用
02-14
"undrop for innodb" 是一款用于恢复 Innodb 数据库中丢失的数据的软件工具。使用方法如下： 1. 下载安装 "undrop for innodb" 软件。 2. 打开软件并选择要恢复的 Innodb 数据库文件。 3. 选择要恢复的数据表。 4. 进行数据恢复操作。 5. 保存恢复的数据到新的数据库中。 注意：使用 "undrop for innodb" 进行数据恢复有可能不是100%成功的，还需要根据具体情况进行评估。因此，在使用 "undrop for innodb" 之前，请务必备份原始数据库文件。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值