alex's blog

Uh, this is this time of the year again. You know, MySQL User Conference and Stuff. And again we need to bring some news about Galera.

What's new about Galera? Everybody knows that it kicks ass, so that's nothing new. So I've been thinking...

There have been quite a few questions about how Galera is different from NDB (MySQL Cluster). Well, how is it not different?

A short discussion with Baron at Henrik's blog has stirred my eloquence.

So, when I posted new benchmarks about intercontinental synchronous replication performance, I kinda was not sure if that 6000 km disaster recovery scenario was not blown out of proportions. Honestly I didn't really believe that the whole EC2 availability zone can fail just like that, without major nuclear conflict. And guess what? This is exactly what happened — one of the EC2 availability zones that was used in my benchmarking did exactly that.

So, the other day I posted the performance benchmarks for the multi-master MariaDB/Galera cluster. Spectacular performance. But some of you may justifiably say:

— Well, we were born into a master/slave world. We, like, adapted to it. We have invested so much brain power to make our applications to work in master/slave environment. What do we do now with all these read/write splitting voodoo Lua scripts and slave lag battling techniques? And master failover... There's a whole industry there. Thousands of jobs!

It's been long known that Galera optimistic replication and enterprise-size databases are a match made in heaven. Today we're going to get a little closer to testing this statement.
We'll have look at how Galera can scale out Sysbench OLTP complex 60 million rows workload in EC2. This is a first proper benchmark for 0.8 series and also the first benchmark of MariaDB/Galera port, so I'll start modest, just to see how it goes. I chose m1.large instances with 7.8Gb of RAM for server nodes and c1.xlarge instance for a client - I don't want the client to be a bottleneck.

The time has come. People keep on asking why there is a practical limit on the number of nodes in multi-master cluster and what is it exactly. So here's some no-nonsense hardcore multi-master math
(hereafter I assume that all nodes in a cluster have the same processing power and load is distributed uniformly between them).

Dedicated to Fernando Pedone and other modest and courageous researchers whose work made this possible.

It been sometime since we benchmarked MySQL/Galera with sysbench, using it mostly for testing. Our recent visit to Percona Performance Conference showed that sysbench is probably most widely used tool for MySQL benchmarking in the community and besides it is the only benchmark I know that correctly measures response times. So I just gave it a shot with our 0.6 release.
I ran OLTP test on 1-4 large EC2 instances. At first I tried 100K row table and it was good except that the deadlock rate was too high to my taste:

This is the second part in in the series of posts about scaling Drupal stack. The first part can be found here.

Trend is an amazing piece of software that packs incredible amount of functionality into tiny amount of code and brief syntax. Trend is your universal live data plotter. It can work as oscilloscope and it can work as a regular strip chart plotter. It can get data from fifo or from standard input. It can read data as text or in binary form. It is almost completely configurable in runtime. In short: it is a pinnacle of software engineering, a crown of creation, an answer to all our needs and everything.
Trend can be downloaded from: