Have you tried starting mysqld with innodb_force_recovery = x ? (where x = values defined below)
http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html That might get you past the corruption that's killing startup. -Dan On 2/13/08 12:32 PM, "Bryan Cantwell" <[EMAIL PROTECTED]> wrote: > No input on this one? > > -----Original Message----- > From: Bryan Cantwell [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 12, 2008 11:51 AM > To: mysql@lists.mysql.com > Subject: Crashed InnoDB > > We had a power outage, now the mysql wont start at all. Here is the err file > output... Any help on how to recover? > > 080212 11:35:50 mysqld started > 080212 11:35:50 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... > 080212 11:35:50 InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 115 2637413615. > InnoDB: Doing recovery: scanned up to log sequence number 115 2637626081 > 080212 11:35:50 InnoDB: Starting an apply batch of log records to the > database... > InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 > 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 > 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 > 71 72 73 74 75 080212 11:35:51 - 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=0 > read_buffer_size=2093056 > max_used_connections=0 > max_connections=2500 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 3012828 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=(nil) > 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... > Cannot determine thread, fp=0xbf3feaf8, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80d4205 > 0x835537c > 0x82c8b43 > 0x82c97dc > 0x8294835 > 0x8295489 > 0x82851fd > 0x82b02cd > 0x8203f89 > 0x834fcb5 > 0x8388daa > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and > follow instructions on how to resolve the stack trace. Resolved > stack trace is much more helpful in diagnosing the problem, so please do > resolve it > The manual page at http://www.mysql.com/doc/en/Crashing.html contains > information that should help you find out what is causing the crash. > > You are running a statically-linked LinuxThreads binary on an NPTL system. > This can result in crashes on some distributions due to LT/NPTL conflicts. > You should either build a dynamically-linked binary, or force LinuxThreads > to be used with the LD_ASSUME_KERNEL environment variable. Please consult > the documentation for your distribution on how to do that. > 080212 11:35:51 mysqld ended
