Good news to all of you who are going or were thinking of going to the Percona Live MySQL Conference and Expo. Yesterday two great addon events were announced, both happening on Friday April 13th, right after the main conference:

Drizzle Day 2012

Usually people do this around New Year, I will do it in February. Actually, I was inspired to do this after reviewing all the talks for this year's MySQL Conference - what a snapshot into the state of where we are! It made me realize we've made important progress in the past year, worth taking a moment to celebrate it. So here we go...

Diversification

In the past few years there was a lot of fear and doubt about MySQL due to Oracle taking over the ownership. But if you ask me, I was more worried for MySQL because of MySQL itself. I've often said that if MySQL had been a healthy open source project - like the other 3 components in the LAMP stack - then most of the NoSQL technologies we've seen come about would never have been started as their own projects, because it would have been more natural to build those needs on top of MySQL. You could have had a key-value store (HandlerSocket, Memcache API...), sharding (Spider) and clustering (Galera). You could have had a graph storage engine (OQGraph engine isn't quite it, I understand it is internally an InnoDB table still?). There could even have been MapReduce functionality, although I do think the Hadoop ecosystem targets problems that actually are better solved without MySQL.

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: https://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: https://www.mysqlperformanceblog.com/2012/01/09/announcement-of-percona…

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.