Undrop-for-innodb从删库到跑路:修订间差异
来自三线的随记
小无编辑摘要 |
小无编辑摘要 |
||
(未显示同一用户的3个中间版本) | |||
第8行: | 第8行: | ||
=== 坑 === | === 坑 === | ||
# 寻找表ID的时候,配合grep命令使用有可能找不到有效的结果,去掉grep解决 | |||
# 最后导出来的数据一开始一堆乱码,并不是编码问题,而是c_parser ->-t参数CREATE statement 文件里面的语句有问题,并不是原来表的结构 | # 最后导出来的数据一开始一堆乱码,并不是编码问题,而是c_parser ->-t参数CREATE statement 文件里面的语句有问题,并不是原来表的结构 | ||
# | # 如上一条所示,需要提前准备表的结构文件,不然的话也得表结构恢复才能进行数据恢复 | ||
# 这工具针对不同的innodb_file_per_table方式用法有不同 | # 这工具针对不同的innodb_file_per_table方式用法有不同 | ||
# innodb_file_per_table参数描述了innodb存储引擎存储数据的方式。如果为OFF,则库表的所有数据都存放在ibdata*的共享表空间内,若为ON,则每个表会生成独立的文件来存储数据。 | # innodb_file_per_table参数描述了innodb存储引擎存储数据的方式。如果为OFF,则库表的所有数据都存放在ibdata*的共享表空间内,若为ON,则每个表会生成独立的文件来存储数据。 | ||
# show VARIABLES like '%innodb_file_per_table%' | # show VARIABLES like '%innodb_file_per_table%' | ||
=== 大概步骤 === | |||
# stream_parser扫描出磁盘页文件 | |||
# c_parser -> 0000000000000001.page + SYS_TABLES.sql ->得到表ID | |||
# c_parser + 表ID -> 0000000000000003.page + SYS_INDEXES.sql ->得到磁盘页ID | |||
# c_parser 磁盘页文件->-o *** -l ****导出数据 | |||
# 导出来的数据可能看起来不是SQL语句,用source命令导入就是了,两个文件(-o -l生成的) | |||
# 讲道理2-3步骤其实就是根据存在的表结构提取数据 | |||
= 没事别手贱 = | = 没事别手贱 = | ||
[[分类:Mysql]] | [[分类:Mysql]] |
2018年10月11日 (四) 20:31的最新版本
undrop-for-innodb --->mysql innodb引擎翻车用的恢复工具
教程1:http://blog.51cto.com/icenycmh/2158814?source=dra
教程1->快照:http://archive.fo/dydbj
git->https://github.com/twindb/undrop-for-innodb
坑
- 寻找表ID的时候,配合grep命令使用有可能找不到有效的结果,去掉grep解决
- 最后导出来的数据一开始一堆乱码,并不是编码问题,而是c_parser ->-t参数CREATE statement 文件里面的语句有问题,并不是原来表的结构
- 如上一条所示,需要提前准备表的结构文件,不然的话也得表结构恢复才能进行数据恢复
- 这工具针对不同的innodb_file_per_table方式用法有不同
- innodb_file_per_table参数描述了innodb存储引擎存储数据的方式。如果为OFF,则库表的所有数据都存放在ibdata*的共享表空间内,若为ON,则每个表会生成独立的文件来存储数据。
- show VARIABLES like '%innodb_file_per_table%'
大概步骤
- stream_parser扫描出磁盘页文件
- c_parser -> 0000000000000001.page + SYS_TABLES.sql ->得到表ID
- c_parser + 表ID -> 0000000000000003.page + SYS_INDEXES.sql ->得到磁盘页ID
- c_parser 磁盘页文件->-o *** -l ****导出数据
- 导出来的数据可能看起来不是SQL语句,用source命令导入就是了,两个文件(-o -l生成的)
- 讲道理2-3步骤其实就是根据存在的表结构提取数据