[ERROR]Space id in fsp header but in the page header一列

报错如下MYSQL不能正常启动

2017-09-22 10:39:05 21409 [Note] InnoDB: Database was not shutdown normally!2017-09-22 10:39:05 21409 [Note] InnoDB: Starting crash recovery.2017-09-22 10:39:05 21409 [Note] InnoDB: Reading tablespace information from the .ibd files...2017-09-22 10:39:05 21409 [ERROR] InnoDB: Space id in fsp header 1416128883,but in the page header 824195850 

我曾经写过这样一个文章如下：
InnoDB: Error: space id and page n:o stored in the page?
http://blog.itpub.net/7728585/viewspace-2121548/
但是上面的文章只是人为模拟，实际上在生产情况中严重得多，基本是块的物理顺坏，今天又有网友问我这个问题，实际上遇到这种问题一般都涉及到块的物理损坏了,修复的可能性并不大，我们来看看源码抛错位置：

/**********************************************************************//**Reads the space id from the first page of a tablespace.@return space id, ULINT UNDEFINED if error */ulintfsp_header_get_space_id(/*====================*/   const page_t*   page)   /*!< in: first page of a tablespace */{   ulint   fsp_id;   ulint   id;   fsp_id = mach_read_from_4(FSP_HEADER_OFFSET + page + FSP_SPACE_ID);   id = mach_read_from_4(page + FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID);   DBUG_EXECUTE_IF("fsp_header_get_space_id_failure",           id = ULINT_UNDEFINED;);   if (id != fsp_id) {       ib::error() << "Space ID in fsp header is " << fsp_id           << ", but in the page header it is " << id << ".";       return(ULINT_UNDEFINED);   }   return(id);} 

• FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID：PAGE HRADER中存储了space id在34后4字节，也就对应了报错中的but in the page header 824195850
• FSP_SPACE_ID：File space header中存储了space id在38字节后4个字节，也就对应了报错中的Space id in fsp header 1416128883

File space header是每一个表空间的第一个块才会有的，存储的信息如下:

/*          SPACE HEADER           ============File space header data structure: this data structure is contained in thefirst page of a space. The space for this header is reserved in every extentdescriptor page, but used only in the first. *//*-------------------------------------*/#define FSP_SPACE_ID        0   /* space id */#define FSP_NOT_USED        4   /* this field contained a value up to                   which we know that the modifications                   in the database have been flushed to                   the file space; not used now */#define FSP_SIZE        8   /* Current size of the space in                   pages */#define FSP_FREE_LIMIT      12  /* Minimum page number for which the                   free list has not been initialized:                   the pages >= this limit are, by                   definition, free; note that in a                   single-table tablespace where size                   < 64 pages, this number is 64, i.e.,                   we have initialized the space                   about the first extent, but have not                   physically allocated those pages to the                   file */#define FSP_SPACE_FLAGS     16  /* fsp_space_t.flags, similar to                   dict_table_t::flags */#define FSP_FRAG_N_USED     20  /* number of used pages in the                   FSP_FREE_FRAG list */#define FSP_FREE        24  /* list of free extents */#define FSP_FREE_FRAG       (24 + FLST_BASE_NODE_SIZE)                   /* list of partially free extents not                   belonging to any segment */#define FSP_FULL_FRAG       (24 + 2 * FLST_BASE_NODE_SIZE)                   /* list of full extents not belonging                   to any segment */#define FSP_SEG_ID      (24 + 3 * FLST_BASE_NODE_SIZE)                   /* 8 bytes which give the first unused                   segment id */#define FSP_SEG_INODES_FULL (32 + 3 * FLST_BASE_NODE_SIZE)                   /* list of pages containing segment                   headers, where all the segment inode                   slots are reserved */#define FSP_SEG_INODES_FREE (32 + 4 * FLST_BASE_NODE_SIZE)                   /* list of pages containing segment                   headers, where not all the segment                   header slots are reserved */ 

那么这个错误简单的说就是某个表空间ibd文件的第一个块的34后4字节和38字节后4个字节不能通过检测，但是要注意这仅仅是这8个字节一个检测。实际上这种错误基本对应着表空间文件的物理顺坏，一般来说其他字节也出现了问题，如果没有备份或者其他双机手段可能要导致这个表空间的数据丢失。好了我们回到案例。

随即我问这位朋友是否是独立表空间，他说是的，然后我们就需要找到到底哪个表空间出了问题。我曾经有一个读取二进制文件的工具，放到百度云盘：
http://pan.baidu.com/s/1num76RJ
可以直接读取这样的信息如下:

******************************************************************This Tool Is Uesed For Find The Data In Binary format(Hexadecimal)Usage:./bcview file blocksize offset cnt-bytes!                   file: Is Your File Will To Find Data!                             blocksize: Is N kb Block.Eg: 8 Is 8 Kb Blocksize(Oracle)!                                 Eg: 16 Is 16 Kb Blocksize(Innodb)!       offset:Is Every Block Offset Your Want Start!                                     cnt-bytes:Is After Offset,How Bytes Your Want Gets!                               Edtor QQ:22389860!                                                Used gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)                ******************************************************************----Current file size is :0.109375 Mb----Current use set blockszie is 16 Kb----Current file name is t6.ibdcurrent block:00000000--Offset:00036--cnt bytes:08--data is:001e0000001e0000 

我们可以得到数据

current block:00000000--Offset:00036--cnt bytes:08--data is:001e0000001e0000 

但是要扫描全部的ibd文件才能找到是哪个表空间检测出错，但是这个哥们shell也是比较好，写了一个如下的shell来完成：

find /opt/app/mysql5/var/ -iname \*.ibd > afor i in `cat ./a`;do ./bcview $i 16 34 8 | head -15 >> a.log;done 

这样将所有表空间的第一个块的信息的34-42字节信息都提取出来了，我随即查看了一下，找到了报错的表空间：

current block:00000000--Offset:00034--cnt bytes:08--data is:31203b0a54686973 

• 0X54686973 十进制为1416128883就是报错的Space id in fsp header 1416128883
• 0X31203b0a 十进制为1416128883就是报错的but in the page header 824195850

显然他们是不相等，正常情况下这8个字节4字节4字节比较是相同的，然后我查看了这个文件中块的checksum也是不相等，这个时候只有2个正常的处理方式：

1. 使用备份文件进行恢复
2. 如果这个表不重要可以移除掉ibd文件保留frm文件，可以正常启动，启动后drop掉这个表

后记

显然这里也再次重申了备份的重要性，遇到这样的错误，最安全的方式还是进行数据恢复，当然某些工具可以直接提取数据文件里面的数据，但是现有的版本支持并不是太好，而且风险也是特别大。

作者微信