| 2011-12-30 20:37:28 |
Charles Capps |
bug |
|
|
added bug |
| 2011-12-30 20:38:33 |
Charles Capps |
description |
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 extrabackup 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 $ibbackup_binary to 'xtrabackup', which will work correctly for my specific installation. This may be the safest bet, in addition to adding a check before returning to ensure that *something* was selected, along with an appropriate error if not.
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 |
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 extrabackup 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, in addition to adding a check before returning to ensure that *something* was selected, along with an appropriate error if not.
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 |
|
| 2011-12-30 23:17:23 |
Charles Capps |
description |
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 extrabackup 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, in addition to adding a check before returning to ensure that *something* was selected, along with an appropriate error if not.
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 |
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 |
|
| 2011-12-30 23:27:21 |
Valentine Gostev |
percona-xtrabackup: assignee |
|
Valentine Gostev (longbow) |
|
| 2011-12-30 23:27:24 |
Valentine Gostev |
percona-xtrabackup: importance |
Undecided |
Medium |
|
| 2012-01-16 17:36:55 |
Alexey Kopytov |
percona-xtrabackup: status |
New |
Confirmed |
|
| 2012-01-18 08:03:21 |
Sergei Glushchenko |
percona-xtrabackup: assignee |
Valentine Gostev (longbow) |
Sergei Glushchenko (sergei.glushchenko) |
|
| 2012-01-21 09:47:05 |
Sergei Glushchenko |
branch linked |
|
lp:~sergei.glushchenko/percona-xtrabackup/bug910206_InnoDB_version |
|
| 2012-01-21 09:50:31 |
Sergei Glushchenko |
branch linked |
|
lp:~sergei.glushchenko/percona-xtrabackup/bug910206_InnoDB_version-1.6 |
|
| 2012-01-21 09:57:01 |
Sergei Glushchenko |
percona-xtrabackup: status |
Confirmed |
Fix Committed |
|
| 2012-01-23 12:43:42 |
Alexey Kopytov |
nominated for series |
|
percona-xtrabackup/1.6 |
|
| 2012-01-23 12:43:42 |
Alexey Kopytov |
bug task added |
|
percona-xtrabackup/1.6 |
|
| 2012-01-23 12:43:42 |
Alexey Kopytov |
nominated for series |
|
percona-xtrabackup/2.0 |
|
| 2012-01-23 12:43:42 |
Alexey Kopytov |
bug task added |
|
percona-xtrabackup/2.0 |
|
| 2012-01-23 12:43:59 |
Alexey Kopytov |
percona-xtrabackup/1.6: assignee |
|
Sergei Glushchenko (sergei.glushchenko) |
|
| 2012-01-23 12:44:01 |
Alexey Kopytov |
percona-xtrabackup/1.6: milestone |
|
1.6.5 |
|
| 2012-01-23 12:44:08 |
Alexey Kopytov |
percona-xtrabackup/2.0: milestone |
|
1.9.1 |
|
| 2012-01-23 12:44:18 |
Alexey Kopytov |
percona-xtrabackup/1.6: status |
New |
Triaged |
|
| 2012-01-23 12:44:22 |
Alexey Kopytov |
percona-xtrabackup/1.6: importance |
Undecided |
Medium |
|
| 2012-01-23 12:44:38 |
Alexey Kopytov |
percona-xtrabackup/1.6: status |
Triaged |
Fix Committed |
|
| 2012-01-23 14:19:44 |
Alexey Kopytov |
percona-xtrabackup/2.0: milestone |
1.9.1 |
1.9.0 |
|
| 2012-01-23 14:20:03 |
Alexey Kopytov |
percona-xtrabackup/2.0: milestone |
1.9.0 |
1.9.1 |
|
| 2012-01-26 05:27:40 |
Sergei Glushchenko |
branch unlinked |
lp:~sergei.glushchenko/percona-xtrabackup/bug910206_InnoDB_version |
|
|
| 2012-01-30 05:57:49 |
Stewart Smith |
percona-xtrabackup/1.6: status |
Fix Committed |
Fix Released |
|
| 2012-01-30 13:10:10 |
Alexey Kopytov |
percona-xtrabackup/2.0: status |
Fix Committed |
Fix Released |
|
