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

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

Vincent Bernat <bernat@debian.org> writes:
>  ❦  2 juillet 2013 09:20 CEST, Paul Wise <pabs@debian.org> :
>>> 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)
>> An alternative to including the MySQL InnoDB code might be to
>> build-depend on mysql-source-5.5, unpack and patch it during the build
>> process and add Built-Using: mysql-5.5 (= $version) to the resulting
>> binary package.
> The problem is that it should Build-Depends on Percona MySQL which is
> not yet available in Debian. I think the first step would be to provide
> Percona MySQL packages. Currently, it seems that there is no easy way to
> provide packages as alternative to MySQL but maybe work has already
> started with MariaDB.

It would need to build-depend on specific MySQL and Percona Server
versions (which end up being on-disk compatible with various MariaDB

We're working on getting Percona Server ready to be included too, but
we'd be going for the current Percona Server versions not the ones we
patch heavily to then build XtraBackup with.

But, the main problem is that we need to patch the InnoDB source to build
XtraBackup and the patch isn't trivial to port to the latest versions
(and there's usually no benefit in doing so).

It's better to think of XtraBackup patching and including the parts of
InnoDB it needs and for reasons that are largely historical it's
multiple binaries for multiple versions of InnoDB.

Our short/medium term goal is to stop doing this and actually just have
one set of InnoDB code from the most recent MySQL/Percona Server version
and one XtraBackup binary that works on all server versions.

In an ideal world there'd be some library we could link against and have
the patches be accepted upstream.. but we're not in an ideal world. This
would make it more like something like xfsprogs which does end up
including some of the same code as the kernel (although we patch InnoDB
while xfsprogs seems to be about at the point where that isn't

So while we do understand how it'd be great to build against the source
in mysql-source-5.5, it's just not really feasible to do so and maintain
quality and maintainability. We're hoping that our short/medium term of
just including the patched InnoDB bits we need in our source tree to
mostly solve the problem.

I hope this helps clarify.

Stewart Smith

Attachment: pgpLqfCj3qbb6.pgp
Description: PGP signature

Reply to: