Many people have asked me what do I think was the best thing about Percona Live UK. I always answered: that it happened in the first place! This was the first time we had such a large and high-quality MySQL conference in Europe, and many well known bloggers and speakers that can't always travel to Santa Clara were present.

More importantly, many MySQL users who don't travel to Santa Clara could now see them speak and meet with them. I met at least 4 hard core MySQL DBA's from Helsinki that I've never met before. We had to travel to London to meet each other! (But if you are in Helsinki, we have our first MySQL user group tomorrow, this should fix things!)

When I walked into the conference venue, I introduced myself to a person that stood there talking to Baron Schwartz. He introduced himself as Schlomi Noach. Then we started laughing: we know each other quite well, Schlomi and I run the annual MySQL awards as co-secretaries. I never realized we had not met in person before!

The content of the program was very high quality. In the past few years I've come to value informal one-to-one discussions as my primary source of new information instead of the official lectures, but at this conference I actually chose to attend as many talks as possible and learned new information from many of them.

There are moments in history that become like signpost that everyone remembers the rest of their lives. Like where were you when you heard the news that JFK had been shot, or those 9/11 planes hit the WTC twin towers. If you work with MySQL and high-availability, then this week will be remembered as such. And if you're a European MySQL geek, you will remember that we were at the Percona Live UK conference when Galera clustering 1.0 was announced. Btw, the conference itself was also historical, at least for European MySQL users. I will have to write a separate blog post about the conference, because it was a great one, and I have to post slides of my 2 talks too. But this blog post is dedicated to the stable release of Galera.

The past few years of MySQL conferences...

Every year since Oracle's acquisition of MySQL in 2009, there's been some uncertainty around the annual MySQL conference, which used to be co-organized by MySQL AB (in charge of content) and O'Reilly (conference logistics). As my career unfolded during those years, I've seen relatively close how the conferences of 2010 and 2011 happened. As there's been a lot of re-structuring in the community around various forks and new employers, I've felt that the annual conference was the one thing that kept us together, the one common forum where everyone would meet. For this reason I have been personally very engaged (as have many others) in helping O'Reilly get through the conferences of 2010 and 2011 and I'm very grateful to Tim, Gina and the rest of the O'Reilly team that they have provided us with this forum and gravitation point for the past two years.

During this years conference it was openly speculated that it would be the last O'Reilly MySQL conference. EnterpriseDB being the main sponsor at a MySQL conference... kind of gave you a hint. With Oracle constantly boycotting and refusing to sponsor the conference of its own community, the business justification for O'Reilly to keep going just wasn't there anymore.

So once again we were facing uncertainty of what to do next year.

When we have been discussing alternatives for the next MySQL conference, I always maintained there are 3 things from which people recognize the MySQL conference: time, location and name. So I was encouraging people to come up with solutions that would maintain those 3 variables as constant as possible.

In December I covered the topic The state of MySQL forks: co-operating without co-operating (which was also a response to Giuseppe Maxia's take on the same topic). Since half a year has now passed, I was wondering if I should follow up with an update. (Drizzle having a GA release would be the major news in such an update.)

But I see that Peter Zaitsev covered this topic in the opening keynote of their Percona Live conference. Since I agree with Peter's view on this topic, I just recommend you watch the talk on Percona.TV. He also uses the same categorizations of the forks, and includes "community patches" as its separate slide.

Yesterday I wrote down the approach used in the MepSQL build system to parameterize the TAR package name produced. Today I will follow up with how the same was done for building DEBs. The motivation is to create a system that can be used flexibly to create packages of any MySQL fork, with any brand name: mepsql-server-*.deb, percona-server-server-*.deb, mariadb-server-*.deb or even just mysql-server-*.deb (which I might do some day).

While yesterday's tricks with the TAR files were rather straightforward, with the process of building DEBs this turns out to be much more challenging. But not to worry, like my former collague Bernhard Ocklin used to say: This is software, anything is of course possible.

As I mentioned before, it seems that thanks to Git and Bzr introducing distributed version control workflows, the open source community is now living in a phase where forking is easy and happens frequently - referred to by Brian Aker as the Cambrian Explosion of open source. We certainly see that happening in the MySQL Community.

Assuming you have the competence and know your way around a codebase, forking a proper open source project isn't that hard. You create your own project on GitHub or Launchpad and copy the source code. 1 But one thing you need to do is to change to using the new name (Drizzle, Percona, MariaDB, MepSQL....). Typically you want to keep using the original command line and file names (mysql, mysqld_safe, libmysql...), yet the product name as it appears in your installation packages is changed to distinguish it from the parent project.

In the life of an open source project a name change is a relatively rare occurrence. Most projects never fork or change their name. So it is not surprising that all the tools and methods we use while programming assume that the product name is a constant. It turns out it is hardwired into build scripts here and there. Sometimes excessively: when building DEB files the word "mysql" is used over a hundred different times!

• 1As noted in previous posts, if everything isn't fully open source, which is the case with MySQL, you have a challenge in reproducing from scratch the missing parts, like documentation, build system, etc...

Just wanted to highlight that Percona Server has now added HandlerSocket to its most recent release, being the first "MySQL fork/distribution" to ship it in easy to consume binary downloads.

HandlerSocket brings NoSQL to MySQL, and does so with a vengeance! It was developed at DeNa, by Akira Higuchi and is already used in production in their MySQL servers. The announcement on my former collague Yoshinori Matsunobu's blog flaunts a 7x performance improvement over the standard SQL interface in MySQL. The most astonishing part is that their MySQL is now faster than Memcached, even if the latter doesn't store anything to disk, so with this NoSQL-for-MySQL solution it makes sense to remove the caching layer completely!