List:General Discussion« Previous MessageNext Message »
From:jsf Date:December 31 2004 5:30am
Subject:Re: BIG InnoDB problems!
View as plain text  
Thanks Eric,

We already tried levels 1, 3 and 5...

no soap.  I'm on the verge of thinking it's a bug.



:-(

J.


On Fri, 31 Dec 2004 00:06:28 +0000, Eric Bergen <eric.bergen@stripped> wrote:
> It looks like your tablespace is corrupt.  Check this doc out:
> http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
> 
> On Thu, 30 Dec 2004 17:21:40 -0500, jsf <jfreeman@stripped> wrote:
> > I've been struggling with this problem for the last few days.  I've
> > enlisted the help of some colleagues on the NYLUG (NY Linux User's
> > Group) list but finally we figured this is the best place to look for
> > some help.
> >
> > We have a server running SLES 9.0 (SuSE Linux Enterprise Server 9.0) and:
> >
> > mysqladmin  Ver 8.41 Distrib 4.1.8a, for pc-linux-gnu on i686
> >
> > There are 5 MySQL databases on the server.  The smallest has 5 tables,
> > the largest 14 tables.  All the tables in all the databases are myISAM
> > tables.
> >
> > There is ONE database on the server that we are trying to create/work
> > with that is all InnoDB tables.
> >
> > We are having serious problems with these tables.
> >
> > There are indications in the error logfile regarding what to do to try
> > and discover the root of these problems and fix them.  I will begin
> > pursuing those options shortly after posting this but as:
> >
> > 1) We're under a deadline with the application in question that
> > requires the InnoDB tables and
> >
> > 2) Although I'm the most qualified person, from a technical
> > standpoint, at my institution to try and get this fixed, that's not
> > saying much as I'm not THAT deeply technical.
> >
> > I thought I'd risk posting some of the logfile here to see what the
> > experts have to say.  Please accept my apologies for just coming here
> > and dumping this on the list's lap.
> >
> > I will try to figure it out myself but if anyone can help guide me
> > towards a solution in the meantime I'd be much obliged.
> >
> > Many thanks in advance.
> >
> > Joshua
> >
> > Here is the output of 'tail -100' on the error logfile:
> >
> > ------snip------
> >
> > InnoDB: log sequence number 0 241346488.
> > InnoDB: Doing recovery: scanned up to log sequence number 0 241346521
> > InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.000052
> > 041230 16:43:20  InnoDB: Flushing modified pages from the buffer pool...
> > 041230 16:43:20  InnoDB: Started; log sequence number 0 241346521
> > InnoDB: !!! innodb_force_recovery is set to 5 !!!
> > 041230 16:43:20 [Warning] mysql.user table is not updated to new
> > password format; Disabling new password usage until
> > mysql_fix_privilege_tables is run
> > 041230 16:43:20 [Warning] Can't open and lock time zone table: Table
> > 'mysql.time_zone_leap_second' doesn't exist trying to live without
> > them
> > /usr/local/libexec/mysqld: ready for connections.
> > Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
> > distribution
> > InnoDB: Error: trying to access page number 940269659 in space 0,
> > InnoDB: space name ./ibdata1,
> > InnoDB: which is outside the tablespace bounds.
> > InnoDB: Byte offset 0, len 16384, i/o type 10
> > 041230 16:46:01InnoDB: Assertion failure in thread 1123867568 in file
> > fil0fil.c line 3729
> > 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/mysql/en/Forcing_recovery.html
> > InnoDB: about forcing recovery.
> > 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=16777216
> > read_buffer_size=131072
> > max_used_connections=2
> > max_connections=100
> > threads_connected=1
> > It is possible that mysqld could use up to
> > key_buffer_size + (read_buffer_size +
> > sort_buffer_size)*max_connections = 80383 K
> > bytes of memory
> > Hope that's ok; if not, decrease some variables in the equation.
> >
> > thd=0x89441a8
> > 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=0x42fcb1ac, backtrace may not be correct.
> > Stack range sanity check OK, backtrace follows:
> > 0x815f0cf
> > 0xffffe420
> > 0x82e71d5
> > 0x82e71d5
> > 0x82db68f
> > 0x830479f
> > 0x8304cc8
> > 0x82be800
> > 0x82d14a6
> > 0x82ccafb
> > 0x82cd865
> > 0x826232b
> > 0x827915a
> > 0x81fe924
> > 0x81ef33c
> > 0x820aead
> > 0x820b19d
> > 0x8201554
> > 0x8202739
> > 0x81796cb
> > 0x817c1b4
> > 0x817de5d
> > 0x817f137
> > 0x401619ed
> > 0x403519ca
> > 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 0x8951778 = DROP DATABASE `josh_Test`
> > thd->thread_id=5
> > 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.
> >
> > Number of processes running now: 0
> > 041230 16:46:01  mysqld restarted
> > 041230 16:46:01  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...
> > 041230 16:46:01  InnoDB: Starting log scan based on checkpoint at
> > InnoDB: log sequence number 0 241346521.
> > InnoDB: Doing recovery: scanned up to log sequence number 0 241346554
> > InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.000053
> > 041230 16:46:01  InnoDB: Flushing modified pages from the buffer pool...
> > 041230 16:46:01  InnoDB: Started; log sequence number 0 241346554
> > InnoDB: !!! innodb_force_recovery is set to 5 !!!
> > 041230 16:46:01 [Warning] mysql.user table is not updated to new
> > password format; Disabling new password usage until
> > mysql_fix_privilege_tables is run
> > 041230 16:46:01 [Warning] Can't open and lock time zone table: Table
> > 'mysql.time_zone_leap_second' doesn't exist trying to live without
> > them
> > /usr/local/libexec/mysqld: ready for connections.
> > Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
> > distribution
> > -----snip----
> > 
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:    http://lists.mysql.com/mysql?unsub=1
> >
> >
> 
> 
> --
> Eric Bergen
> eric.bergen@stripped
> http://www.bleated.com
>
Thread
BIG InnoDB problems!jsf30 Dec
  • Re: BIG InnoDB problems!Eric Bergen31 Dec
    • Re: BIG InnoDB problems!jsf31 Dec
Re: BIG InnoDB problems!Heikki Tuuri31 Dec
  • Re: BIG InnoDB problems!jsf31 Dec
Re: BIG InnoDB problems!Heikki Tuuri3 Jan
  • Re: BIG InnoDB problems!jsf3 Jan
Re: BIG InnoDB problems!Heikki Tuuri3 Jan
  • Re: BIG InnoDB problems!jsf3 Jan
Re: BIG InnoDB problems!Heikki Tuuri3 Jan
Re: BIG InnoDB problems!Heikki Tuuri11 Jan