130711 23:03:40 InnoDB: Error: page 23 log sequence number 3336825872455
InnoDB: is in the future! Current system log sequence number 235089.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.

我以前从未见过或曾经遇到此错误.客户端没有备份,因此需要完成恢复.

我以前做过MySAIM恢复,但从来没有InnoDB.有没有关于如何正确做到的提示？

从我读过的内容来看,我需要增加一个单独的计数器(“日志序列号”),该计数器存储在ib_logfile0和ib_logfile1的标题中某处,或类似的正确吗？

解决方法:

唯一正确的解决方案是从备份重新安装和恢复.你说你没有备份,但重点是强制InnoDB恢复背后的想法是你可以使服务器足够稳定,你可以进行备份.然后使用它来恢复新的设置.

显然,在做任何事情之前复制所有文件.

除非有一个我没有得到的备忘录,否则你不想尝试增加日志序列号来安抚InnoDB,因为即使你设法做到这一点,你仍然有一个服务器在未知的地方有数据损坏 – 修复LSN,你真正完成的就是让InnoDB不知道腐败.强迫LSN几乎是一个傻瓜的差事.

你有没有试过……

http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html

不同的级别,1到6,累积地禁用InnoDB的部分,并认为如果禁用足够的功能,您可能能够从表中获得成功的mysqldump或至少SELECT … INTO OUTFILE.

我们的想法是使用允许您成功转储数据的最小数字,但如果在启动时发生此错误,我认为可能就是这样,您可能只想继续以6开头.如果服务器启动,然后尝试从表中选择.它可能会再次崩溃,如果确实如此,那么暂时写下该表并移动到下一个表.

一旦您从未损坏的表中检索数据,您就可以回到那些不起作用的数据,并尝试使用SELECT … LIMIT检索小夹头中的数据…抵消.

看看我的answer to this similar question以获得一些额外的想法.

您可能还希望将Percona的InnoDB data recovery tool视为一种潜在的资源,尽管我从来没有(手指交叉)没有备份或正在运行的复制奴隶,所以我从来没有需要它.