The RAID that we used to hold our mysql data was crashed a few days ago. Although it is fine now (after switching to the secondary host connector), we can't seem to start the mysqld.
We tried to start the server using the various innodb_force_recovery options (1-6) with no luck. Below is the error log with the innodb_force_recovery = 1. Any inputs are much appreciated. Thanks! 040202 13:27:32 mysqld started 040202 13:27:32 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 28 1814914366 040202 13:27:33 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 393110. InnoDB: You may have to recover from a backup. 040202 13:27:33 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 00000000... 8 040202 13:27:33 InnoDB: Page checksum 394994200 stored checksum 1142435917 InnoDB: Page lsn 28 1820582657, low 4 bytes of lsn at page end 1820222636 InnoDB: Page may be an index page where index id is 0 1660 InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 393110. 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: Look also at section 6.1 of InnoDB: http://www.innodb.com/ibman.html about InnoDB: forcing recovery. 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 InnoDB: Database page corruptio n on disk or a failed InnoDB: file read of page 698866. InnoDB: You may have to recover from a backup. 040202 13:27:36 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 0000000000.. 040202 13:28:18 InnoDB: Page checksum 1308210445 stored checksum 3312266381 InnoDB: Page lsn 28 1674093630, low 4 bytes of lsn at page end 1820530832 InnoDB: Page may be an index page where index id is 0 1657 InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 497825. 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: Look also at section 6.1 of InnoDB: http://www.innodb.com/ibman.html about InnoDB: forcing recovery. InnoDB: Probable data corruption on page 497825 InnoDB: Original record RECORD: info bits 32 0: len 4; hex 42a68d35; asc B..5;; 1: len 8; hex 800000000094ca94; asc ........;; InnoDB: on that page. Steps 1. InnoDB: Cannot find the dir slot for record RECORD: info bits 32 0: len 4; hex 42a68d35; a sc B..5;; 1: len 8; hex 800000000094d149; asc .......I;; InnoDB: on that page! 040202 13:28:18 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 000000000... 040202 13:28:18 InnoDB: Page checksum 1308210445 stored checksum 3312266381 InnoDB: Page lsn 28 1674093630, low 4 bytes of lsn at page end 1820530832 InnoDB: Page may be an index page where index id is 0 1657 040202 13:28:18 InnoDB: Assertion failure in thread 6 in file page0page.c line 116 InnoDB: We intentionally generate a memory trap. InnoDB: Send a detailed bug report to [EMAIL PROTECTED] mysqld got signal 11; 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=8388600 read_buffer_size=131072 040202 13:28:18 mysqld ended
