В один прекрасный момент mysql начал циклически перезапускаться. В логах вот такое
130531 21:17:46 - 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=8384512
read_buffer_size=131072
max_used_connections=11
max_connections=100
threads_connected=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225787 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
130531 21:17:46 mysqld restarted
130531 21:17:46 InnoDB: Started; log sequence number 144 3135987376
Причина ясна – повреждена база innodb.
Скажу сразу: решений данной проблемы очень много – как сложные, так и не очень. Решил пойти по пути наименьшего сопротивления.
Решение нашлось путём экспериментов:
сначала добавляем строку
innodb_force_recovery=4
после пару перезапусков или после нескончаемого потока сообщений
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
меняем
innodb_force_recovery=4
на
innodb_force_recovery=2
Если ситуация не исправилась (либо перезапуск, либо циклически сообщения InnoDB: innodb_force_recovery is on: we do not allow… ) меняем 2 на 3, и опять наблюдаем. После меняем опять на 4 и в конце – вообще убираем опцию
innodb_force_recovery=...
После этого перезапускаем и база работает нормально.
Если не нормально, тогда нужно найти сбойную таблицу и либо восстановить либо сделать ей truncate. Сбойную таблицу можно найти путём mysqldump’a (ведь лучше на всякий случай сделать дамп всех баз). Если часть данных из таблицы всё же нужна – тогда можно сделать дамп этой таблицы до сбойной записи и либо удалить эту запись, либо сделать truncate + последующий залив дампа таблицы.
Так же можно попробовать такой хак: указать в my.cnf точный размер (с точностью до байта) файлов базы и логов и режим восстановления 6:
innodb_data_file_path = ibdata1:11788091392:autoextend
innodb_log_file_size = 5242880
innodb_force_recovery = 6
А можно ещё попробовать пачку других советов, которые помогли http://local.com.ua/forum/blog/3/entry-10-%D0%B2%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-innodb/
Вообщем, экспериментируйте.
А вот ещё парочка советов, которые возможно помогут:
http://yapatha.livejournal.com/255447.html
http://www.chriscalender.com/recovering-an-innodb-table-from-only-an-ibd-file/
https://www.percona.com/blog/2011/05/13/connecting-orphaned-ibd-files/
