undrop-for-innodb实测（一）-- 表结构恢复-阿里云开发者社区

介绍

undrop是一款针对mysql innodb的数据恢复工具，通过扫描文件或磁盘设备，然后解析innodb数据页进而恢复丢失的数据，对于drop、truncate以及文件损坏都很有帮助。本文介绍drop操作后表结构的恢复过程。

部署

软件包下载

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

依赖包安装

#此处安装必须的编译环境
shell> yum install make gcc flex bison

编译

shell> make
shell> ls
check_data.c  c_parser.o     innochecksum.c        Makefile      recover_dictionary.sh  sql_parser.o     stream_parser.o  test.sh
check_data.o  dictionary     innochecksum_changer  print_data.c  sakila                 sql_parser.y     sys_parser.c     vagrant
c_parser      fetch_data.sh  lex.yy.c              print_data.o  sql_parser.c           stream_parser    tables_dict.c
c_parser.c    include        LICENSE               README.md     sql_parser.l           stream_parser.c  tables_dict.o

到这里部署过程就结束了，这里介绍下几个重要的文件及目录：

dictionary目录。存放字典sql脚本，用于恢复表结构的几张核心字典表的DDL语句
sakila目录。测试schema
stream_parser。可执行文件，用于扫描文件或者磁盘设备，目的是找出符合innodb格式的数据页，按照index_id进行组织
c_parser。可执行文件，用于解析innodb数据页，获取行记录
sys_parser。可执行文件，通过字典表记录恢复目标表的表结构

环境准备

这款工具支持主流linux的4/5/6/7版本，mysql支持5.6/5.7。本文中测试的环境是centos7+MySQL5.7

[root@mydocker-test1 undrop-for-innodb]# cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 

mysql> select version();
+------------+
| version()  |
+------------+
| 5.7.20-log |
+------------+
1 row in set (0.00 sec)

接下来准备测试表

mysql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> select * from t1;
+----+----------+------+
| id | name     | age  |
+----+----------+------+
|  1 | zhangsan |   18 |
|  2 | lisi     |   21 |
|  3 | jack     |   17 |
|  4 | alei     |   25 |
+----+----------+------+
4 rows in set (0.00 sec)

然后进行删除操作

mysql> drop table t1;
Query OK, 0 rows affected (0.32 sec)

innodb数据字典介绍

在做恢复演示之前，首先插播一段innodb数据字典的介绍。

innodb数据字典存储在系统表空间，主要是用于记录innodb核心的对象信息，比如表、索引、字段等。字典的本质是REDUNDANT行格式的innodb表，并且对用户不可见。
为了便于用户查看，innodb提供了一系列的字典视图，视图提供的信息和字典表完全相同，这一部分内容我们可以在information_schema中找到。如下，

mysql> use information_schema -A;
Database changed
mysql> show tables where Tables_in_information_schema like '%innodb_sys%';
+------------------------------+
| Tables_in_information_schema |
+------------------------------+
| INNODB_SYS_DATAFILES         |
| INNODB_SYS_VIRTUAL           |
| INNODB_SYS_INDEXES           |
| INNODB_SYS_TABLES            |
| INNODB_SYS_FIELDS            |
| INNODB_SYS_TABLESPACES       |
| INNODB_SYS_FOREIGN_COLS      |
| INNODB_SYS_COLUMNS           |
| INNODB_SYS_FOREIGN           |
| INNODB_SYS_TABLESTATS        |
+------------------------------+
10 rows in set (0.00 sec)

接下来介绍几张对于数据恢复较为关键的几张字典表。

1、SYS_TABLES。对应视图INNODB_SYS_TABLES，提供innodb表的元数据信息，其中几个关键字段如下，
TABLE_ID。innodb表的标识id，这是组织字典信息的关键
NAME。表名
N_COLS。字段数量，包含innodb的三个隐藏字段，以及虚拟字段
FILE_FORMAT。文件格式
ROW_FORMAT。行格式

2、SYS_COLUMNS。对应视图INNODB_SYS_COLUMNS，提供innodb表中字段的元数据信息，其中关键字段如下，
TABLE_ID。表id，和sys_tables关联
NAME。字段名
POS。0开始的序号，表示字段在表中的位置
MTYPE/PRTYPE。字段类型，这是innodb的表示方法，前者是主体类型，后者是精确类型
LEN。字段长度

