innobackupex --safe-slave-backup hangs when used on master

[angel chen]

When I try to run innobackupex with --safe-slave-backup option, the process gets stuck on log scanned up to (.......) forever

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.

130613 12:14:02 innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'root' (using password: YES).
130613 12:14:02 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.31-30.3-log

innobackupex: Created backup directory /root/chafa2

130613 12:14:02 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/root/chafa2 --tmpdir=/tmp --compact
innobackupex: Waiting for ibbackup (pid=19307) to suspend
innobackupex: Suspend file '/root/chafa2/xtrabackup_suspended_2'

xtrabackup_55 version 2.1.3 for Percona Server 5.5.16 Linux (x86_64) (revision id: 608)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/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 = 5242880
>> log scanned up to (6548331)
[01] Copying ./ibdata1 to /root/chafa2/ibdata1
[01] ...done
>> log scanned up to (6548331)

130613 12:14:04 innobackupex: Continuing after ibbackup has suspended
Use of uninitialized value in pattern match (m//) at /usr/bin/innobackupex line 2867.
[centos@sqlmaster ~]$ >> log scanned up to (6548331)
>> log scanned up to (6548331)
>> log scanned up to (6548331)
>> log scanned up to (6548331)
>> log scanned up to (6548331)
>> log scanned up to (6548331)
>> log scanned up to (6548331)
...

[Alexey Kopytov (akopytov)]

Can you confirm that the server is not a replication slave?

If so, we should just swap check for Slave_SQL_Running and $host_is_slave in wait_for_safe_slave(). The workaround is to not use --safe-slave-backup on non-slave servers.

[Alexey Kopytov (akopytov)]

Please disregard the last question, the bug title mentions it is a master server.

[Shahriyar Rzayev (rzayev-sehriyar)]

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