OUTER JOIN queries in SQL are susceptible to two very subtle bugs that I’ve observed a number of times in the real world. Daniel and I have been hammering out ways to automatically detect queries that suffer from these bugs, in a relatively new Maatkit tool called mk-query-advisor. It’s part of our series of advisor tools for MySQL. I wrote a blog post about it a while ago. Automated analysis of bad query patterns is a good thing to write tools to do, because catching buggy queries is hard work if you do it manually.

mysql > start review;
Query OK, 0 rows affected (0.00 sec)

mysql > Being a MySQL DBA, not a developer, I was mostly interested in the MySQL sections but given I have a general interest in scripting I did go through some of the PHP sections. To be honest they were quite advanced for my php knowledge and experience.

The good thing about the book is that even though it assumes you have the basic knowledge, it still provides an introductory background on most of the two (PHP and MySQL) topics. This is not a “PHP and MySQL for dummies” so don’t expect to learn the very basics nor will you become an expert in either topic by just reading the book. Even if you read the book thoroughly, becoming an expert requires years of hard work and experience. Having said that, his book is a good guide to make it there.

If you are at least a basic developer, this book will help you increase your knowledge drastically and …

Recently, Jobin took up the mantle of starting to poke at Windows support for Drizzle. We decided that step 1 is getting libdrizzle building on Windows - not to mention we could solve a few systemic "how to go about it" problems on a much simpler codebase.

We decided to go the mingw route - for two reasons.

1. on windows we wouldn't have to solve the build problem yet
2. on linux we can cross-compile, and then I can spend less time connecting to a windows machine 

I'm happy to say that the branch implementing support for building under mingw has been merged in to trunk - so please go hammer at it and tell me that I'm an idiot.

If you're on linux and want to play, you'll need mingw32 and mingw32-pthread. You may notice that mingw-pthread isn't in the …

A couple of weeks ago one of my colleagues and I worked on a data corruption case that reminded me that sometimes people make unsafe assumptions without knowing it. This one involved SAN snapshotting that was unsafe.

In a nutshell, the client used SAN block-level replication to maintain a standby/failover MySQL system, and there was a failover that didn't work; both the primary and fallback machine had identically corrupted data files. After running fsck on the replica, the InnoDB data files were entirely deleted.

When we arrived on the scene, there was a data directory with an 800+ GB data file, which we determined had been restored from a SAN snapshot. Accessing this file caused a number of errors, including warnings about accessing data outside of the partition boundaries. We were eventually able to coax the filesystem into truncating the data file back to a size that didn't contain invalid pointers and could be read without …

Almost no one will ever notice anything about this, but I'm excited, so I thought I'd share.

Instead of using the build infrastructure installed by gettextize to handle message translations, we're now using the more modern replacement, intltool.

Unless you're actually hacking on build, this will mean nothing - translations are still done via launchpad - Drizzle still uses gettext() to translate strings. It's purely a tooling change which means the build is less brittle and I'm slightly less ornery. Oh, and we have many less random generated files committed to bzr. I like deleting files.

I noticed that people were hitting the site for information on how to run mysqlslap.To help out those searchers, here is a quick mysqlslap howtoMake sure you have mysql 5.1.4 or higher. Download MySQL from the MySQL websiteMake sure your MySQL database is running.Run mysqlslap, using progressively more concurrent threads: mysqlslap --concurrency=1,25,50,100 --iterations=10 --number-int-cols=2 \-

I noticed that people were hitting the site for information on how to run mysqlslap. To help out those searchers, here is a quick mysqlslap howto Make sure you have mysql 5.1.4 or higher. Download MySQL from the MySQL website … Continue reading →

There is a lot of discussions whenever running MySQL storing data on NFS is a good idea. There is a lot of things for and against this and this post is not about them.
The fact is number of people run their databases on NetApp and other forms of NFS storage and this post is about one of discoveries in such setup.

There are good reasons to have binary logs on NFS volume - binary logs is exactly the thing you want to survive the server crash - using them you can do point in time recovery from backup.

I was testing high volume replication today using Sysbench:

PLAIN TEXT SQL:

1. sysbench --test=oltp --oltp-table-size=10000000 --db-driver=mysql --mysql-user=root --mysql-db=sbsmall --init-rng=1 --max-requests=100000000 --max-time=600 --oltp-test-mode=nontrx --oltp-nontrx-mode=update_nokey --num-threads=8 run

On this box I got …

The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code. So what does this mean for Drupal?

An opcode cache is used to keep compiled PHP code in memory. In a nutshell, when there's a request for a Drupal node, there are all kinds of PHP code that need to  be compiled before PHP can execute that code to query the database, create the webpage, and send it to the browser. The more complex your Drupal site, IE the more modules you have installed, the more PHP code that needs to be compiled. This compilation process occurs on every request to your Drupal site. By installing and enabling an opcode cache, your server will compile all the PHP code once, then store it in memory for later use. When a request happens again for the same PHP code, the opcode …

The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code. So what does this mean for Drupal?

An opcode cache is used to keep compiled PHP code in memory. In a nutshell, when there's a request for a Drupal node, there are all kinds of PHP code that need to  be compiled before PHP can execute that code to query the database, create the webpage, and send it to the browser. The more complex your Drupal site, IE the more modules you have installed, the more PHP code that needs to be compiled. This compilation process occurs on every request to your Drupal site. By installing and enabling an opcode cache, your server will compile all the PHP code once, then store it in memory for later use. When a request happens again for the same PHP code, the opcode …