windows-server-2003 – 断电后MySQL InnoDB腐败,有可能恢复吗?

前端之家收集整理的这篇文章主要介绍了windows-server-2003 – 断电后MySQL InnoDB腐败,有可能恢复吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我最近开始尝试在断电后让Redmine启动并运行,这似乎已经破坏了 MySQL中的InnoDB数据库. Redmine有一套广泛的文档,即使redmine无法运行,我也希望得到这些文档.启动时服务失败.我已经尝试根据错误日志中url的文档插入innodb_force_recovery = 4. (也尝试了1到6,因为我在腐败后备份了所有目录)我通过“MysqLd-nt –print-defaults”验证它是从params中的恢复选项开始的.

该机器运行Windows Server 2003 SP2,Xeon E5335具有2GB RAM,MysqL未镜像到另一台机器,机器也不是镜像.我没有任何备份,因为前一个人没有设置它们.

这是错误日志:

InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
100308 14:50:01  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
100308 14:50:02  InnoDB: Error: page 7 log sequence number 0 935521175
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100308 14:50:02  InnoDB: Error: page 2 log sequence number 0 935517607
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100308 14:50:02  InnoDB: Error: page 11 log sequence number 0 935517607
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100308 14:50:02  InnoDB: Error: page 5 log sequence number 0 972973045
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100308 14:50:02  InnoDB: Error: page 6 log sequence number 0 972984051
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
100308 14:50:02  InnoDB: Error: page 1577 log sequence number 0 972737368
InnoDB: is in the future! Current system log sequence number 0 933419020.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: Error: trying to access page number 4294965119 in space 0,InnoDB: space name .\ibdata1,InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0,len 16384,i/o type 10.
InnoDB: If you get this error at MysqLd startup,please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MysqL server.
100308 14:50:02InnoDB: Assertion failure in thread 960 in file .\fil\fil0fil.c line 3959
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.MysqL.com.
InnoDB: If you get repeated assertion failures or crashes,even
InnoDB: immediately after the MysqLd startup,there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.MysqL.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
100308 14:50:02 [ERROR] MysqLd-nt: Got signal 11. Aborting!

100308 14:50:02 [ERROR] Aborting

100308 14:50:02 [Note] MysqLd-nt: Shutdown complete
我最近遇到了这个问题并且无法“恢复”本身,但能够在设置innodb_force_recovery时使用MysqLdump,然后用它重新创建数据库.如果由于错误而无法转储数据,请参阅:

http://www.mysqlperformanceblog.com/2008/07/04/recovering-innodb-table-corruption/

对于找到“坏”数据的策略,并抛弃“好”的东西.

原文链接:https://www.f2er.com/windows/368435.html

猜你在找的Windows相关文章