Базы данных MySQL повреждены

Мы запускаем сервер MySQL Database 5.5 на Windows Server 2008 R2 KVM VPS, где наша система автоматически настраивает новые базы данных для клиентов по мере необходимости. Вчерашний разблокированный диск/раздел закончился (не имел файлов, связанных с БД MySQL), но, похоже, испортил базу данных MySQL.Базы данных MySQL повреждены

При просмотре файлов журнала я вижу, что InnoDB поврежден, но не может сделать головы или хвосты проблемы или как ее решить. Может ли кто-нибудь помочь объяснить, что означают эти ошибки, чтобы я мог его исправить?

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

http://justpaste.it/efuh

источник

2014-02-17 Anonymous

Критическая ошибка

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 + указывает на ту страницу. Каждая страница имеет свой собственный page_id в заголовке.

Чтобы исправить это, запустите MySQL с innodb_force_recovery = 4 и удалите все таблицы с помощью mysqldump, чтобы повторно создать табличное пространство InnoDB с нуля. Вероятно, mysqldump не будет работать с некоторыми таблицами (поскольку нет согласованного списка указателей на страницы). Это тот случай, дамп таблицы в диапазонах ПК или использовать сценарий, как this

UPDATE: восстановление данных инструментарий переехал в GitHub

источник

2014-02-17 20:14:48 akuzminsky

я смог запустить его с innodb_force_recovery = 4 и имеют туздЫшпр работает в настоящее время, экспорт все базы данных в "database.sql". Как я не понимаю последних инструкций, как только это будет завершено, следует ли мне настроить новую базу данных MYSQL (чистая установка VPS) и импортировать этот SQL? –

mysqldump по-прежнему работает, но другое консольное окно, открытое для mysqld, только что начало рассылать ошибки InnoDB «Возможно, скопировали табличное пространство, но не файлы журнала». –

InnoDB хранит данные на листах листа индекса дерева B +. Страницы листа соединены в двух направлениях. Ваш MySQL разбился, потому что этот список нарушен для некоторого индекса. mysqldump должен сканировать таблицу, т. е. следовать списку указателей. Вот почему я подозреваю, что mysqldump может привести к сбою mysqld на некоторой таблице. Если это произойдет, сбросьте таблицу в диапазонах первичного ключа. Предположим, что таблица имеет id как первичный ключ. id находится между 1 и 1000. Если «select * from table» сбрасывает mysqld, тогда «выберите * из таблицы, где id <= 1 и id <500» могут не совпадать. Выбирая диапазоны идентификаторов, вы можете сбросить как можно больше записей. – akuzminsky

Базы данных MySQL повреждены

ответ

Смежные вопросы