--stream=tar fails (archive_write_header failed)

Bug #977998 reported by Steven Ayre
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Critical
Alexey Kopytov
2.0
Fix Released
Critical
Alexey Kopytov
2.1
Fix Released
Critical
Alexey Kopytov

Bug Description

--stream=tar appears to fail with xtrabackup 2.0.0 (--stream=xbstream works fine).

Platform is Debian Squeeze x64, using the dotdeb percona binaries.

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.
[2012-04-10 12:34:11 GMT]
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
[2012-04-10 12:34:11 GMT]
120410 13:33:46 innobackupex: Starting mysql with options: --password=xxxxxxxx --user='root' --unbuffered --
120410 13:33:46 innobackupex: Connected to database with mysql child process (pid=5367)
120410 13:33:52 innobackupex: Connection to database server closed
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".
[2012-04-10 12:34:11 GMT]
innobackupex: Using mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (x86_64) using readline 5.2
innobackupex: Using mysql server version Copyright (C) 2002 MySQL AB
[2012-04-10 12:34:11 GMT]
innobackupex: Created backup directory /tmp/tmp.hKYMnWlyCa
120410 13:33:53 innobackupex: Starting mysql with options: --password=xxxxxxxx --user='root' --unbuffered --
120410 13:33:53 innobackupex: Connected to database with mysql child process (pid=5434)
120410 13:33:55 innobackupex: Connection to database server closed
[2012-04-10 12:34:11 GMT]
120410 13:33:55 innobackupex: Starting ibbackup with command: xtrabackup_51 --backup --suspend-at-end --target-dir=/tmp --compress --compress-threads=2 --stream=tar
innobackupex: Waiting for ibbackup (pid=5464) to suspend
innobackupex: Suspend file '/tmp/xtrabackup_suspended'
[2012-04-10 12:34:11 GMT]
xtrabackup_51 version 2.0.0 for MySQL server 5.1.59 unknown-linux-gnu (x86_64) (revision id: undefined)
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:100M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 4
xtrabackup: innodb_log_file_size = 268435456
>> log scanned up to (375 4004314859)
archive_write_header() failed.
[01] xtrabackup: error: cannot open the destination stream for ibdata1
[01] xtrabackup: Error: xtrabackup_copy_datafile() failed.
[01] xtrabackup: Error: failed to copy datafile.
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 371.

Related branches

Revision history for this message
Steven Ayre (steveayre) wrote :

Problem occurs both with and without --compress options.

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.
[2012-04-10 12:37:33 GMT]
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
[2012-04-10 12:37:33 GMT]
120410 13:37:14 innobackupex: Starting mysql with options: --password=xxxxxxxx --user='root' --unbuffered --
120410 13:37:14 innobackupex: Connected to database with mysql child process (pid=7038)
120410 13:37:20 innobackupex: Connection to database server closed
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".
[2012-04-10 12:37:33 GMT]
innobackupex: Using mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (x86_64) using readline 5.2
innobackupex: Using mysql server version Copyright (C) 2002 MySQL AB
[2012-04-10 12:37:33 GMT]
innobackupex: Created backup directory /tmp/tmp.QkgecwCPry
120410 13:37:21 innobackupex: Starting mysql with options: --password=xxxxxxxx --user='root' --unbuffered --
120410 13:37:21 innobackupex: Connected to database with mysql child process (pid=7111)
120410 13:37:23 innobackupex: Connection to database server closed
[2012-04-10 12:37:33 GMT]
120410 13:37:23 innobackupex: Starting ibbackup with command: xtrabackup_51 --backup --suspend-at-end --target-dir=/tmp --stream=tar
innobackupex: Waiting for ibbackup (pid=7128) to suspend
innobackupex: Suspend file '/tmp/xtrabackup_suspended'
[2012-04-10 12:37:33 GMT]
xtrabackup_51 version 2.0.0 for MySQL server 5.1.59 unknown-linux-gnu (x86_64) (revision id: undefined)
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:100M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 4
xtrabackup: innodb_log_file_size = 268435456
>> log scanned up to (375 4007342403)
archive_write_header() failed.
[01] xtrabackup: error: cannot open the destination stream for ibdata1
[01] xtrabackup: Error: xtrabackup_copy_datafile() failed.
[01] xtrabackup: Error: failed to copy datafile.
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 371.

Revision history for this message
Alexey Kopytov (akopytov) wrote :

Could you provide some additional info? I cannot reproduce it, so I'd like to see the full command line used to start the backup (incl. the commands executed on the remote host, if the tar stream is being piped to a remote host).

Is this failure persistent, i.e. does it always occur on ibdata1 on each run?

Thanks.

Changed in percona-xtrabackup:
status: New → Incomplete
Revision history for this message
Arnaud Le Blanc (arnaud-lb) wrote :

I'm seeing this error too, with the following command:

xtrabackup_55 --backup --suspend-at-end --target-dir=/home/xbm/tmp/xbm-1160806 --stream=tar

It happens when xtrabackups attempts to add ibdata1 to the archive. ibdata1 has a size of 31065112576 bytes, which is apparently more than what is allowed.

The error comes from

if (format_number(archive_entry_size(entry), h + USTAR_size_offset, USTAR_size_size, USTAR_size_max_size, strict)) {

in src/libarchive/libarchive/archive_write_set_format_ustar.c:266 (__archive_write_format_header_ustar)

Is there any workaround for this ?

Revision history for this message
Andrew Garner (muzazzi) wrote :

I ran into this as well with --stream=tar. I see xtrabackup 2.0 uses libarchive:archive_write_set_format_ustar - a format which is limited to 8GB files. If the archive error were reported by xtrabackup it would state something along the lines of:

archive_write_header: File size out of range

The pax (or restricted pax) format is likely to be more useful here as the pax format supports much larger files, but it will generate warnings with GNU tar:

# tar ztivf foo.tar.gz
-rw-r--r-- root/root 264 2012-04-19 17:59:47 backup-my.cnf
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
-rw-rw---- 0/0 2594177024 2012-04-19 17:18:19 ibdata1
...

Revision history for this message
Steven Ayre (steveayre) wrote :

Well done for tracking that size limit down. That certainly sounds like what I'm hitting - my ibdata1 is close to 100GiB.

Revision history for this message
Alexey Kopytov (akopytov) wrote :

Andrew,

Thank you for tracking down the problem.

From the libarchive man page, it looks like the 'restricted' PAX format would remove the 8 GB limit and avoid the extended keyword at the same time (if possible). Though looking at the source, files larger than 8 GB set the 'need_extension' flag and thus trigger the extended attributes even with the restricted PAX format. Those warnings are benign, but I guess they would cause a lot of confusion for users, and a lot of work on answering the related questions for us.

However, since XtraBackup uses bundled libarchive, I'm going to fix this by modifying libarchive source to suppress those SCHILY.* attributes that GNU tar is unhappy with. GNU tar is a requirement for tar streams generated by XtraBackup anyway, so we can safely assume those attributes are never used.

Thanks again for your help in verifying this bug.

Changed in percona-xtrabackup:
importance: Undecided → Critical
assignee: nobody → Alexey Kopytov (akopytov)
tags: added: i23334
Jaime Sicam (jssicam)
tags: added: i24015
tags: added: i24127
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-232

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.