Feature Request: Add --defaults-extra-file param to innobackupex

Bug #740489 reported by Mike Benshoof on 2011-03-22
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Wishlist
George Ormond Lorch III
2.0
Fix Released
Wishlist
George Ormond Lorch III
2.1
Fix Released
Wishlist
George Ormond Lorch III

Bug Description

This is a fairly simple feature that I have added to the innobackupex script to allow me to pass an extra client my.cnf file to the xtrabackup. Since xtrabackup accepts that param and can use it for the connection part of the dump process, it is much easier to keep a 700 copy of my admin user credentials and pass that rather than have to hard code the user/pass.

There may be another or a better way to accomplish this, just seemed logical and only took a few minutes to change.

Related branches

tags: added: fr

Mike,

What if you place credentials into the [xtrabackup] section of
$HOME/.my.cnf for the user who is running xtrabackup? Does that
accomplish the same thing?

Mike Benshoof (mbenshoof) wrote :

This method works for a dedicated box running a single mysql instance where the global config file is in a default place (which works for some of my installations) - thanks for the suggestion!

However, I'm moving to multiple instance setup where each instance has a unique configuration file. After some more testing, however, it appears that since I'm now being forced to pass the --defaults-file parameter for each instance, the defaults-extra-file option is pretty much irrelevant.

So it looks as if I'm going to have a watered down my.xtrabackup.cnf type file that has my datadirs, credentials, etc and I can restrict those permissions accordingly.

So with all that being said, I will most likely stop using the option moving forward. So aside from just having it available as it is available in underlying programs, I guess it really isn't needed.

Thanks for your time!

Changed in percona-xtrabackup:
importance: Undecided → Wishlist
Valentine Gostev (longbow) wrote :

We need use-cases to prove this feature might be useful. Right now --defaults-file is pretty enough.

Changed in percona-xtrabackup:
status: New → Won't Fix
Paul Graydon (twirrim) wrote :

Feel free to tell me I'm doing this wrong, if appropriate.

I have a username / password combination in a separate .my.cnf file, which only the backup user has access to, for the xtrabackup process to use for authentication rather than having it in a crontab or script somewhere on the system. I was hoping to use --defaults-extra-file to point at that file.

Alexey Kopytov (akopytov) wrote :

Looks like a reasonable use case to me.

Changed in percona-xtrabackup:
status: Won't Fix → Confirmed
Mike Benshoof (mbenshoof) wrote :

This is a similar use case to my original issue - the ability to not have to keep user/pass info in the core server config file.

Do you need an updated version of the patch or is there anything else that you need from me?

Alexey Kopytov (akopytov) wrote :

No, the patch looks good and is fairly noninvasive. Thanks for the contribution!

Stewart Smith (stewart) on 2012-02-07
Changed in percona-xtrabackup:
status: Confirmed → Triaged
tags: added: low-hanging-fruit
tags: added: contribution
Ryan Lowe (ryan-a-lowe) wrote :

Any chance of getting this included in the next release?

In trying to build out a test case for this I ran into the same issue that Mike Benshoof did, that is, --defaults-file and --defaults-extra-file can not be used together on the same command line for any mysql programs.

That means that this patch would only be useful where there are global config files in use in their default locations and would not satisfy the desire that Mike originally had (to be able to specify both a defaults file and an extra file) and also make the creation of a test suite case almost impossible.

Alexey Kopytov (akopytov) wrote :

OK, let's make --defaults-file and --defaults-extra-file mutually exclusive in innobackupex (and document it).

Regarding the test case, what if we change the way the default configuration file is defined by the test suite? I.e. instead of:

IB_ARGS="--defaults-file=${MYSQLD_VARDIR}/my.cnf --user=root \
--socket=${MYSQLD_SOCKET} --ibbackup=$XB_BIN"

do this:

export MYSQL_HOME=$MYSQLD_VARDIR
IB_ARGS="--user=root \
--socket=${MYSQLD_SOCKET} --ibbackup=$XB_BIN"

This should make creating a test case possible, and also fix bug #1072695.

That seems quite reasonable, and fixes two issues at once. I would have liked to offer a useful solution for our RDBA team that requested this in the first place but I think that would require changing core code to allow both defaults-file and defaults-extra-file to be used together. That seems like a very large can of worms to open...

Alexey Kopytov (akopytov) wrote :

I was considering a hack that would allow both --defaults-file and
--defaults-extra-file to be specified. Something along the following
lines in get_mysql_options() would allow both to be specified and solve
the problem for the mysql command line client:

if ($option_defaults_extra_file) {
  my $extra_options=`my_print_defaults -c $option_defaults_extra_file mysql client`;
  $extra_options =~ tr{\n}{ };
  $options .= $extra_options;
}

What I didn't like in this approach:

1. That would only work for specifying connection parameters for
innobackupex. The xtrabackup binary uses my_getopt() and thus, cannot
use both --defaults-file and --defaults-extra-file. Which also means
--defaults-extra-file would be a rather confusing option

2. Since we are going to get rid of innobackupex and merge it to the
xtrabackup binary, we would have to replicate the same hack
there. Knowing my_getopt, I agree it will be ugly and open a can of
worms.

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers