James,
We've had this issue twice (every 4 months) - running on 4.0.20 - due to an old kernel (we just upgraded the kernel after the last issue).
Do you have a replicated (slave) database? We shut down the master and then the slave (a few minutes after the master to let all changes propigate), and then copy the data files from the slave to the master and restart. We have to rebuild the slave after, but the database is up and running at that point.
If that doesn't work, what about using an older (valid) backup and your binary logs? You can turn the binary logs into the SQL statements and run them on the old backup to bring the database up to date...
Also, be careful about checking the tables - if one is found to be corrupt, it is marked as unusable until it is fixed. There are also different levels of "CHECK TABLE" - are you using the appropriate one?
David
James Green wrote:
Hi,
On running the hot backup tool we receive:
ibbackup: Re-reading page at offset 0 366297088 in /var/lib/mysql/data/ibdata1 ibbackup: Re-reading page at offset 0 366297088 in /var/lib/mysql/data/ibdata1 050218 15:18:01 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex eeaefd1a0000575500007b3500006932000000017183e16e45bf0000000000000000000[garbage continues] .... (.(."u:.%.1./.7u.E.e8.'%.e.c9]q...;InnoDB: End of page dump 050218 15:18:01 InnoDB: Page checksum 4004445466, prior-to-4.0.14-form checksum 3154721000 InnoDB: stored checksum 4004445466, prior-to-4.0.14-form stored checksum 2825075037 InnoDB: Page lsn 1 1904468334, low 4 bytes of lsn at page end 1904466222 InnoDB: Page number (if stored to page already) 22357, 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 162 ibbackup: Error: page at offset 0 366297088 in /var/lib/mysql/data/ibdata1 seems corrupt! innobackup: Error: ibbackup child process has died at innobackup.pl line 332.
We have gone through (via a script) and every table in every database (all by 'mysql' is InnoDB) returns 'OK' using 'check table'.
We did suffer a hardware failure which required a table to be dropped and rebuilt, however that was resolved and everything appears to be operating fine now. Except we want the hot backup to work and it clearly doesn't.
Looking for options. We have mysqldumps but clearly restoration will be very slow. The server is Debian Linux (stable) with MySQL-4.1.9 from the mysql.com binary tarball.
Help! Many thanks!
James
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]