I will be using this picture of the famous Korv Göran kebab grill in my talk at OSCON next week. They recently launched a new slogan "Bigger is better". I think they are on to something, at least when it comes to the kebab business.

Did you know that...

Nowadays you can buy small network attached boxes to function as small home-office disk servers so cheaply, that most of the time I take backups by having a couple of those lying around the house. But for many years I used to backup my personal Linux desktop by burning CD's and then DVD's.

The challenge with backing up to a CD/DVD is that you easily have more data to back up than fits on one disc. The TAR utility was created for tapes and completely lacks any capability of splitting itself into parts. What's more, with TAR you create the archive first, and then compress it, so it is not possible to know in the TAR phase when you've actually reached the size of your CD or DVD, and in the compression phase it is generally too late.

2 weeks from now I'm giving a talk How to Grow Your Open Source Project 10x and Revenues 5x at OSCON (in Portland, Oregon). It is based on the article with the same title I published last year. The talk is scheduled to end a one day sub-track called IT Leaders Summit. I'm glad it is categorized as a business talk rather than community talk - things I write usually are problematic in that I typically cover both business and community and see them mostly as harmonious topics, whereas most other people see them as opposites.

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: