David, did you upgrade from a very old version of MySQL to .49? The sorting order of latin1 accent characters was changed about 8 months ago, and that may cause the assertion you have encountered. You should dump and reimport your tables if you have accent characters.
Anyway, the B-tree index is now corrupt. Please use the instructions of section 6.1 in http://www.innodb.com/ibman.html to force recovery. Then dump + drop + reimport. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB ----- Original Message ----- From: ""David Piasecki"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Wednesday, May 22, 2002 8:04 AM Subject: MySQL InnoDB startup problem > I'm running MySQL 3.23.49. Everything was going good until today. I did > a couple of large table reads/inserts/deletes on the InnoDB tables which > appeared to go fine. I then restarted MySQL which also appeared to go > fine. From that point on, however, I kept losing connection with the DB, > and couldn't run any queries. A check of the error log reveals the > following: > > ---start err log--- > 020521 21:54:13 mysqld restarted > 020521 21:54:19 InnoDB: Database was not shut down normally. > InnoDB: Starting recovery from log files... > InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 0 2556753944 > 020521 21:54:19 InnoDB: Flushing modified pages from the buffer pool... > 020521 21:54:19 InnoDB: Started > /usr/local/mysql/libexec/mysqld: ready for connections > InnoDB: Assertion failure in thread 508094464 in file btr0btr.c line 574 > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > 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 agaist 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=268431360 > record_buffer=131072 > sort_buffer=524280 > max_used_connections=0 > max_connections=400 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 518136 > K > bytes of memory > Hope that's ok, if not, decrease some variables in the equation > ---end err log--- > > I tried grabbing the latest source and recompiling the database, but > still no go. Unfortunately I don't have a backup of the InnoDB tables, > so there isn't a whole lot that I can do in that respect. The data > appears to still be in the tables, because I can on occasion do a select > and it will return data before the database dies. > > Anyone have any experience with this sort of problem? Thanks. > > > David Piasecki > Software Engineer > > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
