What You Need to Know About the MariaDB & Percona Forks of MySQL

Sometimes it feels like you’re bound to hit MySQL eventually, regardless of where you dig on the Internet. It lies beneath the biggest sites, such as Lucent, Facebook, Drupal, WordPress, Google, Joomla and countless other major frameworks, and it’s so huge it has its own letter in the LAMP stack (Linux, Apache, MySQL, Perl or PHP or Python). From that standpoint, it comes as no surprise that this open source database has branched off into a series of specialized forks. The two most prominent are MariaDB and Percona.

This is a deeper look into how and why they come about, along with some advice on what to consider before diving into either fork Step one is nailing down a bit of a background on MySQL itself.

A Brief History of MySQL

In the early 1990’s, just as the World Wide Web was being introduced to the world, a network monitoring service named Minerva created an affordable, stripped-down version of SQL called MiniSQL or just mSQL. It wasn’t open source, but it was free for non-commercial use and sported a price tag in the hundreds for businesses. It appeared just as web standards were being cobbled together and mini-servers were taking off, so it became a backbone of the emerging web infrastructure.

A few years later, Allan Larsson, David Axmark and Michael “Monty” Widenius adapted mSQL into a more robust interface they named MySQL. The legend says it was named after Widenius’ daughter My.

When Sun bought MySQL in 2008, the development community became suspicious of the new owners and the forks began in earnest.

The Evolution of MariaDB

Widenius and Axmark left MySQL shortly after the buy out, and Widenius made very public criticisms of Sun and Oracle as acting contrary to the spirit of open source. Along with 20 of MySQL’s former top developers, he began a “Save MySQL” campaign.

Oracle bought Sun shortly afterward. For Widenius, that moment marked the birth of MariaDB (maintaining the theme by naming the product after another one of his daughters Maria), an open source alternative to MySQL that would be developed in concert with the community; it was meant to stay free perpetually under the GNU license.

The team was able to secure WikiMedia to make the switch to MariaDB in support of open source. As a result, MariaDB had added 10 million users by the end that year. To make switching easier for organizations of all sizes, MariaDB has been built to be a simple “drop-in” replacement for MySQL, coordinated to match MySQL’s APIs. For storage, it replaced the InnoDB engine with Aria and Percona’s XtraDB.

Percona Enters the Scene

Peter Zaitsev and Vadim Tkachenko introduced the open source Percona in 2006. The two had spent a great deal of time supporting MySQL and saw what the businesses really wanted from MySQL; they incorporated those aspects and made it more affordable, which is why some people consider Percona more of a branch of MySQL than a full fork like MariaDB.

Percona is perhaps best known for taking the InnoDB and retooling it into XtraDB, which lies at the root of Percona’s major code enhancements. In other aspects, Percona hews closer to the developments in MySQL than MariaDB, since its concerns are related to improving server performance. For example, Percona pulls in scalability, availability, security and backup features from the Enterprise version of MySQL.

A Few of the Other Forks

  • Drizzle: This open source fork originates from the abandoned MySQL 6.0, and is intended for the web infrastructure and cloud community. The main idea is that it uses a microkernel architecture, using plugins like query cache and authentication.
  • OurDelta: This fork was designed to enhance feedback cycles and bring MySQL code up to date with innovation on the web. OurDelta made it easier to test in more environments, although it no longer exists as a separate project as these enhancements were folded back into the MariaDB 5.1 release.
  • WebScaleSQL: This is another fork that some consider a branch of MySQL 5.6. It was built in 2014 in association with developers from Facebook, Google, LinkedIn and Twitter, and it was made to deal with some of the most common problems with massively replicated databases operating on server farms. WebScaleSQL’s goal was for the deduplication of efforts built independently by social media companies, and it is now saved on GitHub under the GNU license.

Percona or MariaDB: Which Is Better?

Of course, there’s no easy answer to that question. MariaDB (v. 10.1) and Percona Server (v. 5.6) are both production ready, and both can be dropped in fairly easily as a replacement to MySQL v. 5.7, which is the latest production-ready release.

Many companies won’t see a difference in performance unless there are specific capabilities they need or bottlenecks they want to overcome. Here are some reasons, other than the fact both are open source, why you might consider one over the other.

Five Reasons to Consider MariaDB

In addition to WikiMedia, companies supporting MariaDB include most Linux offshoots like Red Hat and SUSE; in 2013, Google announced it was joining those companies in moving its largest servers to MariaDB. Look at MariaDB if you:

  • Want to take advantage of an active international community of developers, not just those from Oracle.
  • Need to stay up to date with the latest developments in technology.
  • Have stakeholders that require immediate security patches.
  • Want to get started on upgrade features before they are released in MySQL.
  • Expect alternate storage engines to be built into the code, such as Connect and Cassandra for NoSQL backends, Spider with built-in  sharding or Percona’s TokuDB to deal with fractal indexes.

Five Reasons to Consider Percona

Percona estimates there are around 2 million installations, even at companies like Acquia, HP, Flickr, Etsy, Opera and Tumblr. Look at Percona if you:

  • Want queries to come back with results faster. Percona have released several benchmarks favourably comparing their XtraDB storage engine against InnoDB in vanilla MySQL.
  • Need to see better consistency in running a variety of very powerful servers.
  • Have plenty of I/O and large working sets that should be handled with no sharding.
  • Want to reduce maintenance time. Percona includes enhanced utilities for online backup and table import/export.
  • Tunability. Percona includes additional instrumentation within the MySQL internals to help with monitoring and tuning.

Concerns Before Switching

