Can't restart MySQL after innodb table filled up
I'm having problems restarting a MySQL server after a certain table reached maximum capacity. I managed to dump my entire database to a flat file before I restarted the server however when I tried to re-import my data the operation failed. My database size set to 500M in the innodb section of my my.cnf file. I'm running RH 7.2, kernel 2.4.19pre1 with 512M of RAM and have rebooted the server without any change in results. I've also upgraded MySQL-Max from 3.23.48 to 3.23.49a using the RPMS on mysql.com. I've tried removing all the innodb files within my database directory and MySQL seems to build the new 500M file properly but then crashes with the following message in the mysql.log: 020304 11:33:01 mysqld started 020304 11:33:02 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 1819350038 InnoDB: Assertion failure in thread 4096 in file ../include/buf0buf.ic line 265 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=1044480 sort_buffer=4194296 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 773739 K bytes of memory Hope that's ok, if not, decrease some variables in the equation 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... Bogus stack limit or frame pointer, fp=0xbfffe0b8, stack_bottom=0x49043190, thread_stack=65536, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0x47f89f20 is invalid pointer thd-thread_id=138727664 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 138727664 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash 020304 11:33:02 mysqld ended - I've also tried changing a few values in the my.cnf file including changing the number of threads to 1 and increasing the size of the DB to 600M. Is this a known bug? Thanks, -- Erik Barker Sr. Systems Engineer NetNation Communications Inc. http://www.netnation.com | http://www.domainpeople.com - 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: Can't restart MySQL after innodb table filled up
Erik, this is probably not a bug. Your log files probably are not the ones which belong together with the current data file(s). When you start the database it tries to use the obsolete log files in recovery. From the manual: If something goes wrong in an InnoDB database creation, you should delete all files created by InnoDB. This means all data files, all log files, the small archived log file, and in the case you already did create some InnoDB tables, delete also the corresponding .frm files for these tables from the MySQL database directories. Then you can try the InnoDB database creation again. It is best to start the MySQL server from a command prompt so that you see what is happening. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ Speed up adding of features to MySQL/InnoDB through support contracts See http://www.innodb.com for the online manual and latest news on InnoDB -Original Message- From: Erik Barker [EMAIL PROTECTED] Newsgroups: mailing.database.mysql Date: Monday, March 04, 2002 10:07 PM Subject: Can't restart MySQL after innodb table filled up I'm having problems restarting a MySQL server after a certain table reached maximum capacity. I managed to dump my entire database to a flat file before I restarted the server however when I tried to re-import my data the operation failed. My database size set to 500M in the innodb section of my my.cnf file. I'm running RH 7.2, kernel 2.4.19pre1 with 512M of RAM and have rebooted the server without any change in results. I've also upgraded MySQL-Max from 3.23.48 to 3.23.49a using the RPMS on mysql.com. I've tried removing all the innodb files within my database directory and MySQL seems to build the new 500M file properly but then crashes with the following message in the mysql.log: 020304 11:33:01 mysqld started 020304 11:33:02 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 1819350038 InnoDB: Assertion failure in thread 4096 in file ../include/buf0buf.ic line 265 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=1044480 sort_buffer=4194296 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 773739 K bytes of memory Hope that's ok, if not, decrease some variables in the equation 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... Bogus stack limit or frame pointer, fp=0xbfffe0b8, stack_bottom=0x49043190, thread_stack=65536, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0x47f89f20 is invalid pointer thd-thread_id=138727664 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 138727664 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash 020304 11:33:02 mysqld ended - I've also tried changing a few values in the my.cnf file including changing the number of threads to 1 and increasing the size of the DB to 600M. Is this a known bug? Thanks, -- Erik Barker Sr. Systems Engineer NetNation Communications Inc. http://www.netnation.com | http://www.domainpeople.com - 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: Can't restart MySQL after innodb table filled up
On Monday 04 March 2002 03:21 pm, Heikki Tuuri wrote: Erik, this is probably not a bug. Your log files probably are not the ones which belong together with the current data file(s). When you start the database it tries to use the obsolete log files in recovery. From the manual: If something goes wrong in an InnoDB database creation, you should delete all files created by InnoDB. This means all data files, all log files, the small archived log file, and in the case you already did create some InnoDB tables, delete also the corresponding .frm files for these tables from the MySQL database directories. Then you can try the InnoDB database creation again. It is best to start the MySQL server from a command prompt so that you see what is happening. Is there now, or later, plans for an automatic procedure for deleting an InnoDB Db and ALL associated files (ie; Delete DB and all) ? Thanks, Anthony Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ Speed up adding of features to MySQL/InnoDB through support contracts See http://www.innodb.com for the online manual and latest news on InnoDB -Original Message- From: Erik Barker [EMAIL PROTECTED] Newsgroups: mailing.database.mysql Date: Monday, March 04, 2002 10:07 PM Subject: Can't restart MySQL after innodb table filled up I'm having problems restarting a MySQL server after a certain table reached maximum capacity. I managed to dump my entire database to a flat file before I restarted the server however when I tried to re-import my data the operation failed. My database size set to 500M in the innodb section of my my.cnf file. I'm running RH 7.2, kernel 2.4.19pre1 with 512M of RAM and have rebooted the server without any change in results. I've also upgraded MySQL-Max from 3.23.48 to 3.23.49a using the RPMS on mysql.com. I've tried removing all the innodb files within my database directory and MySQL seems to build the new 500M file properly but then crashes with the following message in the mysql.log: 020304 11:33:01 mysqld started 020304 11:33:02 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 1819350038 InnoDB: Assertion failure in thread 4096 in file ../include/buf0buf.ic line 265 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=1044480 sort_buffer=4194296 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 773739 K bytes of memory Hope that's ok, if not, decrease some variables in the equation 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... Bogus stack limit or frame pointer, fp=0xbfffe0b8, stack_bottom=0x49043190, thread_stack=65536, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0x47f89f20 is invalid pointer thd-thread_id=138727664 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 138727664 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash 020304 11:33:02 mysqld ended - I've also tried changing a few values in the my.cnf file including changing the number of threads to 1 and increasing the size of the DB to 600M. Is this a known bug? Thanks, -- Erik Barker Sr. Systems Engineer NetNation Communications Inc. http://www.netnation.com | http://www.domainpeople.com - 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
