文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

InnoDB: Error: space id and page n:o stored in the page?

2024-04-02 19:55

关注
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







阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