Does it start up in a stable enough state to run a mysqldump of the tables?
-Dan On 2/13/08 3:54 PM, "Bryan Cantwell" <[EMAIL PROTECTED]> wrote: > I can get mysql to start with that but still complains about corruptionĀ If I > try to do optimize table for instance, it crashes againĀ > I get this now: > 080213 14:32:16 InnoDB: Error: page 4246078 log sequence number 53 188440667 > InnoDB: is in the future! Current system log sequence number 0 10477. > InnoDB: Your database may be corrupt or you may have copied the InnoDB > InnoDB: tablespace but not the InnoDB log files. See > InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html > InnoDB: for more information. > InnoDB: Dump of the tablespace extent descriptor: len 40; hex > 00000000000000010040c0000aeeffffffff000000000004aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > fe; asc @ ; > InnoDB: Serious error! InnoDB is trying to free page 4246077 > InnoDB: though it is already marked as free in the tablespace! > InnoDB: The tablespace free space info is corrupt. > InnoDB: You may need to dump your InnoDB tables and recreate the whole > InnoDB: database! > InnoDB: Please refer to > InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html > InnoDB: about forcing recovery. > 080213 14:32:16InnoDB: Assertion failure in thread 163851 in file fsp0fsp.c > line 2980 > 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.0/en/forcing-recovery.html > InnoDB: about forcing recovery. > 080213 14:32:16 - 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=1073741824 > read_buffer_size=2093056 > max_used_connections=1 > max_connections=2500 > threads_connected=1 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = > 4061404 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0xac68930 > 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=0xbe5f9f88, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80d4205 > 0x835537c > 0x829e8ca > 0x8220478 > 0x829e2c1 > 0x829e5b1 > 0x824d6d9 > 0x8208702 > 0x821c16a > 0x823077e > 0x819f81c > 0x81a00d7 > 0x8193cea > 0x8178a32 > 0x81acb2b > 0x81ae855 > 0x81b0787 > 0x81b1282 > 0x81b19f8 > 0x80f16ea > 0x80f359a > 0x80f46cb > 0x80f5747 > 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 > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0xaca10c8 = optimize table hosts > thd->thread_id=2 > 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. > > Number of processes running now: 0 > > > > From: Dan Rogart [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 12:27 PM > To: Bryan Cantwell; mysql list > Subject: Re: Crashed InnoDB > > 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 >
