|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день.
Неприятная ситуация. Хостер жестко перезапустил виртуальную машину и в итоге mysql отказывается запускаться.
Вот что пишет с логах:
160622 19:55:48 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and
160622 19:55:48 [Note] Plugin 'FEDERATED' is disabled.
160622 19:55:48 InnoDB: The InnoDB memory heap is disabled
160622 19:55:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160622 19:55:48 InnoDB: Compressed tables use zlib 1.2.8
160622 19:55:48 InnoDB: Using Linux native AIO
160622 19:55:48 InnoDB: Initializing buffer pool, size = 128.0M
160622 19:55:48 InnoDB: Completed initialization of buffer pool
160622 19:55:48 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 21828328780
160622 19:55:48 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 21828335125
InnoDB: Error: trying to access page number 4294783871 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
160622 19:55:48 InnoDB: Assertion failure in thread 140055309854592 in file fil0fil.c line 4578
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.5/en/ … overy.html
InnoDB: about forcing recovery.
13:55:48 UTC - mysqld got signal 6 ;
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=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x557575df2390]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x557575cdb785]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f612a15e330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f61297b5c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f61297b9028]
/usr/sbin/mysqld(+0x603b3c)[0x557575f02b3c]
/usr/sbin/mysqld(+0x5dec79)[0x557575eddc79]
/usr/sbin/mysqld(+0x5df5fb)[0x557575ede5fb]
/usr/sbin/mysqld(+0x5d031f)[0x557575ecf31f]
/usr/sbin/mysqld(+0x5a38f1)[0x557575ea28f1]
/usr/sbin/mysqld(+0x5a44d3)[0x557575ea34d3]
/usr/sbin/mysqld(+0x5a5f27)[0x557575ea4f27]
/usr/sbin/mysqld(+0x59335f)[0x557575e9235f]
/usr/sbin/mysqld(+0x562718)[0x557575e61718]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x557575cdd7b1]
/usr/sbin/mysqld(+0x302d11)[0x557575c01d11]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x92a)[0x557575c05d0a]
/usr/sbin/mysqld(+0x28b2eb)[0x557575b8a2eb]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x557575b8ec5b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f61297a0f45]
/usr/sbin/mysqld(+0x2871a8)[0x557575b861a8]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Установка innodb_force_recovery в любое значение от 1 до 6 не помогает Mysql запуститься.
Методики, описанные тут http://sqlinfo.ru/forum/viewtopic.php?id=2438 не получается применить по причине того, что не стоит параметра innodb_file_per_table и все данные в одном толстом файле ibdata1, так же не получается воспользоваться innodb-tools по причине того, что сервер не запускается (а насколько я понял напрямую с файлами данных но не работает, только через сервер)
Помогите пожалуйста выцарапать данные из баз.
П.С: Про бэкапы лучше не упоминать.
Неактивен
Печально. Давайте попробуем подиагностировать. Хочется:
1. лог ошибок с innodb_force_recovery=6 (как минимум, он пропустит применение лога транзакций, увидим, на чем споткнется)
2. размер ibdata1 на диске и в my.cnf (проверяем гипотезы «побился диск и размер файла неправильный» и «хостер переписал my.cnf какой-нибудь админкой»).
Ну и про innodb recovery tools — все не так плохо, с выключенным file_per_table Вы работаете в том же режиме, что и со включенным, только данные живут в одном пространстве данных. Поэтому придется потратить чуть больше времени на изоляции таблиц.
https://www.percona.com/docs/wiki/innod … very:start
Неактивен
Лог с innodb_force_recovery=6:
160623 8:29:22 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
160623 8:29:22 [Note] Plugin 'FEDERATED' is disabled.
160623 8:29:22 InnoDB: The InnoDB memory heap is disabled
160623 8:29:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160623 8:29:22 InnoDB: Compressed tables use zlib 1.2.8
160623 8:29:22 InnoDB: Using Linux native AIO
160623 8:29:22 InnoDB: Initializing buffer pool, size = 128.0M
160623 8:29:23 InnoDB: Completed initialization of buffer pool
160623 8:29:23 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: Error: trying to access page number 4294783871 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
160623 8:29:23 InnoDB: Assertion failure in thread 139699191895936 in file fil0fil.c line 4578
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.5/en/ … overy.html
InnoDB: about forcing recovery.
02:29:23 UTC - mysqld got signal 6 ;
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=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x56056febb390]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x56056fda4785]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0e3fcd2330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f0e3f329c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f0e3f32d028]
/usr/sbin/mysqld(+0x603b3c)[0x56056ffcbb3c]
/usr/sbin/mysqld(+0x5dec79)[0x56056ffa6c79]
/usr/sbin/mysqld(+0x5df5fb)[0x56056ffa75fb]
/usr/sbin/mysqld(+0x5d031f)[0x56056ff9831f]
/usr/sbin/mysqld(+0x5a38f1)[0x56056ff6b8f1]
/usr/sbin/mysqld(+0x5a44d3)[0x56056ff6c4d3]
/usr/sbin/mysqld(+0x5a5f27)[0x56056ff6df27]
/usr/sbin/mysqld(+0x59335f)[0x56056ff5b35f]
/usr/sbin/mysqld(+0x562718)[0x56056ff2a718]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x56056fda67b1]
/usr/sbin/mysqld(+0x302d11)[0x56056fccad11]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x92a)[0x56056fcced0a]
/usr/sbin/mysqld(+0x28b2eb)[0x56056fc532eb]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x56056fc57c5b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f0e3f314f45]
/usr/sbin/mysqld(+0x2871a8)[0x56056fc4f1a8]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Неактивен
Размер ibdata1 на диске 3005218816 байт.
В my.cnf размера явно не указано, скорее всего стоит значение по умолчанию.
Неактивен
Указанная вами статься описывает каким образом вычислить в каких страницах находится нужная таблица, но только на запущенной mysql.
Каким образом это определить на неработающей базе не понятно.
Неактивен
Да, размеры ничего не показали. Очень странно развалился InnoDB 
Okay, давайте тогда пробовать утилиты. Для начала, нужно определить внутренние номера индексов.
Я бы попробовал делать в такой последовательности:
1. Попробовать восстановить системные таблицы. Если это удастся, то у Вас будет честный внутренний словарь соответствий имен таблиц и номеров индексов. В ссылке внизу приведены структуры, с которыми нужно собрать constraint parser, и попробовать найти эти данные.
https://www.percona.com/docs/wiki/innod … dictionary
2. Если системные таблицы нашлись, то дальше восстанавливаем их стандартным способом, выбираем номера индексов таблиц данных, и дальше начинаем потабличное восстановление самих данных.
3. Если таблицы не нашлись, то тогда придется вручную искать каждую табличку. Если знаете, что содержится в таблицах, то grep должен помочь. Если нет, то берете структуру из frm, собираете constraint-parser (как в п.1.) и ищете по ограничениям.
https://www.percona.com/docs/wiki/innod … _frm_files
Тяжелая работа, держитесь
Неактивен
paulus написал:
Печально. Давайте попробуем подиагностировать. Хочется:
1. лог ошибок с innodb_force_recovery=6 (как минимум, он пропустит применение лога транзакций, увидим, на чем споткнется)
2. размер ibdata1 на диске и в my.cnf (проверяем гипотезы «побился диск и размер файла неправильный» и «хостер переписал my.cnf какой-нибудь админкой»).
Ну и про innodb recovery tools — все не так плохо, с выключенным file_per_table Вы работаете в том же режиме, что и со включенным, только данные живут в одном пространстве данных. Поэтому придется потратить чуть больше времени на изоляции таблиц.
https://www.percona.com/docs/wiki/innod … very:start
Огромное спасибо.
Детальное и внимательное изучение методики, указанной в ссылке, помогло восстановить данные. Единственно, пришлось помучиться с вычислением в каких страницах находятся необходимые таблицы. Но правильно приложенный паяльник к нашему программисту и grep помогло в этом.
Пошел настраивать бэкапы )
Отредактированно lmv (23.06.2016 16:06:14)
Неактивен
