Hi Thanks for the help. Even though an rpm -qV -a on the machine listed no likely candidates for corruption, a complete uninstall and reinstall of mysql and mysql-max packages seems to have have fixed whatever the problem was (running off the backed up data).
David -----Original Message----- From: Ware Adams [mailto:[EMAIL PROTECTED] Sent: 25 May 2005 17:31 To: David Brewster Cc: mysql@lists.mysql.com Subject: Re: Restoring InnoDB databases from backups causing problems On May 25, 2005, at 10:06 AM, David Brewster wrote: > Here is the log dump :- > > Thanks > David > > 050525 13:24:10 InnoDB: Started > /usr/sbin/mysqld-max: ready for connections. > Version: '4.0.15-Max' socket: '/var/lib/mysql/mysql.sock' port: 3306 > 050525 13:24:11 InnoDB: Assertion failure in thread 114696 in file > fsp0fsp.c line 3034 > InnoDB: We intentionally generate a memory trap. Well, InnoDB is crashing immediately on startup. Is that how it was crashing when you were using the corrupt table space? You can scan back in the log or look in the log for that data directory. If it's crashing the same way this table space might be corrupt also. If it's a different cause, you might get lucky by upgrading InnoDB. The current 4.0 version is 4.0.24. I would _not_ upgrade to 4.1 until you fix this...you can't easily downgrade InnoDB that has gone to 4.1. If you do try upgrading to 4.0.24, I would work on a copy of this dataset (e.g. a copy of the backup which is now failing). You don't want to do any more damage. Good luck, Ware -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
