There has been an increase in the discussion about MySQL replication and how to make it happen faster. I don't think Marco Tusa's blog is on Planet MySQL, so let's highlight it first: A dream on MySQL parallel replication. This is a good account of what it looks like out in the field of MySQL databases today - you are increasingly aware of replication, fearing it will be a bottleneck you cannot fix.

The headline above could fit in a tweet, but Drizzle making its first release almost 3 years after the project started deserves a blog post.

Brian Aker has a long blog post looking back at these 3 years (and even longer into MySQL history). Stewart Smith has an entertaining personal perspective. .frm files, I will not miss you (if I were to start using Drizzle, that is). Planet Drizzle has an avalanche of posts from most Drizzle devs celebrating this event.

I finally did the migration to Drupal 7 for the Footnotes module this weekend. See Release notes and project page for more information.

With this release I also announced my intent to hand over the module to a new maintainer. Since I'm now increasingly active with affairs in the MySQL community, both hacking as well as other community tasks, it is prudent to not let old projects dangle without attention but to formally hand them over to fresh minds.

An annual tradition of the upcoming O'Reilly MySQL conference is the awards ceremony. Originally the winners of these prestigious awards were nominated and selected by various MySQL AB personnel. 2010 was the first year when the winners were selected by a community panel. This year we are building and expanding on that: This is an invitation for everyone in the community to send in nominations for the awards in the 3 categories named below.

Please send in your suggestions for deserving winners
to: mysql.awards [at] gmail.com
no later than: 23:59 Sunday March 27th (Pacific time)

As some Facebook friends already guessed from my status updates this week, my 9 month paternity leave is now over and I've survived my first week back in work life, waking up at seven in the morning! This is just a personal-life blog post to let everyone know what I'm up to, (For those asking: Ebba is doing fine, she recently started to stand up and even takes steps if I hold her hands.)

During the past months I had many interesting conversations and ideas of what to do next, but in the end Nokia was the company standing out with a very interesting offer. So as of last Tuesday I work at Nokia as Senior Performance Architect in the Mobile Solutions division, better known as the Nokia Ovi web services.

This is the final part in a series of posts about the MepSQL build system known as MepSQL Bakery. MepSQL is a (yet another) fork of the MySQL database server, with the server based on the MySQLatFacebook code and the build system based on the MariaDB build system.

In this final post I wish to draw a high level picture of the complete process of building TAR, DEB and (eventually) RPM packages from the source code. There's not much more technical details to add to the previous posts, instead I'm going to make some, shall we say "archeological", observations which imho are interesting given how the build system has evolved when being passed from one project to another. Perhaps more importantly, I will also say a few words about where I think the future direction lies.

Yesterday I wrote down the approach used in the MepSQL build system to parameterize the TAR package name produced. Today I will follow up with how the same was done for building DEBs. The motivation is to create a system that can be used flexibly to create packages of any MySQL fork, with any brand name: mepsql-server-*.deb, percona-server-server-*.deb, mariadb-server-*.deb or even just mysql-server-*.deb (which I might do some day).

While yesterday's tricks with the TAR files were rather straightforward, with the process of building DEBs this turns out to be much more challenging. But not to worry, like my former collague Bernhard Ocklin used to say: This is software, anything is of course possible.

As I mentioned before, it seems that thanks to Git and Bzr introducing distributed version control workflows, the open source community is now living in a phase where forking is easy and happens frequently - referred to by Brian Aker as the Cambrian Explosion of open source. We certainly see that happening in the MySQL Community.

Assuming you have the competence and know your way around a codebase, forking a proper open source project isn't that hard. You create your own project on GitHub or Launchpad and copy the source code. 1 But one thing you need to do is to change to using the new name (Drizzle, Percona, MariaDB, MepSQL....). Typically you want to keep using the original command line and file names (mysql, mysqld_safe, libmysql...), yet the product name as it appears in your installation packages is changed to distinguish it from the parent project.

In the life of an open source project a name change is a relatively rare occurrence. Most projects never fork or change their name. So it is not surprising that all the tools and methods we use while programming assume that the product name is a constant. It turns out it is hardwired into build scripts here and there. Sometimes excessively: when building DEB files the word "mysql" is used over a hundred different times!

• 1As noted in previous posts, if everything isn't fully open source, which is the case with MySQL, you have a challenge in reproducing from scratch the missing parts, like documentation, build system, etc...

This is the third post in a series about developing the MepSQL build system. In the previous posts we chose BuildBot running in the Amazon EC2 cloud. In this post we actually get a closer look at how the packages are being built (to be followed by even closer looks in later posts :-)

One of the things missing when you fork MySQL is the build system. (The other main missing component being the manual.) It is possible for anyone to compile MySQL from source, but the actual build system (scripts, testing, etc) used by MySQL itself is not public. The same is true for the automated testing. MariaDB uses the open source tool called BuildBot for both of these tasks - in this post we are mainly concerned about the building of packages. Actually, we are mainly concerned with BuildBot itself and the details about building packages is saved for a later post. I will document both the MariaDB system and the MepSQL system which was derived from that.

This is the second part in a series of posts about how the MepSQL packages were built. In part 1 I evaluated OpenSuse Build System and Launchpad PPA and ended up concluding that running your own BuildBot system is the best choice, as those public services didn't provide any facility to test their packages.

This brings us to the next topic: As I don't possess any servers, should I buy one (or more) or should I try out the cloud services? If yes, should I use Amazon EC2 or something else?