Hi Maurice,
You say the MySQL data wasn't on the stuck volume, but were the InnoDB logs?
What is the disk configuration?
It sounds to me like bad hardware/software, which, unfortunately MySQL
and InnoDB cannot protect you from...
Regards,
Jeremy
Maurice Volaski wrote:
Some processes on a server (64-bit Gentoo Linux with MySQL 5.0.44),
which seemed to be related to I/O on LVM volumes hung and it was
necessary to force reboot it. The mysql data was not on an LVM volume
though it still may have been affected since over time, more and more
processes became unresponsive. While fsck recovered the journal and
detected no problems on any volume, at least one database was not
spared:
070911 23:40:34 InnoDB: Page checksum 3958948568,
prior-to-4.0.14-form checksum 2746081740
InnoDB: stored checksum 2722580120, prior-to-4.0.14-form stored
checksum 2746081740
InnoDB: Page lsn 0 491535, low 4 bytes of lsn at page end 491535
InnoDB: Page number (if stored to page already) 199,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 17
InnoDB: Also the page in the doublewrite buffer is corrupt.
InnoDB: Cannot continue operation.
Is it wrong to expect InnoDB to have avoided this or does it suggest
that it couldn't have, i.e., a hardware defect?
--
high performance mysql consulting
www.provenscaling.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
