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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > > > > > > > -- > Eric Bergen > [EMAIL PROTECTED] > http://www.bleated.com > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
