Hi! >On Thu, Dec 27, 2001 at 06:56:03PM +0200, Heikki Tuuri wrote: >> * Recovery has been made more resilient to corruption of log files. > >Can I ask what you mean here? If the log files are corrupt, is >recovery still possible then? Or are the log files themselves less >likely to get corrupted? I'm assuming the former, but I'm curious.
A good question. InnoDB cannot repair a corrupt log file because I have not activated log mirroring. But the problem was that in two cases people reported an assertion failing in roll-forward of the log. I have added two things alleviate the problem: * There are now assertions which check that the data is ok when a log record is written to the log buffer of InnoDB. These assertions eliminate the possibility that the corruption of log files actually is caused by some bug in InnoDB, or some random memory corruption. * Roll-forward does not assert any more, but prints a warning message, and ends the log scan. Even if there is log corruption, if you are lucky you can get a consistent version of the database, or maybe you need dump and reimport some tables. I do not know what caused the log corruption. In one case it may have been the buggy I/O system of Linux 2.5.1. After reboot the database recovered ok. This suggests the Linux file cache was corrupt, but the data on disk was ok. Generally, corrupt log files, like corrupt data files, require recovery from a backup to restore the database. >-- >Michael T. Babcock >CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) >http://www.fibrespeed.net/~mbabcock/ Regards, Heikki Innobase Oy --------------------------------------------------------------------- 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