Your main concerns in making this type of commitment should be operational. Make a list of what information you’ll need to gather, beginning with:

  • Possible migration paths.
  • Key configuration tuning variables.
  • How to reload tables, if that becomes necessary.
  • Whether you need to reconfigure a stand-alone InnoDB server or use something like Percona’s XtraDB.
  • Any documentation on how your applications integrate with the new cluster.
  • What will be necessary to avoid downtime in the migration.
  • How the change can be accomplished gradually.

The MariaDB site notes three points to consider before you upgrade:

  • Views with definition ALGORITHM=MERGE or ALGORITHM=TEMPTABLE were accidentally swapped between MariaDB and MySQL. You will have to re-create views created with either of these definitions.
  • MariaDB has LGPL versions of the C connector and Java Client. If you are shipping an application that supports MariaDB or MySQL, you should consider using these.
  • Consider trying out the TokuDB storage engine or some of the other new storage engines that MariaDB provides.

You’ll find there are many considerations before installing Percona, based on the source of the code and whether you are installing over a recent version of MySQL or MariaDB. Note that Percona offers repositories for yum (RPM packages for Red Hat, CentOS and Amazon Linux AMI) as well as for apt (.deb packages for Ubuntu and Debian).

Final Thoughts

Remember that MariaDB was developed to add more features and to optimize queries; it offers scalability features including multi-source replication, allowing a single server to replicate from several sources. Be careful about planning out any complex replication schemas that bridge MySQL with other implementations. You will be able to replicate from MySQL v. 5.6 to MariaDB v.10, but not the other way around.

Percona has devoted more of its resources to improving the database and how it manages network interactions. Users come to Percona looking for enhanced availability in addition to high throughput and  scale. As Percona stays closer to current MySQL releases, it’s a more conservative option in terms of application compatibility; IT professionals looking for detailed diagnostics and performance metrics tend to prefer Percona.

For the TL,DR summary: MariaDB is better for advanced features, the latest security and adapting to new tech. Percona excels at database performance and diagnostics. Either one will put you in good company with cutting edge technology firms around the world.

Database Monitoring for MariaDB and Percona Server

Both MariaDB and Percona Server are forks of MySQL and strive to be drop in replacements for MySQL from a binary, api compatibility, and command line perspective.

It’s great to have an alternative to MySQL since you never know what might happen to it given that Oracle bought it for 1 billion dollars. In this blog post I set out to see if these MySQL forks would work 100% with AppDynamics for Databases. If you’re not familiar with the AppDynamics for Databases product I suggest you take a few minutes to read this other blog post.

The Setup

Getting both MariaDB and Percona Server installed onto test instances was pretty simple. I chose to use 2 Red Hat Enterprise Linux (RHEL) servers running on Amazon Web Services (AWS) for no particular reason other than they were quick and easy to get running. My first step was to make sure that MySQL was gone from my RHEL servers by running “yum remove mysql-server”.

Installing both MariaDB and Percona Server consisted of setting up yum repository files (documented here and here) and running the yum installation commands. This took care of getting the binaries installed so the rest of the process was related to starting and configuring the individual database servers.

The startup command for both MariaDB and Percona Server is “/etc/init.d/mysql start” so you can see that these products really do strive for direct drop in adherence to MySQL. As you can see in the screen grabs below I ended up running MariaDB 10.0.3 and Percona Server 5.5.31-30.3.

Screen Shot 2013-07-01 at 2.21.48 PM Screen Shot 2013-07-01 at 2.23.30 PM

Connected to each of these databases were 1 instance of WordPress and 1 instance of Drupal in a nearly “out of the box” configuration besides adding a couple of new posts to each CMS to help drive a small amount of load. I didn’t want to set up a load testing tool so I induced a high disk I/O load on each server by running the UNIX command “cat /dev/zero > /tmp/zerofile”. This command pumps the number 0 into that file as fast as it can basically crushing the disk. (Use Ctrl-C to kill this command before you fill up your disk.)

The Monitoring

Getting the monitoring set up was really easy. I used a test instance of AppDynamics for Databases to remotely monitor each database instance (yep, no agent install required). To initiate monitoring I opened up my AppDynamics for Databases console, navigated to the agent manager, clicked the “add agent” button, and filled in the fields as shown below (I selected MySQL as the database type):

Screen Shot 2013-07-01 at 3.39.47 PM

My remote agent didn’t connect the first time I tired this because I forgot to configure iptables to let my connection through even though I had set up my AWS firewall rules properly (facepalm). After getting iptables out of the way (I just turned it off since these were test instances) my database monitoring connections came to life and I was off and running.

The Result

Taking a look at all of the data pouring into AppDynamics for Databases I can see that it is 100% compatible with MariaDB and Percona Server. There are no errors being thrown and the data is everything that it should be.

The beauty of my induced disk I/O load was that just by clicking around the web interface of WordPress and Drupal I was getting slow response times. That always makes data more interesting to look at. So here are some screen grabs for each database type for you to check out…

MariaDB Activity

AppDynamics for Databases activity screen for the MariaDB database.

Percona Activity

AppDynamics for Databases activity screen for the Percona database.

MariaDB Explain Statement

Explain statement for a select statement in MariaDB.

Percona Explain Statement

Explain statement for a select statement in Percona.

MariaDB Statistics

A couple of statistics charts for MariaDB.

Percona Statistics

A couple of statistics charts for Percona.

If you’re currently running MySQL you might want to check out MariaDB and Percona Server. It’s possible that you might see some performance improvements since the storage engine for MariaDB and Percona is XtraDB as opposed to MySQL’s InnoDB. Having choices in technology is a great thing. Having a unified monitoring platform for your MySQL, MariaDB, Percona Server, Oracle, SQL Server, Sybase, IBM DB2, and PostgreSQL database is even better. Click here to get started with your free trial of AppDynamics for Databases today.