MTYPE
Stands for “main type”. A numeric identifier for the column type. 1 = VARCHAR, 2 = CHAR, 3 = FIXBINARY, 4 = BINARY, 5 = BLOB, 6 = INT, 7 = SYS_CHILD, 8 = SYS, 9 = FLOAT, 10 = DOUBLE, 11 = DECIMAL, 12 = VARMYSQL, 13 = MYSQL, 14 = GEOMETRY.
PRTYPE
The InnoDB “precise type”, a binary value with bits representing MySQL data type, character set code, and nullability.

3、SYS_INDEXES。对应视图INNODB_SYS_INDEXES，提供索引定义信息，关键字段如下，
INDEX_ID。索引id，这是组织数据的关键。innodb所有的数据都是基于B+tree进行组织，因此B+tree叶节点存储表数据以及二级索引数据，每个叶节点数据页存储index_id信息以标识所属的index。undrop-for-innodb工具扫描innodb数据页后通过index_id对数据页进行重组
NAME。索引名
TABLE_ID。表id，与sys_tables关联
PAGE_NO。B+tree索引根节点的页号

4、SYS_FIELDS。对应视图INNODB_SYS_FIELDS，提供索引定义中的字段信息。此信息可用于恢复二级索引
INDEX_ID。索引id，和SYS_INDEXES关联
NAME。字段名
POS。0开始的序号，表示字段在索引定义中的位置

有关字典表的描述，详细可参阅官方文档：
https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-system-tables.html

表结构恢复

接下来进行误删除操作后的数据恢复过程，本文介绍第一步，表结构的恢复，主要理解几张字典表的逻辑关系。
恢复表结构的实质是恢复被删除的字典数据，因此是需要在ibdata文件中字典数据不被重写的前提下进行，咱们这里在发生删除操作后首先关闭数据库实例。

[root@mydocker-test1 undrop-for-innodb]# 
[root@mydocker-test1 undrop-for-innodb]# mysqladmin -h127.0.0.1 -uroot -P3310 -p shutdown
Enter password:

然后解析ibdata文件，扫描出所有符合innodb格式的数据页，结果会按照index_id进行重新组织，

shell> ./stream_parser  -f  /home/my3310/data/ibdata1

此时会生成一个ibdata文件解析后的目录结构，接下来使用c_parser解析数据页，获取丢失的元数据行记录

#解析四张关键字典表的数据，获取已删表的数据结构。
#所有字典表的index_id是硬编码的，这里01是SYS_TABLES，02是SYS_COLUMNS，03是SYS_INDEXES，04是SYS_FIELDS。
shell> mkdir -p dumps/default
shell> ./c_parser  -4Df  pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t  dictionary/SYS_TABLES.sql >./dumps/default/SYS_TABLES  2>./dumps/default/SYS_TABLES.sql
shell> ./c_parser  -4Df  pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page  -t  dictionary/SYS_INDEXES.sql >./dumps/default/SYS_INDEXES  2>./dumps/default/SYS_INDEXES.sql
shell> ./c_parser  -4Df  pages-ibdata1/FIL_PAGE_INDEX/0000000000000002.page  -t  dictionary/SYS_COLUMNS.sql >./dumps/default/SYS_COLUMNS  2>./dumps/default/SYS_COLUMNS.sql
shell> ./c_parser  -4Df  pages-ibdata1/FIL_PAGE_INDEX/0000000000000004.page  -t  dictionary/SYS_FIELDS.sql >./dumps/default/SYS_FIELDS  2>./dumps/default/SYS_FIELDS.sql

这里有几个选项：
-4Df 。最前面的数字4/5表示行格式REDUNDANT/COMPACT，D表示获取被删除的记录，f后面指定文件
-t 。指定建表语句，生成的结果会根据表结构进行组织

注意：
这里有个地方需要注意，就是这个输出的文件路径./dumps/default，这是工具里代码固定的，因此在此步骤之前我们必须要创建这个目录 $BASEDIR/dumps/default

接下来查看下解析结果，

shell> cd dumps/default/
shell> ls
SYS_COLUMNS  SYS_COLUMNS.sql  SYS_FIELDS  SYS_FIELDS.sql  SYS_INDEXES  SYS_INDEXES.sql  SYS_TABLES  SYS_TABLES.sql

现在我们看到的就是恢复出来的元数据记录，每张字典表有两个文件，和表名同名的文件已文本形式保存行记录，另一个SQL文件是根据表结构生成的loda data语句。

接下来在本地库上将字典数据恢复出来，注意这里需要是另外一个mysql实例，因为为了避免数据文件被复写，我们此前已经将事故实例停止了服务。

