Предыстория. Все админы делятся на три группы: кто ещё не делает бэкапы, кто уже делает и тех, кто проверяет бэкапы.

Так вот. CentOs 5.9, Mysql 5.0.95 небольшой сайт на движке битрикс и форум phpBB3.

Попросили сделать копию базы mysql - и оказалось, что резервные копии базы не создаются, на какой-то из таблиц вылетает ошибка.

Посмотрел - в /var/log/mysqld.log постоянно сыпятся ошибки

140408 17:41:37 InnoDB: Error: page 6123 log sequence number 159546844
InnoDB: is in the future! Current system log sequence number 275928.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.

Начал погружаться в тему, однако в поиске ищутся только случаи, когда майскуль уже не запускается, файлы все побились и каким-то шаманством пытаются вытащить хоть что-то из frm и ibdata.
Здесь же - нормально работающий веб-сервер, есть подозрение, что побитые таблички - это какие-то не особо значимые данные, однако хочется сделать всё по уму, починив данные и сделав нормальный бэкап.

В какую сторону смотреть? С сервером никаких операций по перемещению-удалению файлов, дисковых массивов и т.п. не делалось, служба mysql запускается. Удалять лог-файлы innodb - сдаётся не самое правильное действие в данном случае.

Может, кто поделиться информацией, в какую сторону искать?

Читал http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html - не совсем понял логику и суть предложений.

Вот сейчас допустим у меня не проходит даже простой SELECT * FROM `b_sonet_event_user_view` LIMIT 0, 25 - можно ли распрощаться с таблицей или нужно переводить в innodb_force_recovery = 1 и пробовать выжать хоть какие-то данные - и так идти по всем сбойным innodb таблицам?




С уважением, Андрей.

__________
Надо делать так, как надо. А как не надо - делать не надо.

miksoft,

innodb_file_per_table дефолтная (всё в одном файле).

Модуль соцсети не используется (я так понимаю рекомендация - забить на эту таблицу?)

miksoft,

А что делать с другими таблицами? В общем-то таблиц много, не все можно удалить и забыть. Что с ними делать?

miksoft,

Проблема не со всеми таблицами, но у меня как-то не складывается какой-то системный подход.

Какие я вижу варианты.

1. Создать отдельную базу, в которую перелить все целые таблички, потом вручную собирать таблицы, которые не уходят в резервную копию. Брать их либо из свежеустановленных копий, либо - из самых последних успешных резервных копий, какие остались.
Вариант простой понятный, всегда можно по нему пойти.

2. Попробовать разобраться, можно ли запустить какую-то восстановительную процедуру на таблицах innodb (Ну, что-то аналогичное repair_table для myisam, когда восстанавливаются порушенные индексы). С innodb не работал особо, поэтому не представляю, что можно в данной ситуации делать.

Советы, которые вы даёте - они идут по первому варианту практически, я же хотел бы понять, что можно сделать на уровне sql. Я так понял, что бест практис - это включать innodb_file_per_table на будущее, чтобы была возможность как-то чинить таблицы средствами mysql innodb, а сейчас особо ничего не выжмешь - и пока только идти по первому варианту?

Ну и остаётся самый простой способ - ничегонеделание. Из серии - работает же сайт хоть как-то, значит, затронуты не самые важные таблицы. А вот когда даже mysql не запустится - тогда брать файлы закидывать на другой сервер и пытаться хоть что-то восстановить. Самый плохой способ, на мой взгляд.

miksoft,

Логично.

Такой вопрос - как разбираться с повреждёнными таблицами?
Я так понял - сначала (составить список повреждённых таблиц) нужно попробовать прочитать из них данные, для чего последовательно повышать innodb_force_recovery = 1, 2, 3 ... 6 пока не прочитается, а если не прочитается - думать, насколько силён риск несогласованных данных в случае восстановления данных из резервной копии.

Так?