I'm looking at the schedule for Percona Live UK coming up in 2 weeks from now and realize there's quite a smorgasbord of High Availability talks. What's more interesting, I see that we will be presenting some opposite opinions for the audience to digest:

In July I attended the Community Leadership Summit in Portland. This was the 3rd CLS overall and my second. The first one was organized in San Jose 2 years ago. I noticed there has been a small evolution between those two years (which might partly be due to geography too). The first one in San Jose I think was very successful and drew many de-facto leaders in the open source community, including Bruce Perens himself (author of the Open Source Definition). In Portland there was perhaps less of those, but instead you could see how the audience increasingly consisted of people who actually work as full time Community Managers for various businesses, or in some cases for a non-profit organization.

Update: I won't be in Moscow after all. I was denied visa on grounds that my passport is beginning to fall apart and there wasn't time to get new passport, invitation and visa. Maybe next year - I was excited to go.

October brings 2 very interesting conferences. I will be speaking first on Oct 3rd at HighLoad++ in Moscow and a few weeks later on Oct Oct 25 at Percona Live in London. I will give a talk called Choosing a MySQL Replication / High Availability Solution which is based on my thinking developed in my recent blog post The ultimate MySQL high availability solution and many benchmarks and functional tests I've done while evaluating these technologies.

At Percona Live I will also give a second talk Fixed in Drizzle: No more GOTCHA's. It looked like none of the Drizzle core team would be able to attend the conference and as I was going to be there I volunteered to cover a Drizzle topic at the same time. This is a talk Stewart Smith has given a few times at earlier conferences which I liked and proposed to Percona. As it turns out, also Stewart will be in London after all, so there will be 2 Drizzle talks, I will still give the one I'm committed to.

In July I wrote a blog post MySQL community counseling: talking about your feelings. It was triggered by an earlier blog post and followup threads on Google plus by Monty Taylor, Andrew Hutchings, etc... (everyone involved in that outburst have apologized and moved on long ago). I wanted to use that opportunity to highlight what I call our hidden trauma related to the Oracle acquisition of Sun, things that I still hear being discussed today, 2 years later, and things that I consider unresolved or unsolved that I see causing friction and misunderstandings - the kind of which that outburst too represented. Both before and after writing it I wondered if it was a good idea to publish it - I wondered whether I would be seen as helping to solve the problem or just contributing to it. I actually got some positive feedback about it, including from people at Oracle/MySQL (it's kind of a defense of Oracle, actually) so perhaps it wasn't all wrong. Thanks for that feedback by the way, it was really valuable to me.

A part of that post mentions three persons by name: Mårten Mickos, Zack Urlocker and Kaj Arnö. The post in general is not about any of them and they appear mostly as historical MySQL figures, while the post is about the current situation in the MySQL community and in particular how we are still dealing (or not dealing) with events related to the Oracle acquisition. Each of them appear only in a few sentences. Perhaps that brevity is also part of the problem, as you'll see, this post certainly will not be too short. But nevertheless, if you happen to focus on those specific sentences instead of the rest of the post, they do read as quite grave accusations against these persons - perhaps more than any others against Mårten.

Which is also a bit ironic, because whenever I have talked in private conversations about Mårten's open letter to Neelie Kroes, I always had only good things to say about him:

Just wanted to record for the history books that:


drizzle> select js_eval('var d = new Date(); "Drizzle started running JavaScript at: " + d;')\g
+----------------------------------------------------------------------------------+
| js_eval('var d = new Date(); "Drizzle started running JavaScript at: " + d;') |
+----------------------------------------------------------------------------------+
| Drizzle started running JavaScript at: Mon Aug 29 2011 00:23:31 GMT+0300 (EEST) |
+----------------------------------------------------------------------------------+
1 row in set (0.001792 sec)


I will push this onto launchpad tomorrow, after a good nights sleep and final code cleanups.

Update 2012-01-09: I have now been able to understand the poor(ish) results in this benchmark. They are very likely due to a bad hardware setup and neither Galera nor InnoDB is to blame. See https://openlife.cc/blogs/2012/january/re-doing-galera-disk-bound-bench…

People commenting on my results for benchmarking Galera on a disk bound workload seemed to be confused by the performance degrading when writing to more than one master, and not convinced at my speculations on the reasons. Since sysbench 0.5 has the benchmarks in the form of LUA scripts, it was temptingly easy to tweak those a little to see if my speculations were correct. So yesterday I did run tests again with a slightly modified sysbench workload. (Everything else is identical, so see previous article for details on the setup.)

I just uploaded my slides from my Open DB Camp / Froscon talk to Slideshare:

2 concepts I've been an active advocate of during the past few years are both supported by Galera: Multi-threaded (aka parallel) slave, and allowing out-of-order commits on such a parallel slave. In trying to optimize Galera settings for the disk bound workload I just reported on, I also came to test these alternatives.

Single threaded vs Multi threaded slave

All of my previously reported tests have been run with wsrep_slave_threads=32. For the memory-bound workload there was no difference using one thread or more, but I left it at 32 "just in case". For the disk bound workload there is a clear benefit in having a multi-threaded slave: