Форум пользователей MySQL

yual · 03.11.2009 08:41:54

Здравствуйте, помогите решить проблему. После сбоя питания на сервере, перестал работать MySQL. При обращении к базе лезут ошибки типа "Incorrect information in file: 'nodes.frm'.

OC Debian Lenny. mysql 5, Тип баз innodb. В папке /var/lib/Mysql лежат файлы ibdata1, ib_logfile0, ib_logfile1 и папки баз с frm-файлами.

При открытии базы в phpmyadmin, напротив каждой таблицы с типом innodb только одна надпись - "используется", таблицы других типов в этой же базе отображаются нормально и все данные в порядке.

При попытке восстановить таблицу средствами phpmyadmin, пишет ошибку, например, "Incorrect information in file settings.frm". Так же при просмотре в phpmyadmin поддерживаемых типов таблиц, тип innodb неактивен, пишет "Тип таблиц InnoDB был отключен на данном MySQL сервере", а если оригинальный файл ibdata1 переименовать и перезапустить mysql, то создается чистый ibdata1 и поддержка innodb баз активируется, но при возвращении оригинального файла ibdata на место innodb снова отключается.

Пробовал указывать опцию innodb_force_recovery, запускал mysqlcheck для восстановления, ничего не помогает.

Бэкапов конечно не делал. С этого момента перешел во вторую категорию админов, кто уже делает.

Конфиг mysql:

Код:

[client]
port        = 3306
socket        = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket        = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
port        = 3306
basedir        = /usr
datadir        = /var/lib/mysql
tmpdir        = /tmp
language    = /usr/share/mysql/english
skip-external-locking

bind-address        = 192.168.2.16
key_buffer        = 16M
max_allowed_packet    = 16M
thread_stack        = 128K
thread_cache_size    = 8
myisam-recover        = BACKUP
query_cache_limit       = 1M
query_cache_size        = 16M
expire_logs_days    = 10
max_binlog_size         = 100M
skip-bdb
#skip-innodb

innodb_data_file_path = ibdata1:12000M:autoextend

[mysqldump]
quick
quote-names
max_allowed_packet    = 16M

[isamchk]
key_buffer        = 16M

!includedir /etc/mysql/conf.d/

Может есть какой-то способ если не полностью восстановить, то хотя бы вытащить текст из ibdata?

paulus · 03.11.2009 12:00:50

В /var/log/daemon.log должна быть написана причина, по которой не запускается
InnoDB. Обычно это несоответствие размеров файликов ibdata и iblog* — реальных
и описанных в конфиге.

Обычный сбой питания не может повредить InnoDB (благодаря поддержке ACID),
для этого нужно что-то мощнее — сбой контроллера или дисков. Попробуйте
восстановить правильный размер файликов в конфиге — тогда InnoDB поднимется.

yual · 05.11.2009 08:24:07

Указал в my.cnf точный размер файлов базы и логов:

innodb_data_file_path = ibdata1:11788091392:autoextend
innodb_log_file_size = 5242880

Mysql так и не запускается. В daemon.log пишет:

Код:

