innobackupex InnoDB version detection fails using Percona-supplied RPM versions

[Charles Capps]

Using:

Percona-Server-client-51-5.1.60-rel13.1.413.rhel5
Percona-Server-shared-51-5.1.60-rel13.1.413.rhel5
Percona-Server-server-51-5.1.60-rel13.1.413.rhel5
xtrabackup-1.6.4-314.rhel5

In sub set_xtrabackup_version, MySQL is asked for the running version and innodb_version variables. A set of regexes then compare the expected version numbers to select an xtrabackup binary to run.

When using the RPMs listed, the MySQL version is "5.1.60-rel13.1-log" and the InnoDB version is "1.0.17-rel13.1".

For 5.1, there are three possible regexes:

$var_innodb_version =~ m//
$var_innodb_version =~ m/1\.0\.\d+$/
$var_innodb_version =~ m/1\.0\.\d+-\d/

"1.0.17-rel13.1" does not match the later two, but I'm not entirely sure why it's failing the first, which should match anything.

I corrected my local copy by simply setting the initial value of $ibbackup_binary to 'xtrabackup', which will work correctly for my specific installation. This may be the safest bet. Otherwise, adding a check before returning to ensure that *something* was selected along with an appropriate error if not would be a good idea.

Irritatingly, this problem manifested itself with a misleading error message:

innobackupex: fatal error: no 'mysqld' group in MySQL options
innobackupex: fatal error: OR no 'datadir' option in group 'mysqld' in MySQL options

[Patrick Crews (patrick-crews)]

For whatever reason, I seem to be seeing this as well while trying to port the test for bug810269
I have xtrabackup_55 in my PATH, but the innobackupex script seems to be searching for xtrabackup:
Doing some additional troubleshooting to see if this is me (or my repo is old), but it looks similar, so wanted to share info.

qp-xtrabackup/Percona-Server-5.5/storage/innobase/xtrabackup:qp-xtrabackup/libtar-1.2.11/libtar:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
20111230-183007 xtrabackup_main.bug817132_test [ fail ] 36188
20111230-183007 --copy-back without explicit --ibbackup specification defaults to 'xtrabackup'. ... FAIL
20111230-183007
20111230-183007 ======================================================================
20111230-183007 FAIL: --copy-back without explicit --ibbackup specification defaults to 'xtrabackup'.
20111230-183007 ----------------------------------------------------------------------
20111230-183007 Traceback (most recent call last):
20111230-183007 File "qp-xtrabackup/kewpie/percona_tests/xtrabackup_main/bug817132_test.py", line 115, in test_bug817132
20111230-183007 self.assertEqual(retcode,0, output)
20111230-183007 AssertionError:
20111230-183007 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
20111230-183007 and Percona Inc 2009-2011. All Rights Reserved.
20111230-183007
20111230-183007 This software is published under
20111230-183007 the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
20111230-183007
20111230-183007 IMPORTANT: Please check that the copy-back run completes successfully.
20111230-183007 At the end of a successful copy-back run innobackupex
20111230-183007 prints "completed OK!".
20111230-183007
20111230-183007 sh: xtrabackup: not found
20111230-183007 innobackupex: fatal error: no 'mysqld' group in MySQL options
20111230-183007 innobackupex: fatal error: OR no 'datadir' option in group 'mysqld' in MySQL options
20111230-183007
20111230-183007
20111230-183007 ----------------------------------------------------------------------
20111230-183007 Ran 1 test in 36.188s

[Art van Scheppingen (4-a0t-5)]

We are also affected by this bug.
We are currently in progress of updating our servers to 5.1.60 and only on the 5.1.60 machines we see this happen.
Some (experimental) machines are upgraded to 5.5.18 and do not suffer from this problem.

The correct regex chould be fixed by adding the optional "rel":
$var_innodb_version =~ m/1\.0\.\d+-(rel)?\d/

For now we just added the innobackupex option --ibbackup to to our wrapper scripts.

[Alexey Kopytov (akopytov)]

The reason is an unintentional change in the innodb_version format in 5.1.60, see the server bug #917246.

We have to implement a workaround in XtraBackup though, by updating the regexps used to detect XtraDB 5.1.

[Barry Leung (bleung)]

Hi,
How do I obtain this fix? I am having the same issue. But when I do a yum update Percona-Server-server-51.x86_64, it tells me no packages are marked for update.

[root@dev06 ~]# yum list | grep Percona
Percona-Server-client-51.x86_64 5.1.60-rel13.1.413.rhel5 installed
Percona-Server-devel-51.x86_64 5.1.60-rel13.1.413.rhel5 installed
Percona-Server-server-51.x86_64 5.1.60-rel13.1.413.rhel5 installed
Percona-Server-shared-compat.x86_64 5.5.20-rel24.1.217.rhel5 installed

Thank you,
barry

[Stewart Smith (stewart)]

The "Fix Released" bug status just means that we've merged the fix into our software repositories, not that a binary release with those fixes has gone out. Sorry for any confusion this causes (the statuses are not ideal, I know).

Percona Server 5.1.61-13.2 should be out in the next 24hrs, xtrabackup 1.6.5 will closely follow.

[Shahriyar Rzayev (rzayev-sehriyar)]

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