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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/en/forcing-recovery.html > > InnoDB: about forcing recovery. > > InnoDB: Ending processing because of a corrupt database page. > > > > -- > > > > Maurice Volaski, [EMAIL PROTECTED] > > 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/[EMAIL PROTECTED] > > > > > > > -- > 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 >
