From: Manuel Arostegui Date: February 13 2013 7:37am Subject: Re: Bad Crash in Debian Mysql List-Archive: http://lists.mysql.com/backup/164 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d041826c86ddd1104d5963878 --f46d041826c86ddd1104d5963878 Content-Type: text/plain; charset=ISO-8859-1 2013/2/12 Martin Wodrich > 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. --f46d041826c86ddd1104d5963878--