原创转载请注明出处
<人力资源/>
报错如下MYSQL不能正常启动
21409 10:39:05 2017-09-22[注]InnoDB:数据库不能正常关机! 21409 10:39:05 2017-09-22[注]InnoDB:开始崩溃恢复。 21409 10:39:05 2017-09-22[注]InnoDB:阅读从.ibd文件表空间信息… 21409 10:39:05 2017-09-22[错误]InnoDB:空间id fsp头1416128883,但在页眉824195850
我曾经写过这样一个文章如下:
InnoDB:错误:空间id和n页:存储在页面吗?
http://blog.itpub.net/7728585/viewspace-2121548/
但是上面的文章只是人为模拟,实际上在生产情况中严重得多,基本是块的物理顺坏,今天又有网友问我这个问题,实际上遇到这种问题一般都涉及到块的物理损坏了,修复的可能性并不大,我们来看看源码抛错位置:
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *//* *
从第一页读取空间id表空间。
@return空间id, ULINT定义如果错误*/ulint
fsp_header_get_space_id (/*====================*/const page_t *页面)/* ! & lt;:第一页的表空间*/{
ulint fsp_id;
ulint id;
fsp_id=mach_read_from_4 (FSP_HEADER_OFFSET + + FSP_SPACE_ID页);
id=mach_read_from_4 (+ FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID页);
DBUG_EXECUTE_IF (“fsp_header_get_space_id_failure”,
id=ULINT_UNDEFINED;);
如果(id !=fsp_id) {
ib:错误()& lt; & lt;“空间ID在fsp头是“& lt; & lt;fsp_id
& lt; & lt;在页眉”,但“& lt; & lt;id & lt; & lt;“。”;
返回(ULINT_UNDEFINED);
}
返回(id);
}
-
<李>
FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID:页面HRADER中存储了空间id在34后4字节,也就对应了报错中的但在页眉824195850
李
<李>
FSP_SPACE_ID:文件空间头中存储了空间id在38字节后4个字节,也就对应了报错中id在fsp头1416128883的空间
李
文件空间头是每一个表空间的第一个块才会有的,存储的信息如下:
/*空间头============文件空间头数据结构:此结构中包含的数据 第一页的一个空间。这个头的空间保留在每一个程度 描述符的页面,但使用alt="(误差)空间id fsp头但在页眉一列“>(错误)空间id fsp头但在页眉一列
