Re: MySQL InnoDB startup problem
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
RE: MySQL InnoDB startup problem
I have been using .49 for well over 1 month now. Not sure how it was corrupted but it happened. I followed the instructions with some variation and was able to recover everything. In my.cnf I added ' set-variable = innodb_force_recovery=4'. I was then able to start the database, and did a mysqldump to dump the affected tables/databases into files. I then stopped the database, and deleted the innodb files. I removed the line from my.cnf, restarted mysql. It recreated the innodb files and I dumped the data back in. Perhaps there may have been a faster way, but this way seemed to go smoothly. David Piasecki Software Engineer -Original Message- From: Heikki Tuuri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 11:45 PM To: [EMAIL PROTECTED] Subject: Re: MySQL InnoDB startup problem 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 - 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
Re: MySQL InnoDB startup problem
David, if the corruption happens again, please run CHECK TABLE and report what you get to 'hostname'.err. 3.23.52 will also contain diagnostic code which will help to track the problem. Best regards, Heikki - Original Message - From: David Piasecki [EMAIL PROTECTED] To: 'Heikki Tuuri' [EMAIL PROTECTED] Sent: Wednesday, May 22, 2002 7:05 PM Subject: RE: MySQL InnoDB startup problem I already restored the database as I described on the mysql mailing list, so I won't be able to run 'check table'. Everything is now running smoothly. Thanks. David Piasecki Software Engineer -Original Message- From: Heikki Tuuri [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 12:17 AM To: David Piasecki Subject: Re: MySQL InnoDB startup problem David, you should use the my.cnf option set-variable = innodb_force_recovery=4 to get mysqld up. Please run CHECK TABLE on your InnoDB tables and report to me what it prints to the MySQL error log 'hostname'.err. Regards, Heikki - 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
