percona-discussion team mailing list archive

[mtkopone <koponen@xxxxxx>]

Public bug reported:

Output:
--
$ ./xtrabackup-1.0 --defaults-file=/etc/mysql/my.cnf --backup -- 
incremental-lsn="0:368419190" --target-dir=/home/mysql/testing/ 
incremental 
./xtrabackup-1.0  Ver beta-0.6 for 5.1.34 pc-linux-gnu (i686) 
incremental backup from 0:368419190 is enabled. 
xtrabackup: uses posix_fadvise(). 
xtrabackup: cd to /var/lib/mysql 
xtrabackup: Target instance is assumed as followings. 
xtrabackup:   innodb_data_home_dir = /var/lib/mysql 
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend 
xtrabackup:   innodb_log_group_home_dir = /var/lib/mysql 
xtrabackup:   innodb_log_files_in_group = 2 
xtrabackup:   innodb_log_file_size = 5242880 
>> log scanned up to (0 368490227) 

Copying /var/lib/mysql/ibdata1 
     to /home/mysql/testing/incremental/ibdata1.delta 
090520 13:57:28  InnoDB: Assertion failure in thread 3084293808 in 
file xtrabackup.c line 1568 
InnoDB: Failing assertion: page_offset >> 32 == 0 
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 

--

I've tried both a 0.6-binary compiled for 32-bit machines, and the
1.0-release branch compiled against 5.1.34 with the
fix_innodb_for_backup51.patch. With both, I get the same error.

The lsn given on the commandline is correct. It also happens both with
both the --incremental-lsn and --incremental-basedir -options.

It's a test setup, so I'm running VMWare 2.0.0,
With a virtual server running debian lenny: 
Linux vm2 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux. 
and the mysql I'm testing against is: 
mysql  Ver 14.14 Distrib 5.1.34, for debian-linux-gnu (i486) using readline 5.2

** Affects: percona-xtrabackup
     Importance: Undecided
         Status: New

-- 
Incremental xtrabackup failure
https://bugs.launchpad.net/bugs/378732
You received this bug notification because you are a member of Percona
developers, which is the registrant for Percona-XtraBackup.

Status in Open source backup tool for InnoDB and XtraDB: New

Bug description:
Output:
--
$ ./xtrabackup-1.0 --defaults-file=/etc/mysql/my.cnf --backup -- 
incremental-lsn="0:368419190" --target-dir=/home/mysql/testing/ 
incremental 
./xtrabackup-1.0  Ver beta-0.6 for 5.1.34 pc-linux-gnu (i686) 
incremental backup from 0:368419190 is enabled. 
xtrabackup: uses posix_fadvise(). 
xtrabackup: cd to /var/lib/mysql 
xtrabackup: Target instance is assumed as followings. 
xtrabackup:   innodb_data_home_dir = /var/lib/mysql 
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend 
xtrabackup:   innodb_log_group_home_dir = /var/lib/mysql 
xtrabackup:   innodb_log_files_in_group = 2 
xtrabackup:   innodb_log_file_size = 5242880 
>> log scanned up to (0 368490227) 

Copying /var/lib/mysql/ibdata1 
     to /home/mysql/testing/incremental/ibdata1.delta 
090520 13:57:28  InnoDB: Assertion failure in thread 3084293808 in 
file xtrabackup.c line 1568 
InnoDB: Failing assertion: page_offset >> 32 == 0 
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 

--

I've tried both a 0.6-binary compiled for 32-bit machines, and the 1.0-release branch compiled against 5.1.34 with the fix_innodb_for_backup51.patch. With both, I get the same error. 

The lsn given on the commandline is correct. It also happens both with both the --incremental-lsn and --incremental-basedir -options. 

It's a test setup, so I'm running VMWare 2.0.0,
With a virtual server running debian lenny: 
Linux vm2 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux. 
and the mysql I'm testing against is: 
mysql  Ver 14.14 Distrib 5.1.34, for debian-linux-gnu (i486) using readline 5.2