Latest release fails backup with --slave-info if instance is not a slave

[Phil Hildebrand]

The most recent release of Xtrabackup in the debian apt-get repository includes a version of innobackupex that fails with the --slave-info option if the instance being backed up is not currently a slave.

Old version info:

# xtrabackup --version
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: undefined)

# innobackupex --version
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Ireland Ltd 2009-2012. All Rights Reserved.

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

New version info:

# xtrabackup --version
xtrabackup version 2.1.1 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 600)
# innobackupex --version
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Ireland Ltd 2009-2012. All Rights Reserved.

We use a standard script for backups for both slaves and stand alones, as previously the innobackupex would still complete the backup without change master info if the instance was not a slave, but this new build fails.

Previously, the xtrabackup would complete successfully and contain an blank entry for slave_info:

# ls 2013-05-16/
backup-my.cnf ibdata1 ib_logfile1 mysql xtrabackup_binary xtrabackup_binlog_pos_innodb xtrabackup_logfile
getmoz_prod ib_logfile0 mkheartbeat performance_schema xtrabackup_binlog_info xtrabackup_checkpoints xtrabackup_slave_info

# cat xtrabackup_slave_info
CHANGE MASTER TO MASTER_LOG_FILE='', MASTER_LOG_POS=

The new version appears to fail:

root@dalranddb01a:/backup/dalranddb01a# ls 2013-05-15/
backup-my.cnf heartbeat ibdata1 xtrabackup_binlog_info xtrabackup_logfile xtrabackup_suspended_2

Output from failure:

----------

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Ireland Ltd 2009-2012. All Rights Reserved.

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

130515 18:38:52 innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' (using password: NO).
130515 18:38:52 innobackupex: Connected to MySQL server
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

innobackupex: Using mysql server version 5.5.30-30.2-log

innobackupex: Created backup directory /backup/dalranddb01a/2013-05-15

130515 18:38:52 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/backup/dalranddb01a/2013-05-15 --tmpdir=/tmp
innobackupex: Waiting for ibbackup (pid=23114) to suspend
innobackupex: Suspend file '/backup/dalranddb01a/2013-05-15/xtrabackup_suspended_2'

xtrabackup_55 version 2.1.1 for Percona Server 5.5.16 Linux (x86_64) (revision id: 600)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /data/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 1073741824
xtrabackup: using O_DIRECT
130515 18:38:52 InnoDB: Warning: allocated tablespace 10, old maximum was 9
>> log scanned up to (2123034)
[01] Copying ./ibdata1 to /backup/dalranddb01a/2013-05-15/ibdata1
[01] ...done
[01] Copying ./heartbeat/heartbeat.ibd to /backup/dalranddb01a/2013-05-15/heartbeat/heartbeat.ibd
[01] ...done
>> log scanned up to (2123509)

130515 18:38:54 innobackupex: Continuing after ibbackup has suspended
130515 18:38:54 innobackupex: Starting to lock all tables...
130515 18:38:54 innobackupex: All tables locked and flushed to disk
innobackupex: Error: Failed to get master binlog coordinates from SHOW SLAVE STATUS at /usr/bin/innobackupex line 387.
2013-05-15 18:38:54 [!] Backup failed.

----------

[Alexey Kopytov (akopytov)]

Right, it's a regression introduced by the patch for https://blueprints.launchpad.net/percona-xtrabackup/+spec/use-dbd-mysql-in-innobackupex.

The workaround is to not use --slave-info on servers that are not replication slaves. Thanks for the report.

[Shahriyar Rzayev (rzayev-sehriyar)]

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