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

时间: 2024-09-20 16:01:52

InnoDB: Error: space id and page n:o stored in the page?的相关文章

[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

MYSQL Space id in fsp header,but in the page header错误

今天启动MYSQL的时候发现如下问题: 2015-12-14 20:51:59 2098 [ERROR] InnoDB: Space id in fsp header 131225,but in the page header 65 2015-12-14 20:51:59 2098 [ERROR] InnoDB: inconsistent data in space header in tablespace ./test/oneblock.ibd (table test/oneblock) in

MySQL8.0新特性:增加系统文件追踪space ID和物理文件的映射

Note1: 本文所有代码相关的内容都是基于MySQL8.0.3,而目前版本还处于RC和快速开发的状态,不排除后面的版本逻辑,函数名等发生变化. Note2: 主要代码在这个commit 中,感兴趣的也可以自行阅读代码 Note3: 本文仅是本人的阅码笔记,记录的比较凌乱... 前面我们提到了MySQL5.7的几个崩溃恢复产生的性能退化 为了解决崩溃恢复的效率问题, MySQL8.0对crash recovery的逻辑进行了进一步的优化. 在之前的版本中,InnoDB通过向redo log中写入

error-mysql InnoDB: Error: "mysql"."innodb_table_stats

问题描述 mysql InnoDB: Error: "mysql"."innodb_table_stats 附上错误日志: 2015-06-23 22:39:06 1252 [Note] Giving 0 client threads a chance to die gracefully 2015-06-23 22:39:06 1252 [Note] Shutting down slave threads 2015-06-23 22:39:06 1252 [Note] For

InnoDB: Error: io_setup() failed with EAGAIN

    最近安装好了MySQL之后,在启动MySQL服务时无法正常启动MySQL.提示没有更新/var/lib/mfailedZDB.pid并退出.该MySQL与Oracle位于同一主机.有些内核参数进行过调整应该也是使用与MySQL.下面是该问题的具体描述.   1.故障现象SZDB:/usr/src/mysql_src # /etc/init.d/mysql startStarting MySQL...The server quit without updating PID file (/v

Mysql启动中 InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes 的问题_Mysql

如果你的配置文件使用了类似my-innodb-heavy-4G.cnf作为配置文件的话. Mysql可以正常启动,但innodb的表无法使用 在错误日志里你会看到如下输出: InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes 现在需要做的事情就是把原来的 innodb 的ib_logfile×备份到一个目录下,然后删除掉原来的文件,重启 mysql. 你会看到ib_logfile*大小变成了你配置文

mysql 有关“InnoDB Error ib_logfile0 of different size”错误_Mysql

1,查看Mysqld(/var/log/mysqld.log)日志,发现以下错误:InnoDB: Error: log file /usr/local/mysql/data/ib_logfile0 is of different size 05242880 bytesInnoDB: than specified in the .cnf file 0 104857600 bytes!030826 1:42:15 Can't init databases030826 1:42:15 Aborting

WPF程序,如何在当签窗口遍历子窗口的所有控件呢?比如说我有一个导航界面,选择不同按钮就会有不同的page,我怎么去遍历page里的控件呢?

问题描述 如题,新手求助啊,跪求牛人解答 解决方案

InnoDB可传输表空间

Copying File-Per-Table Tablespaces to Another Server Transportable Tablespace Examples Transportable Tablespace Internals 背景 大家先来回顾一下,如果要将innoDB中的一个表 Moving or Copying 到另外一台(machine|instance)上,如何做? MySQL Enterprise Backup (no need consider) Copying D