Hi
This might be happening due to two reasons;
1 The system date might not be correct.
2. Some things wrong with log postion (Incorrect log position)

Regards,
Krishna Chandra Prajapati

On 8/31/07, Maurice Volaski <mvolaski@aecom.yu.edu> wrote:
>
> A 64-bit Gentoo Linux box had just been upgraded from MySQL 4.1 to
> 5.0.44 fresh (by dumping in 4.1 and restoring in 5.0.44) and almost
> immediately after that, during which time the database was not used,
> a crash occurred during a scripted mysqldump. So I restored and days
> later, it happened again. The crash details seem to be trying to
> suggest some other aspect of the operating system, even the memory or
> disk is flipping a bit. Or could I be running into a bug in this
> version of MySQL?
>
> Here's the output of the crash
> -----------------------------------
> InnoDB: Database page corruption on disk or a failed
> InnoDB: file read of page 533.
> InnoDB: You may have to recover from a backup.
> 070827 3:10:04 InnoDB: Page dump in ascii and hex (16384 bytes):
> len 16384; hex
>
> [dump itself deleted for brevity]
>
> ;InnoDB: End of page dump
> 070827 3:10:04 InnoDB: Page checksum 646563254,
> prior-to-4.0.14-form checksum 2415947328
> InnoDB: stored checksum 4187530870, prior-to-4.0.14-form stored
> checksum 2415947328
> InnoDB: Page lsn 0 4409041, low 4 bytes of lsn at page end 4409041
> InnoDB: Page number (if stored to page already) 533,
> 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 35
> InnoDB: (index PRIMARY of table elegance/image)
> InnoDB: Database page corruption on disk or a failed
> InnoDB: file read of page 533.
> InnoDB: You may have to recover from a backup.
> InnoDB: It is also possible that your operating
> InnoDB: system has corrupted its own file cache
> InnoDB: and rebooting your computer removes the
> InnoDB: error.
> InnoDB: If the corrupt page is an index page
> InnoDB: you can also try to fix the corruption
> InnoDB: by dumping, dropping, and reimporting
> InnoDB: the corrupt table. You can use CHECK
> InnoDB: TABLE to scan your table for corruption.
> InnoDB: See also InnoDB:
> http://dev.mysql.com/doc/refman/5.0/...-recovery.html
> InnoDB: about forcing recovery.
> InnoDB: Ending processing because of a corrupt database page.
>
> --
>
> Maurice Volaski, mvolaski@aecom.yu.edu
> Computing Support, Rose F. Kennedy Center
> Albert Einstein College of Medicine of Yeshiva University
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=p...tikc@gmail.com
>
>


--
Krishna Chandra Prajapati
MySQL DBA,

Ed Ventures e-Learning Pvt. Ltd,
201,202, Ashoka Bhoopal Chambers,
S P Road, Secunderabad 500003.
Ph. No. - 040-39188771
Url: www.ed-ventures-online.com

The checksum errors might be due to various reasons. We had similar issue
where we restored the database multiple times, replaced the ram sticks
nothing helped. Finally we drilled down the issue to the chassis. Recommend
testing the restore on a different machine to rule out any hardware issue.

--
Thanks
Alex
http://alexlurthu.wordpress.com

