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:

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:

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…

After getting very good results with Galera with using a memory bound workload, I was eager to then also test a disk bound workload. Also this time I learned a lot about how Galera behaves and will try to share those findings here.

Setup

The setup for these tests is exactly the same as in last weeks benchmarks, except that I've now loaded the database with 10 tables containing 40 million rows each. This sums up to about 90GB database:

Speaking of conferences, in general, and OpenSQLCamps in particular, there is one a week from now, and I will be speaking! It is organized as a single room track at Froscon, Germany, by Felix Schupp (Blackray/Softmethod) and Volker Oboda (Primebase). The content is mostly a collection of database related talks originally submitted via the main Froscon call for papers. (In other words, unlike many previous camps, the schedule is all set.)

I'm a little excited about this one, because for the first time in my career as speaker I will be giving the keynote. The title of my talk is

How I learned to use SQL and how I learned not to use it

So, vacation is over and I was in luck: Already during first week I had ample time to finally put Galera replication to the test. It was a great experience: I learned a lot, and eventually got the great results I was hoping to see.

Again I've started by just running the standard Sysbench oltp read-write test. Since this is a commonly used benchmark, it produces numbers that are comparable with others running the same benchmarks. Including, as it happens, Galera developers themselves.

These tests were run on an 8 core server with 32 GB of RAM and the disk on some EMC device with a 2,5GB write cache.