MySQL 服务器崩溃，InnoDB 超出表空间边界

Question

I have a C# application performing some database operations on a MySQL 5.7 server. Once the complete system hunp up and I had to hard-reset it. When it comes to a specific table read/write operation now the database server crashes. The windows log shows

InnoDB: Trying to access page number 286720 in space 29, 
space name myInstance/myTable, which is outside the tablespace bounds.
Byte offset 0, len 16384, i/o type read. 

I tried to use mysqlcheck --repair but it fails because note : The storage engine for the table doesn't support repair .

I've read some advices that say I should start MySQL in a recovery mode, so I added

[mysqld]
innodb_force_recovery=4

to the my.ini config file whereupon I should be able to use mysqldump to export the affected database table. But unfortunatelly I am not.

mysqldump: Error 2013: Lost connection to MySQL server 
during query when dumping table `myTable` at row: 1246

---

Edit:

I checked the error log again and found lots of entries saying

[ERROR] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe: 
The table 'myTable' is full

I'm running the server on a Windows 32bit OS with an NTFS formatted partition. The myTable.ibd file size is around 4.5 GB, checking C.10.3 Limits on Table Size states a file size limit of "2TB (possibly larger)" for Win32 w/ NTFS. While checking the reasons for my error the only possible cause I found was a full InnoDB tablespace. The solution might be "Changing the Number or Size of InnoDB Redo Log Files" although the coherence is a bit vague to me. Nevertheless I increased the size of the Redo Log Files from 48M to 100M. But nothing changed.

If I perform a SQL select * from myTable order by Id desc the server crashes instantly. Error log entry is exactly the same as above.

I checked the chapter 15.7.1 Resizing the InnoDB System Tablespace as well and found out that innodb_data_file_path is not explicitly specified.

Any ideas what I can do now? Thanks a lot!

Answer 1

InnoDB cannot repair corruption in tablespaces. This was never implemented and mysqlcheck won't help in any way.

The corruption is in space id 29 which is table myInstance.myTable. To repair it you need to dump all records from this table with innodb_force_recovery. Try all values from 4 to 6 until MySQL doesn't crash. Then drop the table and reload the dump.

If MySQL crashes even with innodb_force_recovery=6 then restore the table from backup.

If you don't have backup - use script http://bazaar.launchpad.net/~percona-dev/percona-data-recovery-tool-for-innodb/trunk/view/head:/fetch_data.sh . It will fetch as many records as it can.

Answer 2

One possible cause could be that the ib_logfile* files are corrupted.

To fix this, remove these files using rm ib_logfile* .

Where are these files? These files are in mysql datadir . The location of datadir depends on the OS. Check my.cnf , in osx that should be in /usr/local/etc .