Henrik just wrote a good article on different ways of achieving high availability with MySQL. I was going to respond in the comments, but decided it is better not to post such a long comment there.

One of the questions I think is useful to ask is what kind of high availability is desired. It is quite possible for a group of several people to stand in a hallway and talk about high availability, all of them apparently discussing the same thing but really talking about very different things.

Henrik says “At MySQL/Sun we recommended against asynchronous replication as a HA solution so that was the end of it as far as MMM was concerned. Instead we recommended DRBD, shared disk or MySQL Cluster based solutions.” Notice that all of those are synchronous technologies (at least, the way MySQL recommended them to be configured), generally …

Brendan Gregg has a very good ongoing series of blog posts about the importance of measuring latency at the layer that’s appropriate for the question you are trying to answer. If you’re wondering whether I/O latency is a problem for MySQL, you need to measure I/O latency at the filesystem layer, not the disk layer. There are a lot of factors to consider. To quote from his latest post:

This isn’t really a problem with iostat(1M) – it’s a great tool for system administrators to understand the usage of their resources. But the applications are far, far away from the disks – and have a complex file system in-between. For application analysis, iostat(1M) may provide clues that disks could be causing issues, but you really want to measure at the file system level to directly associate latency with the application, and to be inclusive of other file system latency issues.

Someone should add Brendan’s feed to Planet MySQL. Here …

https://code.launchpad.net/~stewart/drizzle/json-interface/+merge/59859

Currently a very early version of course, but it’s there in trunk if you want to play with it. Just have libcurl and libevent installed and you can submit queries via HTTP and JSON. Of course, the next steps are getting a true non-sql interface going and seeing how people go with it.

This month’s Maatkit release includes a new tool that’s kind of an old tool at the same time. We wrote it a couple years ago for a client who has a very large set of tables and many queries and developers, and wants the database’s schema and queries to self-document for data-flow analysis purposes. At the time, it was called mk-table-access and was rather limited — just a few lines of code wrapped around some existing modules, with an output format that wasn’t generic enough to be broadly useful. Thus we didn’t release it with Maatkit. We recently changed the name to mk-table-usage (to match mk-index-usage), included it in the Maatkit suite of tools, and enhanced the functionality a lot.

What’s this tool good for? Well, imagine that you’re a big MySQL user and you hire a new developer. Now you need to bring the new person up to speed with your environment. Or, you want to …

Vadim has taught me that valid benchmarks are both simple and complex. Simple, because the basic principles are few; complex, because the devil is in the details and it’s a lot of work to satisfy the basic requirements. I’ll give the simple version here.

• Benchmarks must be appropriate. The workload, sample dataset, distribution of work and data, and so on must be relevant and meaningful for the intended purpose. Running the wrong benchmark rarely teaches anything.
• Benchmarks must be fully documented. Another researcher must be able to determine exactly how you ran your benchmark, on what hardware, under what workload, what operating system, kernel version, all MySQL tuning parameters, and so on.
• Benchmarks must be repeatable. Another researcher must be able to reproduce your results. Documentation is part of this, but you need to ensure that you can reproduce your own results. If you can’t, no one else …

I am not a fan of the MMM tool for managing MySQL replication. This is a topic of vigorous debate among different people, and even within Percona not everyone feels the same way, which is why I’m posting it here instead of on an official Percona blog. There is room for legitimate differences of opinion, and my opinion is just my opinion. Nonetheless, I think it’s important to share, because a lot of people think of MMM as a high availability tool, and that’s not a decision to take lightly. At some point I just have to step off the treadmill and write a blog post to create awareness of what I see as a really bad situation that needs to be stopped.

I like software that is well documented and formally tested. A lot of software is usable even if it isn’t created by perfectionists. But there are two major things in the MySQL world for which I think we can all agree we need strong guarantees of correctness. One is backups. The other is …

GreenSQL invites you to participate in our May Webinars
MAY 18- Securing Databases in Minutes with GreenSQL Express
MAY 24 – Unified Database Security, the Next Generation of Database Security
Press here to sign
http://hosted.verticalresponse.com/579426/4aa0167718/316941501/bdea25b57a/

I am ridiculously far behind on reading blog posts since the MySQL conference. I like to lag somewhat behind, because then when I read the posts I get to see some comments. But I’m much farther behind now than I want to be. This is mostly the fault of the MySQL replication, Performance Schema, NDB Cluster, and InnoDB developers, who just announced a large number of improvements in the upcoming MySQL 5.6 release. How long did it take them to draft all those posts? I hope they keep blogging steadily between releases, too. In the meantime, I’m too far behind. It’s a good problem to have.

Related posts:

1. IE blog is a great experience
2. I moved this blog to pairLite with …

I split my time last week between the IOUG’s Collaborate conference in Orlando, Florida and O’Reilly’s MySQL Conference & Expo in California. The contrast was stark. For me as a MySQLer, Collaborate was a dud. On the other hand, the MySQL conference O’Reilly puts on is superb. It is vital to MySQL as a project and as a community, and it follows that it’s vital to MySQL’s business success. Oracle needs to participate to make it a success in the future.

MySQL at Collaborate had good speakers and content, but no one there is interested in MySQL. MySQL is just from a different world — it is a curiosity at an Oracle conference. Also, as a speaker, sponsor, and attendee, Collaborate was a giant frustration. I can’t recommend it to anyone. (These comments do not reflect on the work that MySQL community members did in recruiting and organizing the MySQL content at the Collaborate conference.) In particular, the experience of …

The slides for my talks at the O’Reilly MySQL Conference and Expo are posted.

Related posts:

1. Videos and slides for MySQL Conference 2010
2. Slides for the innotop workshop at MySQL Conference and Expo 2007
3. Recap of CPOSC 2009, plus slides
4. I’ll be speaking at the O’Reilly MySQL Conference 2010
5. …