Working around innobackupex and version nuance issue(s)?
Lachlan Mulcahy
I found an issue in the innobackupex-1.5.1 script which causes it to
ignore the given --ibbackup= parameter and just go ahead and
autodetect the xtrabackup binary to use.
I have had problems using xtrabackup_51 binary against Percona 5.0.77
server (which is what we are running in Prod) where there will be an
assertion during the --apply-log process.
At the suggestion of Vadim, I just used xtrabackup binary for both
backup and apply log and it seems to work OK so far.
The problem is that without the innobackupex script correctly
supporting usage of that parameter, this overriding cannot be done.
I am thinking the best way around this could be actually turned into
an XBM feature.
My suggestion is that we can ship xtrabackup binaries and innobackupex
script as a part of the project for now and when the backup runs, it
will automatically copy them to the machine to be backed up, using
scp, and then run the copied version directly.
The pros here could be:
#1 No need to install xtrabackup on every single machine you want to
back up
#2 No margin for error for the user in picking an xtrabackup version
that is compatible with XBM - it is possible they could pick a too old
or too new package that doesn't work quite right.
#3 It allows us developing the project a more "known engine" to work
with - there will always be nuances and things to work with and around
in each release, I guess.
What do you think?
Lachlan
Henrik Ingo
<lachlan...@gmail.com> wrote:
> Hi All - probably just Henrik for now :)
Hi :-)
This gets archived though...
Yes. I was just about to look into this issue tomorrow, ie what is the
most convenient way to do what needs to be done on the remote hosts
that are being backed up. My first feeling is that your approach is a
good one. Might be especially advantageous as both XBM and xtrabackup
are developed heavily.
Note that you now have issues with 32 bit vs 64 bit binaries that XBM
must correctly autodetect which ones to use. Of course, we might as a
first step try just using the 32 bit binary everywhere - ask Percona
guys if it's safe and if there is a performance hit.
This seems like a good place to list some other issues that one needs
to guard against, all related to running xtrabackup on the remote
host, with correct permissions, etc...
* we should default to using "mysql" user on the remote host, so that
we have same permissions as mysqld.
* mysql user often has no password set, no shell and no home
directory in /etc/passwd. We should probably have an install shell
script that makes sure all of these are ok.
* The install script then also should take care of the ssh key setup.
* Finally, when I wanted to create a home directory for mysql, I
managed to do something where the directory existed but wasn't owned
nor writable by the mysql user. Resulted in obscure errors...
henrik
--
henri...@avoinelama.fi
+358-40-5697354 skype: henrik.ingo irc: hingo
www.openlife.cc
My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559