Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Jeremy Cole (jeremyprovenscaling.com)
Date: Fri Sep 14 2007 - 03:18:17 CDT
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...
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
> 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
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql