The question "what problems will I have when migrating to the cloud" gets asked often enough. If by cloud you mean Amazon EC2, then from a technical perspective there isn't much that changes. The biggest thing that changes is just how you pay your bill.

Having said that, there's still a few potential gotchas:

1. There are no Virtual IP addresses. Most High Availability tools (like MMM or DRBD+Heartbeat)
   work on the principal of having a floating IP address which is used for the application to connect to the current master. With EC2, you can't do this.
2. There's no customization of the memory. The maximum amount of memory you can have is 15GB, so some users with larger working sets may find this a limitation. If you look at the Dell online store, it costs $2094 to upgrade an R900 from 4G memory to 64G (or $4378 to upgrade to 128G) which …

I have had a wish for a few years. I wanted to find a way to put together the valuable information that the community produces about MySQL, a way that would let me easily find the interesting content that I may have missed when on vacation, or when busy with a conference, a company meeting, or a long stream of coding.

That wish started to take shape last year, when I was traveling with Dups during the East Coast tour. I drove, he took notes. He drove, I took more notes. During meals and walking breaks we discussed and refined the idea. When we went back home, a plan was ready. Dups started coding in January.

At first, his changes were completely invisible. He was refactoring the Planet MySQL code to integrate it with the advanced features that had been developed for the main site. After a series of secondary changes, there came the substantial one. The voting …

I have had a wish for a few years. I wanted to find a way to put together the valuable information that the community produces about MySQL, a way that would let me easily find the interesting content that I may have missed when on vacation, or when busy with a conference, a company meeting, or a long stream of coding.

That wish started to take shape last year, when I was traveling with Dups during the East Coast tour. I drove, he took notes. He drove, I took more notes. During meals and walking breaks we discussed and refined the idea. When we went back home, a plan was ready. Dups started coding in January.

At first, his changes were completely invisible. He was refactoring the Planet MySQL code to integrate it with the advanced features that had been developed for the main site. After a series of secondary changes, there came the substantial one. The voting …

I was asked recently in one of my blogs what are some of the pure technical advantages of moving from MySQL to Oracle. I kind of laughed when I read the question because nothing is likely to stir up more perspectives and emotions than asking about moving from one database server vendor to another. So here goes ten technical considerations of moving to an Oracle database server from a MySQL

Finally merged into main. I added the ability for engines to be temporary only – that is you can only CREATE TEMPORARY table or be created and used during query execution. This allows us to refactor/remove some other code and go towards a “locking is inside the engine” mantra as anything but row level or true MVCC is certainly the exception these days.

Forrester put out its Enterprise Data Management Q2 2009 report a few days ago, you can buy it from Forrester but it also seems to now be available for free from Microsoft here.  I don’t actively seek out these reports as they usually just re-enforce common knowledge (this one was no exception), however as it turned up I managed to find some time on the weekend for a quick read through.

Few surprises in this report, but some key mentions are:

• DBMS market expected to grow 8% annually
• IBM, Microsoft & Oracle own 88% of the DBMS market (by revenue)
• Current market estimated at $27 billion, $32 billion by 2013
• IBM, Ingres, Microsoft, Oracle, PostgreSQL, …

Open SQL Camp will be organized in St Augustin, Germany on the weekend of 22-23 August. Unfortunately, at Monty Program, it looks like we have already scheduled a company meeting at the same time and all of us will be in Spain instead. Consequently, there are now no MariaDB talks proposed for the conference, which is a shame.

read more

Among other things, these past few months I have been working on setting up Buildbot, including adding various enhancements and bug fixes that are needed to properly build and test the MariaDB and MySQL code base.

Since Buildbot is written in Python, this means I have also had to learn Python. I am an old-time Perl hacker, so this exercise feels a bit like living in enemy territory ;-)

Anyway, Python is often touted as a more "pretty" language. And in many ways it is. Still, it is not without its own gotchas. Think "scope rules". Obviously someone haven't been reading up on the subject before implementing things in Python, causing the language to behave stupidly (and certainly different from what one expects) in the following three cases that I hit during my Buildbot work.

First …

The MySQL KILL command as the name suggests kills queries that are running.

After identifying the Id using the SHOW PROCESSLIST command, the User of the connection/thread or a database user with SUPER privileges can execute KILL [id]; to remove the connection/thread.

However, there is an ability to kill just the query that is being executed rather the entire connection. The default when not specified is to kill the connection, however you can optional specify the CONNECTION or QUERY keywords.

For example, below is an interactive test.

Thread 1:

mysql> select sleep(10);

Thread 2:

mysql> show processlist;
+----+------+-----------+------+---------+------+-----------+------------------+
| Id | User | Host      | db   | Command | Time | State     | Info             | …

I've been working on cleanups to the Drizzle autoconf and automake system. Actually, to be fair, I've been doing this work on Drizzle, Gearmand, libdrizzle and libmemcached.

In all of those projects, we have the same set of build ideas:

1. Warnings == Errors
2. As many warnings as we can enable
3. Lots of people will be building directly from bzr

As it turns out, I'm pretty lazy, and I got tired of remember to port the latest m4 macro fix that we made in one project across to the other three. O, hai - code reuse!

So I did some refactoring and split the several macros and large portions of the configure.ac files out into a set of m4 macro files. These now live in their own project, which you can grab from bzr via:

 bzr branch lp:pandora-build

Although each of the macros is useful by itself, the fun part is that you can just put:

…