MySQL InnoDB 断电后损坏,可以恢复吗?

5 mysql windows-server-2003 innodb

我最近开始尝试在停电后启动并运行 Redmine,这似乎损坏了我们在 MySQL 中的 InnoDB 数据库。Redmine 有一套广泛的文档,即使 redmine 无法运行,我也想获得这些文档。该服务在启动时失败。我尝试根据错误日志中 url 的文档插入 innodb_force_recovery = 4 。(也尝试了 1 到 6,因为我在损坏后备份了所有目录)我已经通过“mysqld-nt --print-defaults”验证它是从参数中的恢复选项开始的。

机器运行Windows Server 2003 SP2,至强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
Run Code Online (Sandbox Code Playgroud)

Gar*_*ren 1

我最近遇到了这个问题,并且本身无法“恢复”,但能够在设置 innodb_force_recovery 时使用 mysqldump,然后用它重新创建数据库。如果由于错误而无法转储数据,请参阅:

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

寻找“坏”数据并转储“好”数据的策略。