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

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?

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!

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

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.

Looks like a reasonable use case to me.

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?

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

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.

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...

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