InnoDB: Error: space id and page n:o stored in the page?
发表于:2024-11-27 作者:千家信息网编辑
千家信息网最后更新 2024年11月27日,2016-06-08 04:38:11 7fa7ddd86700 InnoDB: Error: space id and page n:o stored in the pageInnoDB: read
千家信息网最后更新 2024年11月27日InnoDB: Error: space id and page n:o stored in the page?2016-06-08 04:38:11 7fa7ddd86700 InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 4294967295:4294967295, should be 22291:4096!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4096.
InnoDB: You may have to recover from a backup.
2016-06-08 04:38:11 7fa7ddd86700 InnoDB: Page dump in ascii and hex (16384 bytes):
所用到的工具是自己写的mysqlblock和bcview,
我放到了百度云盘
http://pan.baidu.com/s/1num76RJ
供大家下载和使用
今天MYSQL遇到上面的错误:
显然
InnoDB: read in are 4294967295:4294967295, should be 22291:4096!
这里抛出了出错信息,结合前面的提示翻译为,
在space id 22291的4096块上出现了问题,读到的信息为4294967295:4294967295
显现SPACE ID 读到的信息有误 4294967295
那么这第一个4294967295 是怎么来的呢。
首先我们要找到SPACEID 是22291是什么表
select * from INNODB_SYS_TABLESPACES where space = 22291;
然后取出他的ibd文件如果是单独的表空间就非常简单了,目的在于分析原因确定确实是这个表的问题。
然后使用工具查看二进制文件我使用的是自己编写的bcview工具。
******************************************************************
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)
******************************************************************
usage:./bcview file blocksize offset cnt-bytes!
其实这个4294967295来自于块的34-37 的4个字节,
如果我们打开2进制文件使用工具bcview(自己编写的)
./bcview product_info_snapshot.ibd 16 34 4|more
current block:00004096--Offset:00034--cnt bytes:04--data is:ffffffff
我们很清楚看到了这里4个字节全是ffffffff,实际上正常的块是
current block:00000085--Offset:00034--cnt bytes:04--data is:00005713
那么第二个4294967295也就是块号来自哪里呢?
其实这个块号我也占时没有找到他来自哪里,
但是他为什么能读取到正确的4096块呢?
肯能的原意你是每个块的 4-11 8个字节是当前的块号和上一个块的块号
我们来看看
current block:00004090--Offset:00004--cnt bytes:08--data is:00000ffa00000ff9
current block:00004091--Offset:00004--cnt bytes:08--data is:00000ffb00000ffa
current block:00004092--Offset:00004--cnt bytes:08--data is:00000ffc00000ffb
current block:00004093--Offset:00004--cnt bytes:08--data is:00000ffd00000ffc
current block:00004094--Offset:00004--cnt bytes:08--data is:00000ffe00000ffd
current block:00004095--Offset:00004--cnt bytes:08--data is:00000fff00000ffe
current block:00004096--Offset:00004--cnt bytes:08--data is:0000100000000fff
current block:00004097--Offset:00004--cnt bytes:08--data is:0000100100001000
current block:00004098--Offset:00004--cnt bytes:08--data is:0000100200001001
很明显的这里看到了0000100000000fff 当前块号4096 上一个块是4095
这里就确定了确实是这个块出现了问题。那么怎么恢复呢?
当然有从库直接删除导入即可。
如果没有从库没有备份,那么准备好丢数据的可能。
我们可以create table t_bak as select * from t;
这个肯定报错 报错就是读取到了出问题的块,但是t_bak出来了,这个时候我们取自增主键,试着向后推移一部分
如果报错在推 比如一次主键+10 这个还是和你的行大小有关。如果1K的行一个块大约也就10来条数据左右,
我们只要跳过了出错的块,读取应该会正常。但是肯定会丢一些数据,丢的就是坏块的数据。
如果死马当活马医,可以改一下34-37字节为正常的值。再试试。
当然也可以通过mysqlblock工具看一下是否有异常的块
异常:
[root@bak tmp]# ./mysqlblock product_info_snapshotbak.ibd -t
FILE SIZE IS : 1589641216
Total Block Status :
Total block : 97024,Total size is: 1516.000000 MB
Total undo block : 0,Total size is: 0.000000 MB
Total inode block : 1,Total size is: 0.015625 MB
Total insert buffer free blocks: 0,Total size is: 0.000000 MB
Total data(index pages) block : 92434,Total size is: 1444.281250 MB
Total new allocate blocks : 4540,Total size is: 70.937500 MB
Total insert buf bitmap blocks : 6,Total size is: 0.093750 MB
Total system blocks : 0,Total size is: 0.000000 MB
Total transaction system blocks: 0,Total size is: 0.000000 MB
Total file space header blocks : 1,Total size is: 0.015625 MB
Total extrenl disc blocks : 5,Total size is: 0.078125 MB
Total LOB blocks : 24,Total size is: 0.375000 MB
Total Unkown blocks : 13,Total size is: 0.203125 MB
正常:
[root@bak tmp]# ./mysqlblock product_info_snapshot.ibd -t
FILE SIZE IS : 1589641216
Total Block Status :
Total block : 97024,Total size is: 1516.000000 MB
Total undo block : 0,Total size is: 0.000000 MB
Total inode block : 1,Total size is: 0.015625 MB
Total insert buffer free blocks: 0,Total size is: 0.000000 MB
Total data(index pages) block : 92449,Total size is: 1444.515625 MB
Total new allocate blocks : 4538,Total size is: 70.906250 MB
Total insert buf bitmap blocks : 6,Total size is: 0.093750 MB
Total system blocks : 0,Total size is: 0.000000 MB
Total transaction system blocks: 0,Total size is: 0.000000 MB
Total file space header blocks : 1,Total size is: 0.015625 MB
Total extrenl disc blocks : 5,Total size is: 0.078125 MB
Total LOB blocks : 24,Total size is: 0.375000 MB
Total Unkown blocks : 0,Total size is: 0.000000 MB
InnoDB: read in are 4294967295:4294967295, should be 22291:4096!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4096.
InnoDB: You may have to recover from a backup.
2016-06-08 04:38:11 7fa7ddd86700 InnoDB: Page dump in ascii and hex (16384 bytes):
所用到的工具是自己写的mysqlblock和bcview,
我放到了百度云盘
http://pan.baidu.com/s/1num76RJ
供大家下载和使用
今天MYSQL遇到上面的错误:
显然
InnoDB: read in are 4294967295:4294967295, should be 22291:4096!
这里抛出了出错信息,结合前面的提示翻译为,
在space id 22291的4096块上出现了问题,读到的信息为4294967295:4294967295
显现SPACE ID 读到的信息有误 4294967295
那么这第一个4294967295 是怎么来的呢。
首先我们要找到SPACEID 是22291是什么表
select * from INNODB_SYS_TABLESPACES where space = 22291;
然后取出他的ibd文件如果是单独的表空间就非常简单了,目的在于分析原因确定确实是这个表的问题。
然后使用工具查看二进制文件我使用的是自己编写的bcview工具。
******************************************************************
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)
******************************************************************
usage:./bcview file blocksize offset cnt-bytes!
其实这个4294967295来自于块的34-37 的4个字节,
如果我们打开2进制文件使用工具bcview(自己编写的)
./bcview product_info_snapshot.ibd 16 34 4|more
current block:00004096--Offset:00034--cnt bytes:04--data is:ffffffff
我们很清楚看到了这里4个字节全是ffffffff,实际上正常的块是
current block:00000085--Offset:00034--cnt bytes:04--data is:00005713
那么第二个4294967295也就是块号来自哪里呢?
其实这个块号我也占时没有找到他来自哪里,
但是他为什么能读取到正确的4096块呢?
肯能的原意你是每个块的 4-11 8个字节是当前的块号和上一个块的块号
我们来看看
current block:00004090--Offset:00004--cnt bytes:08--data is:00000ffa00000ff9
current block:00004091--Offset:00004--cnt bytes:08--data is:00000ffb00000ffa
current block:00004092--Offset:00004--cnt bytes:08--data is:00000ffc00000ffb
current block:00004093--Offset:00004--cnt bytes:08--data is:00000ffd00000ffc
current block:00004094--Offset:00004--cnt bytes:08--data is:00000ffe00000ffd
current block:00004095--Offset:00004--cnt bytes:08--data is:00000fff00000ffe
current block:00004096--Offset:00004--cnt bytes:08--data is:0000100000000fff
current block:00004097--Offset:00004--cnt bytes:08--data is:0000100100001000
current block:00004098--Offset:00004--cnt bytes:08--data is:0000100200001001
很明显的这里看到了0000100000000fff 当前块号4096 上一个块是4095
这里就确定了确实是这个块出现了问题。那么怎么恢复呢?
当然有从库直接删除导入即可。
如果没有从库没有备份,那么准备好丢数据的可能。
我们可以create table t_bak as select * from t;
这个肯定报错 报错就是读取到了出问题的块,但是t_bak出来了,这个时候我们取自增主键,试着向后推移一部分
如果报错在推 比如一次主键+10 这个还是和你的行大小有关。如果1K的行一个块大约也就10来条数据左右,
我们只要跳过了出错的块,读取应该会正常。但是肯定会丢一些数据,丢的就是坏块的数据。
如果死马当活马医,可以改一下34-37字节为正常的值。再试试。
当然也可以通过mysqlblock工具看一下是否有异常的块
异常:
[root@bak tmp]# ./mysqlblock product_info_snapshotbak.ibd -t
FILE SIZE IS : 1589641216
Total Block Status :
Total block : 97024,Total size is: 1516.000000 MB
Total undo block : 0,Total size is: 0.000000 MB
Total inode block : 1,Total size is: 0.015625 MB
Total insert buffer free blocks: 0,Total size is: 0.000000 MB
Total data(index pages) block : 92434,Total size is: 1444.281250 MB
Total new allocate blocks : 4540,Total size is: 70.937500 MB
Total insert buf bitmap blocks : 6,Total size is: 0.093750 MB
Total system blocks : 0,Total size is: 0.000000 MB
Total transaction system blocks: 0,Total size is: 0.000000 MB
Total file space header blocks : 1,Total size is: 0.015625 MB
Total extrenl disc blocks : 5,Total size is: 0.078125 MB
Total LOB blocks : 24,Total size is: 0.375000 MB
Total Unkown blocks : 13,Total size is: 0.203125 MB
正常:
[root@bak tmp]# ./mysqlblock product_info_snapshot.ibd -t
FILE SIZE IS : 1589641216
Total Block Status :
Total block : 97024,Total size is: 1516.000000 MB
Total undo block : 0,Total size is: 0.000000 MB
Total inode block : 1,Total size is: 0.015625 MB
Total insert buffer free blocks: 0,Total size is: 0.000000 MB
Total data(index pages) block : 92449,Total size is: 1444.515625 MB
Total new allocate blocks : 4538,Total size is: 70.906250 MB
Total insert buf bitmap blocks : 6,Total size is: 0.093750 MB
Total system blocks : 0,Total size is: 0.000000 MB
Total transaction system blocks: 0,Total size is: 0.000000 MB
Total file space header blocks : 1,Total size is: 0.015625 MB
Total extrenl disc blocks : 5,Total size is: 0.078125 MB
Total LOB blocks : 24,Total size is: 0.375000 MB
Total Unkown blocks : 0,Total size is: 0.000000 MB
工具
字节
数据
问题
信息
文件
就是
肯定
明显
清楚
死马当活马医
也就是
二进制
原因
原意
可以通过
备份
大小
实际
实际上
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
服务器机箱管理软件
软件开发服务属于科技服务吗
数据库名称怎样查看
弥勒服务器云存储公司
1394网络技术协议
铜山网络安全宣传周
数据库云技术
计算机等级3网络技术
sql数据库学习心得
互联网科技面临的威胁
神通数据库怎么查看实例名
ipfs服务器系统
毕节地区软件开发培训学校
网络安全工作成就视频
新华互联网科技是干啥的
电脑数据库文件怎么查
重庆平伟科技集团网络安全
潮流软件开发过程创意
网络技术与软件应用学什么
通信网络技术应用研究生
苏康码出不来显示服务器异常
关系型数据库百度云
集成化的软件开发
江西网络技术收费标准
宿豫街头宣传网络安全
英雄联盟西北服务器
巽通网络技术服务有限公司
网络安全八大行业
软件开发与事件总线
闵行区节能软件开发产品介绍