MarkD,

This is valid bug, and we hope we fixed it in latest Launchpad commit,
can you get new version from there ?



MarkD wrote:
> Hello,
> 
> if i --prepare my backup, i get the following errors:
> 
> # ./xtrabackup --prepare                     
> ./xtrabackup  Ver beta-0.4 for 5.1.32 unknown-linux-gnu (x86_64)     
> xtrabackup_logfile detected: size=231063552, start_lsn=(23 1769429644)
> xtrabackup: Starting InnoDB instance for recovery.                    
> xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
> InnoDB: Log scan progressed past the checkpoint lsn 23 1769429644                
> 090402 11:01:12  InnoDB: Database was not shut down normally!                    
> InnoDB: Starting crash recovery.                                                 
> InnoDB: Reading tablespace information from the .ibd files...                    
> InnoDB: Restoring possible half-written data pages from the doublewrite          
> InnoDB: buffer..
> InnoDB: Doing recovery: scanned up to log sequence number 23 1774672384 (2 %)    
> InnoDB: Doing recovery: scanned up to log sequence number 23 1779915264 (4 %)  
> ....
> InnoDB: Doing recovery: scanned up to log sequence number 23 2000116224 (99 %)
> InnoDB: Doing recovery: scanned up to log sequence number 23 2000474712 (99 %)
> 090402 11:28:39  InnoDB: ERROR: We were only able to scan the log up to 23 2000474712
> InnoDB: but a database page a had an lsn 23 2137052144. It is possible that the
> InnoDB: database is now corrupt!
> 090402 11:28:39  InnoDB: Starting an apply batch of log records to the database...
> InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> InnoDB: Last MySQL binlog file position 0 16569046, file name /mysql/logs/rad-db1.002794
> 090402 11:29:25  InnoDB: Started; log sequence number 23 2000474712
> 
> [notice (again)]
>   If you use binary log and don't use any hack of group commit,
>   the binary log position seems to be:
> InnoDB: Last MySQL binlog file position 0 16569046, file name /mysql/logs/rad-db1.002794
> 
> 090402 11:29:25  InnoDB: Starting shutdown...
> 090402 11:29:27  InnoDB: Assertion failure in thread 1171810624 in file btr/btr0pcur.c line 402
> InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == buf_frame_get_page_no(page)
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
> InnoDB: about forcing recovery.
> Aborted
> 
> Is this related to this bugreport or something completly different? I
> did not check, if this backup is functional or not.
> 
> Greets
> Mark
> 


-- 
Vadim Tkachenko, CTO
Percona Inc.
ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403
MySQL Performance Blog - http://www.mysqlperformanceblog.com
MySQL Consulting http://www.percona.com/

  Attend the 2009 Percona Performance Conference
  April 22-23 - http://conferences.percona.com/