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.

As someone may have noticed, I recently wrote a trilogy on how to dive into the MySQL Cluster source code. Unfortunately my overtures towards the MySQL Cluster source code ended up being only a look-but-don't-touch affair, as I failed to actually get to touch her internals with my text editor. Even so, in this post I'd like to tell about the background to my love affair with this beauty, by relating to some benchmarks I've been working on together with my customers.

Oh, and I'd like to apologize already, that I cannot mention where these benchmarks were done, what the schema looked like and the exact numbers. If you want that kind of real benchmarks, you should read Mikael's blog, or watch the slides from this webinar. (Then compare those results to BigDBAHead's SSD RAID magic with InnoDB, both are the same DBT2 benchmark.)

(Continued from part II where I tried to fix a bug and found out that the affected part of the code had been rewritten, so the bug didn't exist anymore.)

Magnus gives a helpful hint...

This is part II of my efforts to prove myself that I can do programming. In part one I successfully created a MySQL Cluster branch for myself and compiled it.

Let's go to the public MySQL bug database and see if there are any trivial MySQL Cluster bugs I could sharpen my teeth on. Heh, sure enough #32658 looks simple enough. There is a typo in an output string - so I could fix that without even doing any C++ code! (Funnily, a MySQL internal comment to the bug says something about it being embarrassing. Guess it is a good bug for me then, as patching over embarrasments is what Sales Engineers do routinely :-)

Let me see...