[debian-mysql] percona vs. mariadb

[Otto Kekäläinen]

Hello,

2013/3/7 Bjoern Boschman <bjoern at boschman.de>:
>> We should just ship the same major.minor release of all of them if
>> they're going to share /etc/mysql/my.cnf.
>>
>> I'd prefer, though, that they didn't if at all possible. If they must,
>> this probably means having them conflict and provide so that incompatible
>> options don't cause issues.
>>
>
> I totally aggree that different sql-server branches must not share those
> data!

At least at the moment when MariaDB and MySQL are binary-compatible,
they should share the same data. That makes it easy for admins to
switch servers. Compare the situation to packages nginx-light and
nginx-full: same conf files, but different binaries and conflicts each
other, so both binaries can't be installed at once.

At some point in the future, if they really diverge from each other,
they could adapt separate configs (compare how httd providers Apache
and Nginx are packaged in Debian). But I think these kind of diverges
are initiated in the upstream project, and not designed nor maintained
by downstream packagers.

Now to the question, how many MySQL variants could Debian ship? I
don't know, but I assume that Debian should at least have MySQL plus
some other that users can migrate to in case Oracle goes evil. More is
of course better, but only it there are resources.

Well if there are resources for only one new option? Which one should
the other be, MariaDB, Percona or something else? Logically the one
which has most packaging resources and maintainers backing it should
be selected. At the moment I am trying to package MariaDB (I'll post
another message on that later) and I noticed that Kristian Nielsen,
who is a MariaDB developer, has at least subscribed to this list and
talked on the debian-mysql IRC channel, so there is a direct
connection to the upstream project. I found Kristian's e-mail while
looking in the MariaDB repos on who commited their debian/ and when I
needed some help understanding the compile options etc, Kristian was
kind to respond and he has contributed to my packaging effort. The
packaging done at MariaDB was a bit outdated, not using quilt, stuck
in debhelper version 1 etc but now when I've helped catch up to modern
standards there is no reason why upstream MariaDB wouldn't be
interested in staying up-to-date in regards to Debian packaging.

Is MariaDB technically the superior option? I don't know. Personally I
have only experience of plain MySQL and plain MariaDB. I might try the
MariaDB cluster in a project later this year, but I don't have any
experience of e.g. Percona at all, so I am not qualified to say much
about it, but a quick googling shows mixed benchmark results.

Because of my background I have more to say in regards to Free
Software project management. And in regards to that, at least MariaDB
seems to be commited to Software Freedom and it has the capacity to
diverge from MySQL if Oracle would in future behave even less freedom
loving than what it has shown so far. As I understood (might be wrong)
Percona does not have the momentum to fork off MySQL if needed.

Also, looking at what Fedora and OpenSUSE is doing[1], they both
included MariaDB in their repos. I think the general trend is from
MySQL to MariaDB with Wikipedia[2] an all, and following it would be
the safest option and likely to guarantee that there will be
MariaDB-knowledgeable people around to help with maintaining the
packages.

So I suggest we keep MySQL for at least one cycle and include MariaDB
ASAP, so that both will be available and users can vote themselves
running either "apt-get install mysql-server" or "apt-get install
mariadb-server".

[1]
http://michal.hrusecky.net/2013/01/mysql-mariadb-and-opensuse-12-3/
http://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB

[2] http://www.zdnet.com/wikipedia-moving-from-mysql-to-mariadb-7000008912/


-- 
Otto Kekäläinen                   []         otto at fsfe.org
Finnish Team Coordinator        [][][]  finland at fsfe.org
Free Software Foundation Europe   ||      +358 44 566 2204
Support FSFE! http://fsfe.org/support?otto