[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ITP: Percona XtraBackup - hot backup utility for MySQL



Hi!

I'm Stewart and I work for Percona. One of the things I'm currently
working on is ensuring all our free and open source software projects
are packaged for all the major linux distributions - including my
beloved Debian.

We're wanting to have Percona XtraBackup be part of Debian. Percona
XtraBackup is an online backup tool for MySQL, MariaDB, Percona Server
and Percona XtraDB Cluster. In the near future, we will also wanting our
packages for Percona Server and Percona XtraDB Cluster to be part of
Debian.

There is an open bug for Percona XtraBackup packaging:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824

We are going to make "upload release to Debian" be part of our release
process. We tend to make a new minor bugfix release (i.e. 2.1.x) every
2-3 months and a new major release every 12 (2.0 in April 2012, 2.1 in
May 2013). We want to be an active and involved upstream.

There have been a couple of issues with our source tarballs and build
procedure that I've had to fix up before proposing that Percona
XtraBackup be included. I've made changes on top of our 2.1.3 release
that mean we now generate source tarballs that do not require an
active internet connection to build.

I've put up source tarball and packaging for unstable up at:
http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/

All future releases will produce tarballs like this, so they'll be in a
more normal area of our downloads site - I'll also get one up in an
official place for the current 2.1.3 release.

I (and we, the rest of Percona) would really appreciate any
review/comments/suggestions on this packaging - we're really keen to
have Percona XtraBackup be in the Debian archives.

Why is the tarball so big and why did it require an internet connection?
Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
of InnoDB) to help it read InnoDB pages from disk and back them up
safely. It also uses part of the code to replay REDO logs to prepare a
backup before it can be restored. Due to various not-that-interesting
reasons (all of which we do consider bugs) we currently produce
different binaries for different MySQL versions (hence linking in code
From different MySQL versions).

It's important to note that we patch the InnoDB code inside MySQL to
make it usable by xtrabackup and that we cannot just use the MySQL code
already shipped in Debian for this without creating a nightmare for
the Debian MySQL packaging team, the security team and ourselves (it's
generally non-trivial to port this patch to new versions).

There should never be any security implications of linking against this
(not always up to date) MySQL code as we only use it to read (and write)
files to local disk.

Questions:

1) We have a transitional package called 'xtrabackup' that was (prior to
   2.0) the package name was in our own APT repositories. Does it make
   sense to keep this in the Debian packaging?

2) We have trademarks. We've tried to come up with a trademark policy
   that makes everybody happy (well, as happy as you can be when you're
   dealing with trademark law).
   It's at:
   http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
   We believe this should satisfy any requirements of Linux
   distributions, but if there's any concerns, don't hesitate to ask.

3) Supported architectures. We see x86-64, x86 and very, very rarely,
   SPARC. I'd say that both people running XtraBackup on a non-x86
   architecture are happy, but I'm pretty sure there's not even that
   many. While XtraBackup may compile (or even run) on other
   architectures, it currently makes approximately zero business sense
   for us to spend any time on it - although we're happy to take
   patches.

   Given this, how much "works and passes tests on all archs" is
   required to have packages accepted?

4) We plan on continuing to provide our own repositories as well and are
   wanting to not diverge in packaging from our repos and what's in
   Debian. Any tips/tricks are very welcome - we have "build debian
   packages" as part of or continuous integration efforts and plan to
   soon have "run the whole test suite on those packages" as part of it.


Thanks in advance for the feedback!
-- 
Stewart Smith

Attachment: pgphGOxr1eUaS.pgp
Description: PGP signature


Reply to: