xtrabackup-2.0: This does not look like a tar archive

[Alex Yurchenko]

Not sure if this belongs here or in XtraDB Cluster:

When trying to get xtrabackup SST (xtrabackup installed from RPM, mysql binaries from Percona XtraDB Cluster 5.5.20 replease), the following happened:

donor:
120407 8:13:28 [Note] WSREP: Running: 'wsrep_sst_xtrabackup 'donor' 'ec2-50-18-2-242.us-west-1.compute.amazonaws.com:4444/xtrabackup_sst' 'root:' '/var/lib/mysql/' '/etc/my.cnf' 'b17f0aa1-8046-11e1-0800-6792537af21d' '904047' '0''
120407 8:13:28 [Note] WSREP: sst_donor_thread signaled with 0
120407 8:13:38 [Note] WSREP: 1 (ip-10-176-203-239): State transfer to 0 (ip-10-168-41-89) complete.

slave:
120407 8:13:28 [Note] WSREP: Running: 'wsrep_sst_xtrabackup 'joiner' 'ec2-50-18-2-242.us-west-1.comp
ute.amazonaws.com' '' '/var/lib/mysql/' '/etc/my.cnf' '2479' 2>sst.err'
120407 8:13:28 [Note] WSREP: Prepared SST request: xtrabackup|ec2-50-18-2-242.us-west-1.compute.amaz
onaws.com:4444/xtrabackup_sst
...
120407 8:13:38 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup 'joiner' 'ec2-50-18
-2-242.us-west-1.compute.amazonaws.com' '' '/var/lib/mysql/' '/etc/my.cnf' '2479' 2>sst.err: 2 (No su
ch file or directory)

slave sst.err:
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Does xtrabackup still require special tar binary? If so, it probably should be a part of the package.

[Alexey Kopytov (akopytov)]

XtraBackup 2.0 does not require a special tar binary, but tar archives produces with --stream=tar still have to be extracted with the -i switch as previously, see http://www.percona.com/doc/percona-xtrabackup/innobackupex/streaming_backups_innobackupex.html

I don't see what happened from the log. The record before the "This does not look like a tar archive" error says something had failed with errno 2. Could it be the culprit?

I'd like to see the xtrabackup command line to investigate this further.

[Alex Yurchenko (ayurchen)]

errno 2 is not a culprit, it is just an error propagation: wsrep_sst_xtrabackup script didn't create a magic file - because it failed previously due to tar error.

donor command line:
innobackupex --galera-info --tmpdir=/tmp --stream=tar /tmp 2>/var/lib/mysql/innobackup.backup.log | nc ec2-50-18-2-242.us-west-1.compute.amazonaws.com 4444

joiner command line:
nc -dl 4444 | tar xfi - -C /var/lib/mysql/

Looking into /var/lib/mysql/innobackup.backup.log reveals:
>>>>>>>>>>>>>>>>>>>
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

120407 10:40:00 innobackupex: Starting mysql with options: --unbuffered --
120407 10:40:00 innobackupex: Connected to database with mysql child process (pid=21850)
120407 10:40:06 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!".

innobackupex: Using mysql Ver 14.14 Distrib 5.5.21, for Linux (x86_64) using readline 5.1
innobackupex: Using mysql server version Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

xtrabackup: Error: Please set parameter 'datadir'
innobackupex: fatal error: no 'mysqld' group in MySQL options
innobackupex: fatal error: OR no 'datadir' option in group 'mysqld' in MySQL options
<<<<<<<<<<<<<<<<<

However innobackupex does not seem to have a datadir option, so it has to be set in my.cnf for it to work. This may seem as a user configuration error, however MySQL does not require setting datadir variable in my.cnf to run. In other words, valid my.cnf should not break innobackupex.

[Alexey Kopytov (akopytov)]

Thanks. So the problem was in the missing datadir option. In which case it's a duplicate of bug #934934.