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.

An important part of benchmarking is to draw graphs. A graph can reveal results you wouldn't have spotted just by looking at raw numbers. By the way, the process of massaging the raw numbers into graphs will often reveal things too.

Sysbench output tends to be quite wordy, especially when you have a script that runs 1, 2, 4, 8... threads with the same test. To manually copy paste the numbers into a spreadsheet is tiresome. So I came up with this monster shell one-liner to condense the output into a csv file. I'm posting it here so I will find it the next time I need it:

A while ago Baron blogged about his utter dislike for MMM, a framework supposedly used as a MySQL high-availability solution. While I have no personal experience with this framework, reading the comments to that blog I'm indeed convinced that Baron is right. For one thing, it includes the creator of MMM agreeing.

Baron's post still suggests - and having spoken with him I know that's what he has in mind - that a better solution could be built, it's just MMM that has a poor design. I'm going to go further than that: Personally, I've come to think that this family of so called clustering suites is just categorically the wrong approach to database high-availability. I will now explain why they fail, and what the right way is instead.

Last week Monty Taylor wrote an interesting blog post Oracle do not, in fact, comprise the total set of MySQL Experts where he protested against the title of Oracle's new podcast series Meet The MySQL Experts. Now, when I say "interesting" I'm not really referring to the factual argument he is making...

What was interesting about this was to see Monty burst out like that and express some true human feelings. Through all the controversies we've seen around MySQL, the Drizzle team has made a point of staying out of such discussions and just working on cleaning up their code and adding cool new stuff (added as plugins, of course). And if anything, I would have expected it to be someone like Stewart to finally break and start ranting about something, if it were to happen...

Just to be clear: I do not actually agree with Monty on the factual topic he is raising. We are of course all very geeky and arguing about English grammar is a good way to relax, but as far as I'm concerned it is quite common for titles of podcasts and such to be shortened versions of the full, grammatically correct sentence whose meaning the are conveying. After all, it would be silly to have a podcast called "Meet the MySQL experts who work in Oracle's R&D department, but excluding those experts that do work at Oracle's support or consulting organizations, even if they are great minds too, and also excluding anyone not working for Oracle at all."

For Finnish or Northern European readers of this blog, I just wanted to advertise that there is a great MySQL training coming up in Helsinki on the 3rd week of August. The trainer will be Oli Sennhauser from Switzerland. Oli is a former collague of mine from MySQL AB and is now an independent MySQL consultant - one of the best in Europe! The curriculum is targeted at developers (more dev than ops) that are already familiar with using MySQL, and will help you get a deeper understanding of InnoDB internals, high availability, caching and other advanced topics.

You can check it out or register at the Citrus website.

I've been following the Galera project for years now, but this week I finally had some time to spend hands on time on it. I'm sure you noticed Vadim from Percona is also looking at it, it will be interesting to compare results. In this post I will just share the experience of installing and configuring Galera.

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.

Mythbusters: How to configure InnoDB buffer poll on large MySQL servers

Yesterday I wrote about the dangers in using top on systems with 100+ GB of RAM, not to mention future systems with 1+ TB. A related topic is, how should I configure MySQL on such a large system?

There is a classic rule of thumb that on a dedicated MySQL server one should allocate 80% of memory to the InnoDB buffer pool. On a 128GB system that is 102.4 GB. This means that I would leave 25.6 GB of RAM "unused". So surely on these large systems, this old piece of advice cannot hold anymore. If the database was previously running on a server that in total had less than that altogether, it seems wrong to leave so much memory just unused. Let's label the old rule of thumb tentatively a "myth" and ask mythbusters to figure out a new MySQL configuration for us...

We all know that a megabyte in binary system is not the same as one million bytes (in decimal system). But have you actually cared much about it? I have to admit I haven't. I know there is a small rounding error, but by and large I always treated 2^10 = 1 kB = 1024 bytes and 10^3 = 1 kB = 1000 as the same thing. (Update: Opening sentence was edited to remove units MB and MiB since it seems even I managed to use them backwards! The math in this article is correct. The rest of the article uses MB, GB and TB mostly to refer to binary magnitudes, which is apparently incorrect. See comments for wikipedia links and discussion.)

More importantly, when you move into larger numbers, rounding errors usually become even less important. Unfortunately, in this case they become bigger:

A week ago Baron wrote a blog post which can only be described as the final nail in the coffin for MMM. At MySQL AB we never used or recommended MMM as a High Availability solution. I never really asked about details about that, but surely one reason was that it is based on using the MySQL replication. At MySQL/Sun we recommended against asynchronous replication as a HA solution so that was the end of it as far as MMM was concerned. Instead we recommended DRBD, shared disk or MySQL Cluster based solutions. Of course, to replicate across continents (geographical redundancy) you will mostly just use asynchronous replication, also MySQL Cluster used the standard MySQL replication for that purpose.