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
