Events and backup - two good features - an awful combination

The cool features coming with MySQL 5.1 and 6.0 are the event scheduler and so called online backup.
Both of them implement something that you can do outside the database server. The event scheduler frees the DBA from the operating system dependency and the database backup and restore makes mysqldump redundant.
So far, the good news. What's wrong with this picture?
A look at the manual tells you all. You can backup and restore a database with an explicit SQL statement, but you can't use it in a prepared statement or in an event.
What?
WHAAAAT?
What do I use the event scheduler for, then? Ask any DBA about the first thing that comes to mind associated to a time scheduled event, and 9 times out of 10 the answer is "backup".
So, why is the most logical action not allowed in events?
And don't try to cheat the system with a stored routine that may free you from the details of stating which backup file to use. The backup database and restore database commands are not supported in prepared statements. Ergo, even if you could use "backup database" in a stored routine, it won't do you any good, because the MySQL server can't overwrite an existing file.
Sure, you can circumvent this prohibition with some hacks (MySQL Proxy could be helpful, for instance), but why the user has to suffer for such a small issue?
MySQL developers, if you are listening, please think like users!

Mapping the MySQL community

I was intrigued by this survey about MySQL today, and I took it.
Some of the questions made me think about the status of MySQL community. Unlike other free/open source projects, MySQL community people are not direct contributors to the project, but just users. Then there are the more advanced ones who keep an active role, and the majority who are just content to use it and don't even care to participate in blogs or forums.
Seen throrugh the articles in PlanetMySQL, the MySQL community has three components, with sub components:

• Sun/MySQL employees, who link between the noisy users and the company.
• The ones who produce or advocate closed source
• The ones who only deal with open source
• The ones who tell interesting stories without taking sides.
• The interested parties, i.e. the ones who have gained some expertise in MySQL and sell their services or products.
  
• The positive vibes, who promote their business and contribute constructive criticism
• The negative vibes, who are always complaining about something, trying to weakening MySQL in order to sell their stuff, even when they contribute good technical stuff.
• The enthusiasts, who just write about cool things.
  

Maybe the distinction is wider, but this is how I see it after browsing planetmysql archives for a while.
I like to collocate myself in the third group. And I am thinking of taking a few notes and write a Whos' who of MySQL community when I have time.

MySQL sought by politics

In the hot US political campaign, something of interest for MySQL is happening. The Obama camp is looking for developers in the LAMP stack, asking for MySQL experience. They also ask specifically for deep knowledge of MySQL performance and query optimization. The interesting bits about this request is that it is
It would be interesting to know what the McCain camp is going to use to counter this move. But it is not going to be so difficult to guess ...
$ wget -O /dev/null -S http://www.johnmccain.com/
...
Content-Location: http://www.johnmccain.com/Home.htm
Last-Modified: Sun, 01 Jun 2008 13:39:58 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
...
I can already foresee many geeks converting a political debate into a technological challenge.
As, for me, I don't discuss my political views. Go LAMP!

Sun, the stock market lottery, and the road ahead

Seeing the recent stock market disaster, I wonder if it makes sense to hire capable managers, when your company is hostage of the stockholders mob.
The news delivered by Sun did not seem that bad, except for the USA salesforce. Sun is growing everywhere else in the world, and a slow US economy has punished the whole company out of proportion. The reaction from the crowd is really unbelievable.
On a related matter, Sun has announced the layoff of 2500 people. What does it mean? Sun's strategy is based on growth, or so they say. How can they grow if they start firing people?
Bah!

MySQL and Ubuntu - a perfect match

I like Ubuntu's philosophy. Among the Debian derived Linux distros, it's the one that appeals to me the most. The first live CDs (Knoppix, Mepis) were a revolution, but Ubuntu has perfected the trend by adding a quality that was missing from these early ones.
I especially like the ease of installation. Plug to the net, apt-get install package_name, and presto! you got what you want.
MySQL server comes with just one line:

apt-get install mysql-client mysql-server

This will get you the latest server and client binaries, ready to use.
Yesterday I wanted to build MySQL 5.1 from source. The latest one (5.1.24) that has been released is missing the Federated engine, and I wanted the complete thing. So I installed Ubuntu in a spare machine, and got the source code from the development tree.
By default, Ubuntu does not ship with a compiler, and the manual lists quite a lot of requirements to get the ball rolling. In Ubuntu, installing the recommended building tools is as easy as:

apt-get install build-essential autoconf automake libtool bison byacc libncurses5-dev

After this command, to compile a complete server, you type:

cd where/you/downloaded/the/source/tree
./BUILD/compile-pentium-max

And it works without a glitch. Could it be easier than that?
On a side, but not entirely unrelated note, after Sun's acquisition, I suspect that Solaris will play a more important role with MySQL. I have little experience with Solaris, but surely it isn't as easy as Ubuntu. I wonder if there is an equivalent in Solaris to the above apt-get command. Any takers?

backup by slave, oh yes!

A well thought backup saved my skin last Saturday.
It's a simple setup: many copies. Using MySQL replication, the master is for writes.
Four slaves for reads. One slave for backups only (*). In a different server room. In a different building. (**)
The backup slave has a  cron job, which stops the slave, makes a dump, removes the oldest one, and resumes replication.
The same job works hourly (keeps 30 dumps), daily (keeps 7 dumps), and weekly (keeps 8 dumps).
The disaster occurred yesterday. A colleague who was working too much (***) made a destructive query on the wrong server. He thought he was using the development server, but it turned out to be the master. Fortunately, nobody else was working on a Saturday, so there weren't any changes, besides his. I zeroed the database on the master and reloaded the latest hourly dump. No suffering. No bad blood, and my morning coffee is paid till the end of the quarter!

(*) Replication is not a backup.
In this particular case, if you rely only on replication, your data is gone forever. 
You have five copies, all of them FUBAR.
(**) Keep the backup slave in the same room, and a flooding will make both master and slave useless at once.
(***) Seriously, Mel! You should have been holding a beer in a pub downtown instead of being in the office.