how to recovery innodb from Pages from .idb (Part IV)
时间:2010-08-22 来源:Steven1981
TEST STEP4:编译percona-innodb-recovery-tool,make
TEST STEP5:将数据表空间拆分成N个16K大小的PAGE
TEST STEP3:得到表定义文件:table_defs.h (可以用create_defs.pl自动产生),并替换include/table_defs.h.
----------------------
|| [root@localhost percona-innodb-recovery-tool]# perl create_defs.pl --table=recover1
|| #ifndef table_defs_h
|| #define table_defs_h
||
|| // Table definitions
|| table_def_t table_definitions[] = {
|| {
|| name: "recover1",
|| {
|| { /* int(11) */
|| name: "id",
|| type: FT_INT,
|| fixed_length: 4,
||
|| has_limits: TRUE,
|| limits: {
|| can_be_null: FALSE,
|| int_min_val: -2147483648LL,
|| int_max_val: 2147483647LL
|| },
||
|| can_be_null: FALSE
|| },
|| { /* */
|| name: "DB_TRX_ID",
|| type: FT_INTERNAL,
|| fixed_length: 6,
||
|| can_be_null: FALSE
|| },
|| { /* */
|| name: "DB_ROLL_PTR",
|| type: FT_INTERNAL,
|| fixed_length: 7,
||
|| can_be_null: FALSE
|| },
|| { /* varchar(50) */
|| name: "c1",
|| type: FT_CHAR,
|| min_length: 0,
|| max_length: 50,
||
|| has_limits: TRUE,
|| limits: {
|| can_be_null: TRUE,
|| char_min_len: 0,
|| char_max_len: 50,
|| char_ascii_only: TRUE
|| },
||
|| can_be_null: TRUE
|| },
|| { /* varchar(100) */
|| name: "c2",
|| type: FT_CHAR,
|| min_length: 0,
|| max_length: 100,
||
|| has_limits: TRUE,
|| limits: {
|| can_be_null: TRUE,
|| char_min_len: 0,
|| char_max_len: 100,
|| char_ascii_only: TRUE
|| },
||
|| can_be_null: TRUE
|| },
|| { type: FT_NONE }
|| }
|| },
|| };
||
|| #endif
# 在确定表结构无误后,将结果输出到 include/table_defs.h
cd /opt/percona-innodb-recovery-tool
perl create_defs.pl --table=recover1 > /opt/percona-innodb-recovery-tool/include/table_defs.h
TEST STEP4:编译percona-innodb-recovery-tool,make ()
----------------------
# 这一步之前必须先确定include/table_def.h , 因为数据抽取程序编译必须有这个头文件。
cd /opt/percona-innodb-recovery-tool
make
TEST STEP5:将数据表空间拆分成N个16K大小的PAGE
----------------------
|| cd /opt/percona-innodb-recovery-tool
|| [root@localhost percona-innodb-recovery-tool]# ./page_parser -5 -f /opt/recover1.ibd
|| Opening file: /opt/recover1.ibd
|| Read data from fn=3...
|| Read page #0.. saving it to pages-1282459607/4294967295-65535/0-00000000.page
|| Read page #1.. saving it to pages-1282459607/0-51/1-00000001.page
|| Read page #2.. saving it to pages-1282459607/4294967295-65535/2-00000002.page
|| Read page #3.. saving it to pages-1282459607/0-447/3-00000003.page
|| Read page #4.. saving it to pages-1282459607/0-447/4-00000004.page
|| Read page #5.. saving it to pages-1282459607/0-447/5-00000005.page
|| Read page #6.. saving it to pages-1282459607/0-447/6-00000006.page
|| Read page #7.. saving it to pages-1282459607/0-447/7-00000007.page
|| Read page #8.. saving it to pages-1282459607/0-447/8-00000008.page
|| Read page #9.. saving it to pages-1282459607/0-447/9-00000009.page
|| Read page #10.. saving it to pages-1282459607/0-447/10-00000010.page
|| Read page #11.. saving it to pages-1282459607/0-447/11-00000011.page
|| Read page #12.. saving it to pages-1282459607/0-447/12-00000012.page
|| Read page #13.. saving it to pages-1282459607/0-447/13-00000013.page
|| Read page #14.. saving it to pages-1282459607/0-447/14-00000014.page
|| Read page #0.. saving it to pages-1282459607/0-0/15-00000000.page
##The -5 option stands for MySQL 5 (with COMPACT format). For MySQL < 5, use -4.
##The result of this utility is the pages split from the shared tablespace file.
##Some of these pages contain our data. Others are irrelevant for our purposes.
## 这里,我们要用到STEP2中得到的index_id=447, 那么我们要找的数据其实就是在pages-1282459607/0-447目录里。
## 为什么我们的数据就在主键相关的PAGE里呢?
## 这是INNODB的存储机制决定的。 其实INNODB就是一个INDEX_CLUSTER_TABLE,
## If record size < (UNIV_PAGE_SIZE/2-200) == ~7k – the record is stored internally (in a PK page)
## Otherwise – 768 bytes internally, the rest in an external page
## 这一点在这里不继续展开,有兴趣的同学可以研究一下:INNODB PAGE FORMAT。
待续... ...