page dump, page corruption during prepare

When I try to run prepare (I’ve tried with an new backup twice) on a backup made on Ubuntu 9.10 and run prepare on 10.04, I get the following error (does anyone know what this is?):

root@client:~# xtrabackup --prepare --use-memory=24G --target-dir=/mysql/2011-02-18_05-54-38
xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86_64)
xtrabackup: cd to /mysql/2011-02-18_05-54-38
xtrabackup: This target seems to be not prepared yet.
110222 3:42:11 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Warning: cannot open ./xtrabackup_logfile. will try to find.
xtrabackup: ‘ib_logfile0’ seems to be ‘xtrabackup_logfile’. will retry.
xtrabackup: xtrabackup_logfile detected: size=3418193920, start_lsn=(1588924650071)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 3418193920
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 25769803776 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
110222 3:42:12 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 26b54d6100000005000000000000000000000171f49bb68d000000000000 0000000000000000000000002e776200000000000000000200f200000000 0000000600000000ffffffff

P[ pK ;
InnoDB: End of page dump
110222 3:42:12 InnoDB: Page checksum 2533584674 (32bit_calc: 649416033), prior-to-4.0.14-form checksum 2591050710
InnoDB: stored checksum 649416033, prior-to-4.0.14-form stored checksum 2591050710
InnoDB: Page lsn 369 4103845517, low 4 bytes of lsn at page end 4103845517
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
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 http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.

So…

It turns out that the issue is that if the backup is made on a server with “innodb_fast_checksum=1” turned on, you will get this error if you try to use a restored (prepared) backup on a box NOT using innodb_fast_checksum. This also includes using the generated backup file “backup-my.cnf”, which even if you make a backup on a server using fast checksum, this file will NOT have innodb_fast_checksum specified and starting MySQL with this file will result in the failure I had.

That’s a really good catch, thanks for figuring out this problem. I will file a bug report.