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 > > --------------------------------------------------------------------- > 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
