Sheeri was also in Hämeenlinna for the OUGF Harmony conference a few weeks ago, and of course she had her video camera with her. My talk "Synchronous multi-master clusters with MySQL: an introduction to Galera" is now posted on Youtube. (You may also want to watch the slides on slideshare while listening.)

I think this is a really good talk if you are interested in Galera. First we cover how to get a Galera cluster running, including the most important options and status variables to pay attention to. I cover both the internal Galera architecture and how to use load balancers and clustering frameworks, and explain how galera handles node crashes and network partitioning.

In the series of shell one liners, today I wanted to stalk someone, so I came up with this one liner to show all diffs ever created by a specific user in a give bzr repository:

bzr log -n0 | grep -B 1 henrik | grep revno | grep -v merge | \
awk -F'revno: ' '{print $2}' | while read revno; do echo; \
echo '#####################################################################'; \
echo revno: $revno; bzr diff -c$revno; done 

bzr log -n0 prints out the full log history of your repo. It may look something like this:

    ------------------------------------------------------------
    revno: 2441.2.16 [merge]
    committer: Henrik Ingo 
    branch nick: drizzle-json_server-keyvalue

Some time ago I finally had the chance to test the built-in load balancing feature in MySQL's JDBC driver together with a 3 node Galera cluster. I have used this feature at a MySQL Cluster customer many years ago, so I knew it worked and I knew it was great, but I didn't know if it would work with Galera. Galera sometimes returns some error states that are different from what MySQL Cluster does and the main point of the test was to see how the loadbalancing in the JDBC driver reacts to that.

On Thursday I went to the Harmony conference arranged by Oracle User Group Finland to speak about Galera clustering. (They chose the topic based on my suggestions.) The slides are now available on SlideShare. I'm pretty satisfied with this talk myself, the slides contain the most important steps you need to know to get started, but also the internal architecture of Galera, how it works, and what kind of replication topologies and load balancing you would want to use with it. And benchmarks of course.

Heli from Oracle User Group Finland invited me to speak at this years OUGF Harmony conference which starts tomorrow. Last year I had some proposals accepted but had to decline due to work travel.

This year they wanted to learn more about Galera and I was of course more than happy to go and speak. My talk is titled "Synchronous Multi-Master Clusters with MySQL: an Introduction to Galera." It contains some parts of what we presented at the MySQL Conference, but is more of an introduction and less about benchmarking.

The Helsinki MySQL User Group will meet at the usual place on May 29th. Click here for details and to RSVP. Linas Varbalas will talk about Tungsten and maybe dare a live demo!

Linas is in town for the OUGF Harmony conference 2012. The conference might of course be of some interest to user group members too. Due to the conference we also have other famous MySQLrs in town, Sheeri Kabral of OurSQLcast fame has also confirmed she will attend the user group (and maybe have OurSQLcast CD's with her?)

A few weeks ago I blogged about the HTTP JSON api in Drizzle. (See also a small demo app using it.) In this post I want to elaborate a little on the design decisions taken. (One reason to do this is to provide a foundation for future work, especially in the form of a GSoC project.)

Looking around: MongoDB, CouchDB, Metabase

This post is about a fairly technical detail of how Galera works. I'm writing it down in preparation for testing this feature so that I can agree with Alex whether to file a bug or not. I'm sharing it on my blog just in case someone else might benefit from learning this.

Galera 2.0 introduces rolling schema upgrades. This is a new way to do non-blocking schema changes in MySQL.

As the name suggests, it is done as a rolling upgrade. Having seen clusters doing rolling upgrades before, I assumed this is what happens:

• Execute alter table on Node 1.
• Node 1 is removed from the cluster and stops processing transactions.
• Node 1 completes alter table.
• Node 1 re-joins cluster and catches up so that it is in sync.