The program for this year's MySQL conference is now published.

As regular readers will remember, I served on the program committee this year and was one of those who appealed for people to send in great proposals. I would now like to thank all of you that sent in proposals. On my quick count we had over 250 proposals, and if I look at my own ratings I'd say about 180 of them were really good, conference worthy talks (and this already excludes some pretty good talks). A related piece of trivia was that this might have been the first year ever that the deadline for the Call for Proposals wasn't extended, which possibly took some of you by surprise. We simply got so many good talks by the deadline, that there wasn't any need to.

In my previous post I explained why I believe the production of RPM and DEB packages should be more integrated with the rest of your development process. Now it's time to look into how you can put the RPM build scripts inside your main source code repository, and in particular how I did that to produce RPM packages for Drizzle.

Last weekend I released rpm files for the latest Drizzle Fremont beta (announcement). As part of that work I've also integrated the spec file and other files used by the rpmbuild into the main Drizzle bzr repository (but not yet merged into trunk). In this post I want to explain why I think this is a good thing, and in a follow up post I'll go into what I needed to do to make it work.

(And speaking of stuff you can download, phpMyAdmin 3.5.0-alpha1 now supports Drizzle!)

Hi again

It's time to announce the next Helsinki MySQL User Group which is on February 8 at 18:00. Venue is Solinor's meeting and sauna facilities in North Haaga: http://www.meetup.com/The-Helsinki-MySQL-User-Group/events/42163422/

By popular request, Monty will be sharing news about MariaDB, after which there is the usual food, beverages, sauna and socializing.

The organizers would really appreciate it if you could RSVP at the meetup request above. Last time the place was already packed and now with this kind of superstar speaker the hosts want to make sure they book an appropriate room and enough food. (Seems there's already 20+ going!)

See you there!

Just wanted to say I'm so happy: http://www.mysqlperformanceblog.com/2012/01/09/announcement-of-percona-x...

And also that this is a significant moment in the evolution of MySQL - things will never be the same again.

I've been promising I should re-visit once more the disk bound sysbench tests I ran on Galera. In December I finally had some lab time to do that. If you remember what troubled me then it was that in all my other Galera benchmarks performance with Galera was equal or much better compared to performance on a single MySQL node. (And this is very unusual wrt high availability solutions, usually they come with a performance penalty. This is why Galera is so great.) However, on the tests with a disk bound workload, there was performance degradation, and what was even more troubling was the performance seemed to decrease more when adding more write masters.

In these tests I was able to understand the performance decrease and it had nothing to do with Galera and not even InnoDB. It's a defect in my lab setup: all nodes kept their data on a partition mounted from an EMC SAN device - the same device for all nodes. Hence, when directing work to more nodes, and the workload is bottlenecked by disk access, naturally performance would decrease rather than increase. Unfortunately I don't currently have servers available (but will have sometime during this year) where I could re-run this same test with local disks.

As part of this lab session I also investigated the effect varying the number of Galera slave applier threads, which I will report on in the remainder of this post. Of course, the results are a bit obscure now due to the problematic lab setup wrt SAN, but I'll make some observations nevertheless.
While the previous tests were run on MySQL 5.1, this test was run on MySQL 5.5 and I will make some observations there too.

A year ago I posted a blog on The state of MySQL forks: co-operating without co-operating. (Also Giuseppe wrote about the topic at that time, and Peter Zaitsev covers it in his conference keynotes.) So I've been wondering if it would be good to write an update on the topic now, and in that case what to write.