On 9/5/07, Krishna Chandra Prajapati <prajapatikc@gmail.com> wrote:
>
> Hi
> This might be happening due to two reasons;
> 1 The system date might not be correct.
> 2. Some things wrong with log postion (Incorrect log position)
>
> Regards,
> Krishna Chandra Prajapati
>
> On 8/31/07, Maurice Volaski <mvolaski@aecom.yu.edu> wrote:
> >
> > A 64-bit Gentoo Linux box had just been upgraded from MySQL 4.1 to
> > 5.0.44 fresh (by dumping in 4.1 and restoring in 5.0.44) and almost
> > immediately after that, during which time the database was not used,
> > a crash occurred during a scripted mysqldump. So I restored and days
> > later, it happened again. The crash details seem to be trying to
> > suggest some other aspect of the operating system, even the memory or
> > disk is flipping a bit. Or could I be running into a bug in this
> > version of MySQL?
> >
> > Here's the output of the crash
> > -----------------------------------
> > InnoDB: Database page corruption on disk or a failed
> > InnoDB: file read of page 533.
> > InnoDB: You may have to recover from a backup.
> > 070827 3:10:04 InnoDB: Page dump in ascii and hex (16384 bytes):
> > len 16384; hex
> >
> > [dump itself deleted for brevity]
> >
> > ;InnoDB: End of page dump
> > 070827 3:10:04 InnoDB: Page checksum 646563254,
> > prior-to-4.0.14-form checksum 2415947328
> > InnoDB: stored checksum 4187530870, prior-to-4.0.14-form stored
> > checksum 2415947328
> > InnoDB: Page lsn 0 4409041, low 4 bytes of lsn at page end 4409041
> > InnoDB: Page number (if stored to page already) 533,
> > 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 35
> > InnoDB: (index PRIMARY of table elegance/image)
> > InnoDB: Database page corruption on disk or a failed
> > InnoDB: file read of page 533.
> > InnoDB: You may have to recover from a backup.
> > InnoDB: It is also possible that your operating
> > InnoDB: system has corrupted its own file cache
> > InnoDB: and rebooting your computer removes the
> > InnoDB: error.
> > InnoDB: If the corrupt page is an index page
> > InnoDB: you can also try to fix the corruption
> > InnoDB: by dumping, dropping, and reimporting
> > InnoDB: the corrupt table. You can use CHECK
> > InnoDB: TABLE to scan your table for corruption.
> > InnoDB: See also InnoDB:
> > http://dev.mysql.com/doc/refman/5.0/...-recovery.html
> > InnoDB: about forcing recovery.
> > InnoDB: Ending processing because of a corrupt database page.
> >
> > --
> >
> > Maurice Volaski, mvolaski@aecom.yu.edu
> > Computing Support, Rose F. Kennedy Center
> > Albert Einstein College of Medicine of Yeshiva University
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:
> > http://lists.mysql.com/mysql?unsub=p...tikc@gmail.com
> >
> >
>
>
> --
> Krishna Chandra Prajapati
> MySQL DBA,
>
> Ed Ventures e-Learning Pvt. Ltd,
> 201,202, Ashoka Bhoopal Chambers,
> S P Road, Secunderabad 500003.
> Ph. No. - 040-39188771
> Url: www.ed-ventures-online.com
>

Thank you for your replies. I attempted to restore again and most
oddly, mysql complained that it couldn't restore to a particular
table because it wasn't in the database, which, of course, it had to
be because the restore itself had just recreated it. So I blew away
the entire mysql directory on the disk, updated to 5.0.45, and then
it did not complain when I restored that time. So far, it has not
since.


>Hi
>This might be happening due to two reasons;
>1 The system date might not be correct.
>2. Some things wrong with log postion (Incorrect log position)
>
>Regards,
>Krishna Chandra Prajapati


>The checksum errors might be due to various reasons. We had similar
>issue where we restored the database multiple times, replaced the
>ram sticks nothing helped. Finally we drilled down the issue to the
>chassis. Recommend testing the restore on a different machine to
>rule out any hardware issue.
>
>--
>Thanks
>Alex
><http://alexlurthu.wordpress.com>http://alexlurthu.wordpress.com


>On 8/31/07, Maurice Volaski
><<mailto:mvolaski@aecom.yu.edu>mvolaski@aecom.yu. edu> wrote:
>
>A 64-bit Gentoo Linux box had just been upgraded from MySQL 4.1 to
>5.0.44 fresh (by dumping in 4.1 and restoring in 5.0.44) and almost
>immediately after that, during which time the database was not used,
>a crash occurred during a scripted mysqldump. So I restored and days
>later, it happened again. The crash details seem to be trying to
>suggest some other aspect of the operating system, even the memory or
>disk is flipping a bit. Or could I be running into a bug in this
>version of MySQL?
>


--

Maurice Volaski, mvolaski@aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University