Nov  5 08:59:40 mysqlserv mysqld_safe[21272]: started
Nov  5 08:59:40 mysqlserv mysqld[21276]: InnoDB: Log scan progressed past the checkpoint lsn 16 2290962980
Nov  5 08:59:40 mysqlserv mysqld[21276]: 091105  8:59:40  InnoDB: Database was not shut down normally!
Nov  5 08:59:40 mysqlserv mysqld[21276]: InnoDB: Starting crash recovery.
Nov  5 08:59:40 mysqlserv mysqld[21276]: InnoDB: Reading tablespace information from the .ibd files...
Nov  5 08:59:40 mysqlserv mysqld[21276]: InnoDB: Restoring possible half-written data pages from the doublewrite
Nov  5 08:59:40 mysqlserv mysqld[21276]: InnoDB: buffer...
Nov  5 08:59:41 mysqlserv mysqld[21276]: 091105  8:59:41  InnoDB: Starting an apply batch of log records to the database...
Nov  5 08:59:41 mysqlserv mysqld[21276]: InnoDB: Progress in percents: 0 091105  8:59:41 - mysqld got signal 11;
Nov  5 08:59:41 mysqlserv mysqld[21276]: This could be because you hit a bug. It is also possible that this binary
Nov  5 08:59:41 mysqlserv mysqld[21276]: or one of the libraries it was linked against is corrupt, improperly built,
Nov  5 08:59:41 mysqlserv mysqld[21276]: or misconfigured. This error can also be caused by malfunctioning hardware.
Nov  5 08:59:41 mysqlserv mysqld[21276]: We will try our best to scrape up some info that will hopefully help diagnose
Nov  5 08:59:41 mysqlserv mysqld[21276]: the problem, but since we have already crashed, something is definitely wrong
Nov  5 08:59:41 mysqlserv mysqld[21276]: and this may fail.
Nov  5 08:59:41 mysqlserv mysqld[21276]: 
Nov  5 08:59:41 mysqlserv mysqld[21276]: key_buffer_size=0
Nov  5 08:59:41 mysqlserv mysqld[21276]: read_buffer_size=131072
Nov  5 08:59:41 mysqlserv mysqld[21276]: max_used_connections=0
Nov  5 08:59:41 mysqlserv mysqld[21276]: max_connections=100
Nov  5 08:59:41 mysqlserv mysqld[21276]: threads_connected=0
Nov  5 08:59:41 mysqlserv mysqld[21276]: It is possible that mysqld could use up to 
Nov  5 08:59:41 mysqlserv mysqld[21276]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K
Nov  5 08:59:41 mysqlserv mysqld[21276]: bytes of memory
Nov  5 08:59:41 mysqlserv mysqld[21276]: Hope that's ok; if not, decrease some variables in the equation.
Nov  5 08:59:41 mysqlserv mysqld[21276]: 
Nov  5 08:59:41 mysqlserv mysqld[21276]: thd=(nil)
Nov  5 08:59:41 mysqlserv mysqld[21276]: Attempting backtrace. You can use the following information to find out
Nov  5 08:59:41 mysqlserv mysqld[21276]: where mysqld died. If you see no messages after this, something went
Nov  5 08:59:41 mysqlserv mysqld[21276]: terribly wrong...
Nov  5 08:59:41 mysqlserv mysqld[21276]: Cannot determine thread, fp=0xb50e6378, backtrace may not be correct.
Nov  5 08:59:41 mysqlserv mysqld[21276]: Stack range sanity check OK, backtrace follows:
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x81f3821
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x84145e8
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x8414f26
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x83d95ad
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x83db4ef
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x83c8451
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x83f15a0
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0x833663e
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0xb7edb4c0
Nov  5 08:59:41 mysqlserv mysqld[21276]: 0xb7ced6de
Nov  5 08:59:41 mysqlserv mysqld[21276]: New value of fp=(nil) failed sanity check, terminating stack trace!
Nov  5 08:59:41 mysqlserv mysqld[21276]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Nov  5 08:59:41 mysqlserv mysqld[21276]: stack trace is much more helpful in diagnosing the problem, so please do 
Nov  5 08:59:41 mysqlserv mysqld[21276]: resolve it
Nov  5 08:59:41 mysqlserv mysqld[21276]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Nov  5 08:59:41 mysqlserv mysqld[21276]: information that should help you find out what is causing the crash.
Nov  5 08:59:41 mysqlserv mysqld_safe[21285]: ended
Nov  5 09:00:01 mysqlserv /etc/init.d/mysql[21423]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Nov  5 09:00:01 mysqlserv /etc/init.d/mysql[21423]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Nov  5 09:00:01 mysqlserv /etc/init.d/mysql[21423]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Nov  5 09:00:01 mysqlserv /etc/init.d/mysql[21423]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Nov  5 09:00:01 mysqlserv /etc/init.d/mysql[21423]:

По инструкции сделал stack trace, программа выдала такой результат :

Код:

0x81f3821 handle_segfault + 769
0x84145e8 page_cur_insert_rec_low + 1672
0x8414f26 page_cur_parse_insert_rec + 1094
0x83d95ad recv_scan_log_seg_for_backup + 1933
0x83db4ef recv_recover_page + 799
0x83c8451 buf_page_io_complete + 1553
0x83f15a0 fil_aio_wait + 528
0x833663e srv_parse_data_file_paths_and_sizes + 1310
0xb7edb4c0 _end + -1351043320
0xb7ced6de _end + -1353066202

Как трактовать этот вывод не пойму.

paulus · 05.11.2009 13:49:49

Угу, а вот тут уже побился tablespace он пытается проиграть транзакции
и получает sigsegv... дальше только innodb_force_recovery. Ниже трех
ставить смысла нет — падает на третьем уровне. http://dev.mysql.com/doc/refman/5.0/en/ … overy.html

yual · 06.11.2009 09:18:40

Спасибо. После указания опции innodb_force_recovery = 6 mysql заработал. Работал не устойчиво, но работал. Но главное, что я смог сделать дамп всех баз и восстановить их в чистую базу. Теперь все работает как надо. Еще раз спасибо за помошь!

paulus · 06.11.2009 13:44:49

Замечательно И не забудьте настроить регулярные бэкапы

Форум пользователей MySQL

#1 03.11.2009 08:41:54

Восстановление innodb базы данных.

Код:

#2 03.11.2009 12:00:50

Re: Восстановление innodb базы данных.

#3 05.11.2009 08:24:07

Re: Восстановление innodb базы данных.

Код:

Код:

#4 05.11.2009 13:49:49

Re: Восстановление innodb базы данных.

#5 06.11.2009 09:18:40

Re: Восстановление innodb базы данных.

#6 06.11.2009 13:44:49

Re: Восстановление innodb базы данных.

Board footer