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]



Reply via email to