[debian-mysql] percona vs. mariadb

[Clint Byrum]

Excerpts from micah anderson's message of 2013-03-06 18:26:44 -0800:
> 
> Hi everyone,
> 
> It seems everywhere I turn, people are wanting to replace MySQL in
> Debian with MariaDB. I share the reasons and motivation behind doing
> that, I have been very unhappy with what has happened and is happening
> with MySQL (the recent security upgrades were really unfortunte too).
> 

I share your concern. Its a crying shame what Oracle's ridiculous
non-disclosure policies have done to our ability to ship a working,
stable MySQL to Debian users.

> However, I'm struggling to understand why MariaDB, and not Percona
> Server (also a drop-in replacement for MySQL, and they even have debian
> packages made). From my evaluation today, Percona Server seems like a
> big win and I'd like to hear what the pkg-mysql team thinks about this:
> 

Percona Server is basically MySQL++. MariaDB maintains its own tree, so
the reason I would favor Maria over MySQL is that Percona Server is going
to be following Oracle, while MariaDB has already decided to diverge and
will thus be more immune to the weirdness of the closed MySQL model.

Thats not to say PS isn't amazing. It is. And they have great engineers
at Percona working on it. It *should* be in Debian. But its not really
much of an improvement over MySQL.

> 1. sustainability: MariaDB seems to be a one man hero effort by Monty,
> hoping to get people to rally around him. Not necessarily bad because he
> is trying to fix the MySQL situation, but it seems problematic to do
> that when Percona exists and seems to have what appears to be a solid
> base of people working on it, people who really know their stuff.
> 

Your perception is really quite off. MontyProgram is not just Monty, and
SkySQL is also selling services and customizing MariaDB for its customers.

Note that sometimes Percona Server pulls in patches from MariaDB:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698068
http://www.mysqlperformanceblog.com/2013/01/13/cve-2012-4414-in-mysql-5-5-29-and-percona-server-5-5-29/

> 2. security: last time there were a series of MySQL security issues, I
> looked at MariaDB and it hadn't been updated to fix those after a long
> time, due to its slow release cycle, that was disappointing and scary
> and might be related to #1
> 

You're missing something here. MariaDB has been beating Oracle to the
punch on releasing security fixes. I think. I say "I think" because
sometimes I don't have time to look at the code of MySQL to see if the
issue is addressed, and I have to wait *weeks* to find out if the last
release has fixed the CVE's that are open. Meanwhile MariaDB releases
a security fix whenever it is ready, and actually tells us, on that
day, that it is fixed. Percona Server has often been updated in similar
fashion, and I suspect that often MariaDB and PS developers collaborate
on this.

> 3. stability: MariaDB is MySQL with a couple yeeehaw storage engines
> added on top of it... that scares me a little because it adds weird
> untested code paths, it also removes storage engines
> 

I have to agree here. I worry about the optimizer stuff in MariaDB too.

> 4. performance: percona looks like a highly tuned mysql plus awesome
> sauce and all the big orgs that are wanting to scale move to it, so it
> is either 'webscale' hand waving or actually good. Every time I look
> around for performance tuning stuff in MySQL, I'm always seeing the
> largest amount of good signal coming out of the Percona arena. If you
> look at the Percona comparison chart[0] you will see a number of
> different things that it has that look really interesting, as does the
> benchmarks[1] (which of course are going to favor them, so grain of salt
> and all that). I particularly like the SSD optimizations they've
> done[2].
> 

This is really just a reason to have it available, not to have it be a
replacement.

> 5. multi-master clustering: mariadb is working towards getting galera
> integrated, but it is still beta, where percona has had it integrated
> for a while and people use it. This means adding the xtradb storage
> engine, which I am arguing against above in #3, but from what I can tell
> xtradb is just InnoDB with some nice row-level replication features
> added and Percona decided to add that after evaluating it, leaving the
> other storage engine toys for other people to mess around with
>

Its not integrated into Percona Server, it is in Percona's XtraDB cluster
product. So that would be yet another flavor to have in the archive.

> 6. tested: just have a look at who in the industry has already switched
> to percona[2], an impressive list!

I think that people will switch to things that work for their narrow
case and we should not stand in their way. But Debian is really offering
people a vetted (license wise) stable platform, that may not be in line
with what those in the industry are doing.

There's also the issue that Debian is largely volunteer maintained. I no
longer work for Canonical and my day job doesn't really have cycles in
it for MySQL maintenance. So dealing with Oracle's tight lipped policy
and lack of patches/bug trackers means I have to spend more time on
MySQL than I really have. The others on the team are also taxed. So if
there is a solution out there that will be more responsive to a Debian
maintainer's needs, then thats the one I'd choose, even if it meant loss
of performance or capabilities.