List:General Discussion« Previous MessageNext Message »
From:jsf Date:December 30 2004 10:21pm
Subject:BIG InnoDB problems!
View as plain text  
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----
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