Страница 1 из 1
Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 10:28:26
SinClaus
Ситуация: посыпался диск на BSD сервере (что характерно, SMART даже не вякнул...), и по известному закону плохо читаемый блок (возможно не один) попал в базу ibdata1 мускуля. Вытащить файл удалось только при помощи dd с ключем noerror. Файлы ib_log... не повреждённые. Да, структура базы - т.е. каталог с *.frm абсолютно не повреждён.
Ирония ситуации в том, что по привычке к InnoDB базам ежедневный бэкап делался только по базам данных, дабы не зацеплять безобразно распухающие логи. Ну и лень-матушка, конечно. В общем, из бэкапа innodb база не восстановима. Можно ли ее попытаться малость подремонтировать?
Данные там не столько критические для предприятия, сколько важные политически - это содержимое вики которая использовалась для координации группы разработчиков, традиционно не любящих (почему-то

) админов.
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 11:05:57
Gamerman
А как мускуль ругается на все это?
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 11:21:12
SinClaus
Традиционно - орёт что индексы в будущем, что константы гигантских размеров, традиционное начало:
Код: Выделить всё
110323 14:44:44 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
110323 14:44:44 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
...................
посылает в
http://dev.mysql.com/doc/refman/5.0/en/ ... overy.html
заканчивает
Код: Выделить всё
....................
110323 14:44:44InnoDB: Assertion failure in thread 679481600 in file 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.
110323 14:44:44 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=0
read_buffer_size=1048576
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 204800 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
110323 14:44:44 mysqld ended
Оно в общем понятно, dd там понавставлял нулевых блоков, их можно интерпретировать и как плюс бесконечность...
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 13:15:42
LMik
И бэкапы естественно вы еще не начали делать?
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 13:28:00
SinClaus
Это к вопросу отношения не имеет. Даже бэкапы бэкапов есть.
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 16:15:10
Alex Keda
восстановить из бэкапа
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 18:13:04
SinClaus
Алекс, я понимаю, долгое общение с хомячками действует... Повторяю: к сожалению ibdata1, корректная, с этого сервера, в бэкапах отсутствует.
Re: Ремонт innodb (ibdata1) базы
Добавлено: 2011-03-26 20:36:30
Alex Keda
ы...
понял....
========
делайте копию, пробуйте фиксить...