#根据工具dictionary目录中的SQL脚本创建字典表
mysql> create database dictionary;
mysql> use dictionary;

mysql> source  ../dictionary/SYS_TABLES.sql
mysql> source  ../dictionary/SYS_INDEXES.sql
mysql> source  ../dictionary/SYS_FIELDS.sql
mysql> source  ../dictionary/SYS_COLUMNS.sql

#执行前面生成的LOAD DATA语句导入恢复的记录
shell> mysql -h127.0.0.1 -uroot  -p dictionary <SYS_TABLES.sql
shell> mysql -h127.0.0.1 -uroot  -p dictionary <SYS_COLUMNS.sql
shell> mysql -h127.0.0.1 -uroot  -p dictionary <SYS_INDEXES.sql
shell> mysql -h127.0.0.1 -uroot  -p dictionary <SYS_FIELDS.sql

到这里工作已经基本完成，因为恢复出来的元数据信息，我们已经可以在本地实例的表中查看了。接下来就是最后一步，使用sys_parser读取表中的元数据记录，并生成DDL语句。

不过这里sys_parser需要单独编译，

shell> make sys_parser
/opt/mysql/bin/mysql_config
cc -o sys_parser sys_parser.c `mysql_config --cflags` `mysql_config --libs`

最好联合mysql的安装路径进行编译，如果已经编译完成并出现如下报错的话，可以修改ld配置解决

[root@mydocker-test1 undrop-for-innodb]# ./sys_parser -h127.0.0.1  -uroot  -p****   -d dictionary  test_1/t1
./sys_parser: error while loading shared libraries: libmysqlclient.so.20: cannot open shared object file: No such file or directory

[root@mydocker-test1 undrop-for-innodb]# vi /etc/ld.so.conf.d/mariadb-x86_64.conf 
/opt/mysql/lib
[root@mydocker-test1 undrop-for-innodb]# ldconfig

执行sys_parser，需要注意的是，用作表结构恢复的实例端口必须为3306，这里没有提供端口选项。

[root@mydocker-test1 undrop-for-innodb]# ./sys_parser -h127.0.0.1  -uroot -p***  -d dictionary  test_1/t1
CREATE TABLE `t1`(
    `id` INT NOT NULL,
    `name` VARCHAR(20) CHARACTER SET 'utf8' COLLATE 'utf8_general_ci',
    `age` INT,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB;

大功告成，但是好像有一点不对？
是的，对比前面环境准备中原始的表结构，这里少了一些信息，就是二级索引。undrop-for-innodb的表结构恢复功能，只会恢复表的主干信息，不包含自增、二级索引以及外键等信息。但是这些信息我们可以通过字典数据获取。

这里我们首先通过SYS_INDEXES表找到该表的索引信息，发现除了primary key之外还有一个二级索引name，

mysql> select * from SYS_INDEXES where TABLE_ID=41;
+----------+----+---------+----------+------+-------+------------+
| TABLE_ID | ID | NAME    | N_FIELDS | TYPE | SPACE | PAGE_NO    |
+----------+----+---------+----------+------+-------+------------+
|       41 | 42 | PRIMARY |        1 |    3 |    26 | 4294967295 |
|       41 | 43 | name    |        1 |    0 |    26 | 4294967295 |
+----------+----+---------+----------+------+-------+------------+
2 rows in set (0.00 sec)

然后通过SYS_FIELDS表查找这个索引的字段定义。

mysql> select * from SYS_FIELDS  where index_id=43;
+----------+-----+----------+
| INDEX_ID | POS | COL_NAME |
+----------+-----+----------+
|       43 |   0 | name     |
+----------+-----+----------+
1 row in set (0.00 sec)

然后我们就可以通过alter table语句恢复二级索引了。索引名为'name'，并且定义中只有name这一个字段

mysql> alter table t1 add key `name`(name);

其他的表结构信息也可以通过类似方式进行手工恢复。

结语

本文基于undrop-for-innodb工具，在发生innodb的drop操作后进行表结构恢复的操作，主要是通过这个过程理解innodb字典的逻辑关系。

undrop-for-innodb实测（一）-- 表结构恢复

介绍

部署

环境准备

innodb数据字典介绍

表结构恢复

结语

热门文章

最新文章

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

undrop-for-innodb实测（一）-- 表结构恢复

介绍

部署

环境准备

innodb数据字典介绍

表结构恢复

结语

热门文章

最新文章

相关电子书

相关实验场景