List:Backup« Previous MessageNext Message »
From:Manuel Arostegui Date:February 13 2013 7:37am
Subject:Re: Bad Crash in Debian Mysql
View as plain text  
2013/2/12 Martin Wodrich <martin@stripped>

> My Mysql-Server (based on Debian Squeeze) will not start.
>
> If i try to start manually i get this messages:
> -----------------------------------------------
> 130212 20:29:57 [Note] Plugin 'FEDERATED' is disabled.
> 130212 20:29:57  InnoDB: Initializing buffer pool, size = 8.0M
> 130212 20:29:57  InnoDB: Completed initialization of buffer pool
> InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
> InnoDB: Skipping log redo
> InnoDB: Database page corruption on disk or a failed
> InnoDB: file read of page 11.
> InnoDB: You may have to recover from a backup.
> 130212 20:29:57  InnoDB: Page dump in ascii and hex (16384 bytes):
> ...
> B: End of page dump
> 130212 20:29:57  InnoDB: Page checksum 1644745718, prior-to-4.0.14-form
> checksum
> 3307808961
> InnoDB: stored checksum 1292765135, prior-to-4.0.14-form stored checksum 0
> InnoDB: Page lsn 0 1910861244, low 4 bytes of lsn at page end 0
> InnoDB: Page number (if stored to page already) 11,
> InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
> InnoDB: Page may be an update undo log page
> InnoDB: Page may be an index page where index id is 0 3
> InnoDB: (index "CLUST_IND" of table "SYS_INDEXES")
> InnoDB: Database page corruption on disk or a failed
> InnoDB: file read of page 11.
> InnoDB: You may have to recover from a backup.
> InnoDB: It is also possible that your operating
> InnoDB: system has corrupted its own file cache
> InnoDB: and rebooting your computer removes the
> InnoDB: error.
> InnoDB: If the corrupt page is an index page
> InnoDB: you can also try to fix the corruption
> InnoDB: by dumping, dropping, and reimporting
> InnoDB: the corrupt table. You can use CHECK
> InnoDB: TABLE to scan your table for corruption.
> InnoDB: See also
> http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> InnoDB: Page directory corruption: infimum not pointed to
> 130212 20:29:57  InnoDB: Page dump in ascii and hex (16384 bytes):
> ...
> ;InnoDB: End of page dump
> 130212 20:29:57  InnoDB: Page checksum 1644745718, prior-to-4.0.14-form
> checksum
> 3307808961
> InnoDB: stored checksum 1292765135, prior-to-4.0.14-form stored checksum 0
> InnoDB: Page lsn 0 1910861244, low 4 bytes of lsn at page end 0
> InnoDB: Page number (if stored to page already) 11,
> InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
> InnoDB: Page may be an update undo log page
> InnoDB: Page may be an index page where index id is 0 3
> InnoDB: (index "CLUST_IND" of table "SYS_INDEXES")
> InnoDB: Page directory corruption: supremum not pointed to
> 130212 20:29:57  InnoDB: Page dump in ascii and hex (16384 bytes):
> ...
> ;InnoDB: End of page dump
> 130212 20:29:57  InnoDB: Page checksum 1644745718, prior-to-4.0.14-form
> checksum
> 3307808961
> InnoDB: stored checksum 1292765135, prior-to-4.0.14-form stored checksum 0
> InnoDB: Page lsn 0 1910861244, low 4 bytes of lsn at page end 0
> InnoDB: Page number (if stored to page already) 11,
> InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
> InnoDB: Page may be an update undo log page
> InnoDB: Page may be an index page where index id is 0 3
> InnoDB: (index "CLUST_IND" of table "SYS_INDEXES")
> InnoDB: Next record offset is nonsensical 61113 in record at offset 0
> InnoDB: rec address 0xf3a70000, first buffer frame 0xf3a60000
> InnoDB: buffer pool high end 0xf4260000, buf fix count 1
> 130212 20:29:57  InnoDB: Page dump in ascii and hex (16384 bytes):
> ...
> ;InnoDB: End of page dump
> 130212 20:29:57  InnoDB: Page checksum 1644745718, prior-to-4.0.14-form
> checksum
> 3307808961
> InnoDB: stored checksum 1292765135, prior-to-4.0.14-form stored checksum 0
> InnoDB: Page lsn 0 1910861244, low 4 bytes of lsn at page end 0
> InnoDB: Page number (if stored to page already) 11,
> InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
> InnoDB: Page may be an update undo log page
> InnoDB: Page may be an index page where index id is 0 3
> InnoDB: (index "CLUST_IND" of table "SYS_INDEXES")
> 130212 20:29:57  InnoDB: Assertion failure in thread 4140046032 in file
> ../../../storage/innobase/include/page0page.ic line 591
> 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.1/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> 19:29:57 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 =
> 345939 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+0x2d) [0xf75298ad]
> /usr/sbin/mysqld(handle_fatal_signal+0x4a4) [0xf730de64]
> [0xf6f55400]
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.htmlcontains
> information that should help you find out what is causing the crash.
> -------------------------------------------------------------------------
>
> What can I do?
> I don't have an useable backup.
>

Doesn't look good to me. And not having a proper backup looks even worse :)
I see you've used  innodb_force_recovery = 6....have you tried the rest of
the recovery levels? I don't think they will help, but just in case. If
you're able to get your DB started, you can do a mysqldump and place it in
some other server.
You are having a serious corruption, if you're not able to start your DB,
you have lost everything.

Good luck
Manuel.

Thread
Bad Crash in Debian MysqlMartin Wodrich12 Feb
  • Re: Bad Crash in Debian MysqlManuel Arostegui13 Feb
    • Re: Bad Crash in Debian MysqlMartin Wodrich13 Feb