Description:
A database was dumped from 4.1 and then restored to a fresh directory of 5.0.44 and within days dumps from this database began crashing. The error log from the crash is below.
Interestingly, trying to restore the affected database from backup didn't work either. MySQL claimed it couldn't find a table that, in fact, the restore just had created. So presumably, on restore, mysql doesn't delete all the data, and in this case, the corrupted data, to allow for a clean restoration.
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.
How to repeat:
I don't know if it can be repeated. Create some databases in 4.1, dump them. Blow away the database directory. Install 5.0.44. Restores these databases. Don't even need to change any data. Run dumps. It may crash as described above. I don't know if it is specific to the data set or whether there is some other environmental issue.
Description: A database was dumped from 4.1 and then restored to a fresh directory of 5.0.44 and within days dumps from this database began crashing. The error log from the crash is below. Interestingly, trying to restore the affected database from backup didn't work either. MySQL claimed it couldn't find a table that, in fact, the restore just had created. So presumably, on restore, mysql doesn't delete all the data, and in this case, the corrupted data, to allow for a clean restoration. 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. How to repeat: I don't know if it can be repeated. Create some databases in 4.1, dump them. Blow away the database directory. Install 5.0.44. Restores these databases. Don't even need to change any data. Run dumps. It may crash as described above. I don't know if it is specific to the data set or whether there is some other environmental issue.