From: Jeremy Cole (jeremyprovenscaling.com)
Date: Fri Sep 14 2007 - 03:18:17 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]