问题描述
我们在Windows Server 2008 R2 KVM VPS上运行MySQL数据库5.5服务器，其中我们的系统根据需要自动为客户设置新的数据库。昨天一个完全独立的驱动器/分区（没有与MySQL DB相关联的文件）耗尽空间，但似乎已损坏MySQL数据库。
We run a MySQL Database 5.5 server on a Windows Server 2008 R2 KVM VPS, where our system automatically sets up new databases for customers as needed. A completely separate drive/partition ran out of space yesterday (had no files associated with the MySQL DB) but seemingly has corrupted the MySQL Database.
在查看日志文件时，我可以看到InnoDB已损坏，但不能使头部或尾部的问题是或如何解决它。任何人都可以帮助解释这些错误是什么意思，所以我可以修复它？
In reviewing the log files, I can see that the InnoDB is corrupted but cannot make heads or tails of what the problem is or how to resolve it. Can anyone help explain what is these errors mean so I may be able to repair it?
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
00000001401198BD mysqld.exe!my_osmaperr()
000000014011E79A mysqld.exe!my_osmaperr()
0000000140159697 mysqld.exe!my_osmaperr()
0000000140159F53 mysqld.exe!my_osmaperr()
00000001400F05AD mysqld.exe!my_osmaperr()
00000001400F07C8 mysqld.exe!my_osmaperr()
00000001400F105C mysqld.exe!my_osmaperr()
00000001400F4FB3 mysqld.exe!my_osmaperr()
00000001400DA97C mysqld.exe!my_osmaperr()
00000001400C338C mysqld.exe!my_osmaperr()
0000000076C0652D kernel32.dll!BaseThreadInitThunk()
0000000076D3C541 ntdll.dll!RtlUserThreadStart()
InnoDB: Thread 408 stopped in file hash0hash.c line 146
推荐答案
关键错误是
140217 18:51:48 InnoDB: Assertion failure in thread 2052 in file btr0cur.c line 270
InnoDB: Failing assertion: btr_page_get_next(get_block->frame, mtr) == page_get_page_no(page)
这意味着指向叶B +树索引页中下一页的指针指向错误的页。
That means that a pointer to the next page in a leaf B+tree index page points to the wrong page. Every page has its own page_id in the header.
要修复它，使用innodb_force_recovery = 4启动MySQL并使用mysqldump转储所有表，以便从头重新创建InnoDB表空间。很可能mysqldump会失败一些表（因为没有一致的页面指针列表）。在这种情况下，转储PK范围内的表，或使用类似于的脚本
To fix it start MySQL with innodb_force_recovery=4 and dump all tables with mysqldump in order to re-create InnoDB tablespace from scratch. It's quite probably mysqldump will fail of some tables (because there is no consistent list of page pointers). It that case dump the table in ranges of PK or use a script like this
UPDATE ：数据恢复工具包已移至
UPDATE: Data recovery toolkit moved to GitHub
这篇关于MySQL数据库损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！