|
Задавайте вопросы, мы ответим
Вы не зашли.
Ситуация: посыпался диск на BSD сервере (что характерно, SMART даже не вякнул...), и по известному закону плохо читаемый блок (возможно не один) попал в базу ibdata1 мускуля. Вытащить файл удалось только при помощи dd с ключем noerror. Файлы ib_log... не повреждённые. Да, структура базы - т.е. каталог с *.frm абсолютно не повреждён.
Ирония ситуации в том, что по привычке к InnoDB базам ежедневный бэкап делался только по базам данных, дабы не зацеплять безобразно распухающие логи. Ну и лень-матушка, конечно. В общем, из бэкапа innodb база не восстановима. Можно ли ее попытаться малость подремонтировать?
Данные там не столько критические для предприятия, сколько важные политически - это содержимое вики которая использовалась для координации группы разработчиков, традиционно не любящих (почему-то ) админов.
Для информации куски из ругани MySQL при запуске с повреждённым комплектом ibdata и ib_log___:
начало:
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
...................
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Отредактированно Chawoosh (27.03.2011 09:11:17)
Неактивен
Вообще говоря, там написаны осмысленные слова — надо открыть
http://dev.mysql.com/doc/refman/5.0/en/ … overy.html и поступать
так, как там написано — запускать сервер с увеличивающимися значениями
innodb_force_recovery до тех пор, пока сервер не запустится. После этого сде-
лать резервную копию того, что восстановимо, пересоздать пространство дан-
ных и залить резервную копию назад.
Что касается smart — Гугл проводил исследование относительно недавно и вы-
яснил, что вероятность отказа оборудования после срабатывания смарта равна
50%, то есть смарт хорош для продажи, но абсолютно не показателен в жизни.
Неактивен
Доброго. Загнулся HDD с личного сервера. Файлы все восстановили. Но появилась проблема с InnoDB. Если он влючен, то MySQL падает через 15-20 секунд. При это форум работает(конечно пока не упадёт MySQL). Если его выключить или убрать имеющиеся файлы:
ib_logfile0, ib_logfile1, ibdata1
то всё пашет. Но собственно тогда у мну нет форума... (((
Лог в аттаче.
force_innodb_recovery 4, force_innodb_recovery 6
не помогают.
Система Win7. MySQL 5.1.53-community.
Отредактированно taravasya (11.08.2012 19:52:29)
Неактивен
Попробуйте убрать ib_logfile0 и ib_logfile1, а ibdata1 оставить
Неактивен
Спасибо. Буквально 5 минут назад закончил эту эпопею(((((
Я пробовал убрать логфайлы, не помогало.
В итоге сработало так(может быть кому-то поможет):
Локально в SQL Manager for MySQL, поочерёдно преобразовал все таблицы из InnoDB в MyISAM. Так конечно-же нашлась таблица на которой MySQL "вешался". Когда она осталась одна с InnoDB Engine, я отключил плагин InnoDB, и после этого импортировал одну эту таблицу из бэкапа(к счастью актуальность данных в ней, оказалась не критична) с MyISAM Engine.
Неактивен
