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
>
MarkD,
This is valid bug, and we hope we fixed it in latest Launchpad commit,
can you get new version from there ?
MarkD wrote: logs/rad- db1.002794 logs/rad- db1.002794 get_prev( next_page, mtr) == buf_frame_ get_page_ no(page) bugs.mysql. com. dev.mysql. com/doc/ refman/ 5.1/en/ forcing- recovery. html
> 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/
> 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/
>
> 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_
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://
> 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://
> 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
>
-- www.mysqlperfor manceblog. com www.percona. com/
Vadim Tkachenko, CTO
Percona Inc.
ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403
MySQL Performance Blog - http://
MySQL Consulting http://
Attend the 2009 Percona Performance Conference conferences. percona. com/
April 22-23 - http://