Maybe this was the 0th week!

Yep, I started working on Summer of Code project little by little,
one day after another.

On Monday, I got really excited when I realized that that e-mail from
Google entitled “Congratulations” was addressed to me, not to the
student list… indeed, I noticed that more than a hour after I first
read it (I was really heedless in doing that, don’t you think?). The
Web app did not show the accepted proposal yet, so I went to sleep but
was not able to stop thinking (at least for some time :-).

On Tuesday I woke up with the news I’ll work on the implementation of
a new storage engine for the MySQL DBMS: pretty exciting wakening! To
tell the truth, I was a little worried, because this was absolutely
not the simplest project I could have been chosen to …

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 …

Sarah already wrote something about the PHP Unconference, but Mayflower sent a bigger team, so here are some more impressions.

The unconference had a fair share of the "ever-present" people in PHP development and the corresponding open-source community and also people interested in recent features and willing to learn although they came from different backgrounds. This avoided most of the low-level noise and kept the weekend on a very high level.

Both days there were 4 session tracks with 4 talks each for an admirably rich choice of 32 possible sessions, which made it very hard to get hold of everything you're interested in, but this was deliberately planned and I didn't attend a single talk I didn't like. The long coffee-breaks had a very intense tendency to keep the people busy discussing technical questions or just general chatter with old acquaintances that the orga team was busy driving the people to the talks …

Last weekend the PHP Unconference took place in Hamburg. With about 120 participants it took awhile to vote for the offered talks but at the end more than 30 sessions appeared on the agenda for two days and that promised to be an exciting weekend. You'll find all topics and summaries on PHP Unconference Wiki. There were many interesting sessions for choice, for example 'MySQL Performance Tuning' by Kris Köhntopp, with which started the first day. 45 minutes, as it turned out, were not long enough for this talk and I would have liked to hear more about it. During the talk 'Ask the core developer' by Johannes Schlüter the current moods and the future of PHP and the community were discussed, yet not all of the attendees had the same opinion about that. Security, too, was a topic of the unconference and Johann-Peter Hartmann had …

How do you configure python for use with mysql? You require the MySQLdb module for connecting to mysql server using the python code. This module is used for firing queries to the database server and handling of result sets from python code.

First of all, check if the module is available or not :

jayant@jayantbox:~$ python Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) [GCC 4.2.3 (Ubuntu 4.2.3

This question often comes up, and the general answer given appears to be "CREATE TABLE ... SELECT ..."
But actually, that does not do what you might expect, as this statement creates a table structure based on the resultset of the select, so the column types may differ from your original table, and the table will not have indexes either.
The syntax does allow you to add and override pretty much everything, but since we were talking about copying, let's look at another way:

CREATE TABLE bar LIKE foo;
INSERT INTO bar SELECT * FROM foo;

This produces an exact copy of the original table, both structure and data, indexes and everything.
No, you can't combine these two into a single statement. Sorry ;-)

I’m still looking for new entries. I get quite a few suggestions, but not all of them make it into quiz questions. Do send in your suggestions!

This wonderful quiz from Vladimir Kolesnikov is one of those that should make you stop and think for a moment…

Given this table and data:

mysql> SELECT * FROM t;
+------+------+
| i1   | i2   |
+------+------+
|    1 |    2 |
|    2 |    1 |
|    4 |    3 |
|    3 |    4 |
+------+------+
4 rows in set (0.00 sec)

What is the result of the following three statements?

SELECT * FROM t ORDER BY 1

SELECT * FROM t ORDER BY 2

SELECT * FROM t ORDER BY 1+1

(more…)

Well these days we see a lot of post for and against (more, more) using of MySQL and DRBD as a high availability practice.

I personally think DRBD has its place but there are far more cases when other techniques would work much better for variety of reasons.
First let me start with Florian's comments on the issue as I think they are most interested ones.

First lets get to the point what we're comparing here - it is mainly DRBD to MySQL Replication based techniques (lets …

(If you want $100, you will have to read the entire blog post. Sorry for the tease, but I did not want folks to miss out on the opportunity to win!)

By now it is no surprise that I won one of the three 2008 MySQL Community Member of the Year awards. And folks may know that I won the same award last year.

One interesting fact you may not know: during the 2006 MySQL Awards Ceremony, where Giuseppe Maxia, Roland Bouman, Markus Popp and …

In my post on estimating query completion time, I wrote about how I measured the performance on a join between a few tables in a typical star schema data warehousing scenario.

In short, a query that could take several days to run with one join order takes an hour with another, and the optimizer chose the poorer of the two join orders. Why is one join order so much slower than the other, and why did the optimizer not choose the faster one? That's what this post is about.

Let's start with the MySQL query optimizer. The optimizer tries to choose the best join order based on its cost metric; it tries to estimate the cost for a query, then choose the query plan that has the lowest cost. The unit of cost for the MySQL query optimizer is a single random 4k data page read. In general, it's a pretty …