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

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

Sysbench Synchrones Transatlantiques

One of the pitch lines of the Drizzle project in their rewriting of MySQL code is to rely on standard libraries and make it a full blown C++ project, implying that there's no reason to hold back.

When we started Galera we explicitly decided to do it in C. We didn't have a confidence that libstdc++ was mature enough and expected to have all sorts of problems with it.

Bank restaurant that I have visited today and believe to be one of the largest restaurants (seat-wise) in Helsinki had elevated customer self-service to unparalleled (or rather super-paralleled) heights. The single mutex (cashiers) is locked only once and only to pay for food and grab fork and knife. The rest of IO (choosing and loading food) was totally asynchronous and evenly distributed between serving tables.

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.

So we've been there.

In my opinion the conference was a great success. Our presentation was not, but that's another story. Percona really showed what conferencing is about. Don't know about MySQL. It was behind the closed doors. Valiant guardians strictly watched that you didn't overhear a word of Sacred Knowledge. Hell, even to get to the Expo hall you had to pay $25 (that's right, you had to pay for watching advertisement) and surrender information about your private life, like your phone number and how you learned about the Expo.

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

GLB has been fixed to support unlimited connections and now I can benchmark Drupal stack cluster on large EC2 instances. What I'm looking for here mainly is how much Galera synchronization overhead affects performance here. With small instances everything was pretty much clear: single core hindered by Xen was an easy traget, and scalability was predictably linear. Large instance is dual core, and Xen interference is minimal, Galera synchronization and serialization effect must be more pronounced. How desperately bad is it?

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.

Drupal is a widely used content management system written in PHP that uses SQL server as a storage backend. Although Drupal can work with PostgreSQL, Apache/Drupal/MySQL stack is the usual production configuration.

A number of strategies were developed to scale Drupal performance through clustering, see excellent series of articles by John Quinn. Naturally all of them were capped by the SQL server component. Perhaps Galera is the "holy grail" of Drupal scaling-out?

From Seppo's post you already know that writeset replication isn't particularly suited for table level locking. I would not consider it as a show-stopper though.

As one dude would have surely put it had he been a database developer: "To those who cling to table locking in the age of universally available transactional engines, know that you are on the wrong side of history..."