Ошибка сервера MySQL, InnoDB за пределами границ табличного пространства

Question

У меня есть приложение C#, выполняющее некоторые операции с базами данных на сервере MySQL 5.7. После того, как система полностью оправилась, и мне пришлось ее сбрасывать. Когда дело доходит до конкретной операции чтения/записи таблицы, сервер базы данных выходит из строя. Окна журнала показывает

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. 

Я пытался использовать mysqlcheck --repair, но терпит неудачу, потому note : The storage engine for the table doesn't support repair.

Я прочитал несколько советов, которые говорят, я должен начать MySQL в режиме восстановления, так что я добавил

[mysqld] 
innodb_force_recovery=4 

в файл конфигурации my.ini, после чего я должен быть в состоянии использовать mysqldump экспортировать пораженный таблицу базы данных , Но, к сожалению, нет.

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

---

Edit:

Я снова проверил журнал ошибок и нашел много записей говоря

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

Я бегу сервер на 32-битной ОС Windows с NTFS отформатированный раздел. Размер файла myTable.ibd составляет около 4,5 ГБ, при проверке C.10.3 Limits on Table Size указано ограничение размера файла «2 ТБ (возможно, больше)» для Win32 w/NTFS. При проверке причин моей ошибки единственной возможной причиной, которую я обнаружил, было полное табличное пространство InnoDB. Решением может быть «Изменение количества или размера файлов журнала повторного использования InnoDB», хотя согласованность немного расплывчата для меня. Тем не менее я увеличил размер файлов журнала повтора с 48M до 100M. Но ничего не изменилось.

Если я выполняю SQL select * from myTable order by Id desc, сервер аварийно завершает работу. Запись журнала ошибок точно такая же, как и выше.

Я также проверил главу 15.7.1 Resizing the InnoDB System Tablespace и выяснил, что innodb_data_file_path не указано явно.

Любые идеи, что я могу сделать сейчас? Большое спасибо!

Answer 1

InnoDB не может восстановить повреждение в табличных пространствах. Это никогда не было реализовано, и mysqlcheck никоим образом не поможет.

Коррупция находится в пространстве id 29, которое является таблицей myInstance.myTable. Чтобы восстановить его, вам нужно сбросить все записи из этой таблицы с помощью innodb_force_recovery. Попробуйте все значения от 4 до 6, пока MySQL не сработает. Затем отбросьте таблицу и перезагрузите дамп.

Если MySQL сбой даже с innodb_force_recovery=6, то восстановите таблицу из резервной копии.

Если у вас нет резервной копии - используйте скрипт http://bazaar.launchpad.net/~percona-dev/percona-data-recovery-tool-for-innodb/trunk/view/head:/fetch_data.sh. Он будет извлекать столько записей, сколько может.