Earlier today I asked on this blog and everywhere else people to fill in a simple survey of how do they use MySQL, which one and what should I focus on. I already have more than 30 answers (don’t stop answering, keep providing more) so I will have to publish the results and do something with them. But first I’ll let the survey run for at least a week Oh, and even though I write MySQL, this post is general about all MySQL variants (MariaDB, MySQL Cluster, … (not counting Drizzle)).
Now what is behind this survey? Well, I have a lot of stuff to do and MySQL is not my only responsibility. And I know that sometimes it can use some extra hands. Sometimes I get lucky and we have new beta packaged same day as it …

This is not really a blog post. I just would like to know you opinion on state of MySQL at openSUSE and openSUSE Build Service. But I’m interested in your feedback even if you are not using openSUSE or even if you are not using packages I provide. As my TODO is quite long and I can’t do everything, I would like to know what should I pay the most attention to. Later I will publish a post about the current state of MySQL and how you can participate

Earlier Peter at Percona posted an interesting article about MySQL upgrades. As a database consultant, it’s not uncommon for me to have enterprise-level customers that still run MySQL 4.0 or 4.1  - for a number of reasons that I will enumerate later, this kind of migration can be tricky. I  just finished such a major upgrade so I will share my opinion on the subject.

The Methodology

If you are in a replicated environment you may want to migrate one of your slaves first as a prototype. Dumping and reloading is the recommended way because of many storage file format changes between 4.0 and 5.0 versions. For heavy databases I usually choose the parallel dump approach to save some precious time, either maatkit’s mk-parallel-dump or domas mituzas’ mydumper tools will do the trick.

Note that binary …

I wrote about my MySQL wishlist on November 14th 2007 and now it's time for an update. I will copy-paste the old entry. The original text will be in italics.

1. Per user and/or per database quota
Would very useful in setups for shared hosting. This would also prevent one database from bringing down the whole server. Separate tablespaces on different mountpoint can ease the pain, but I consider that a nasty hack.
No update. Still problematic

2. External authentication
I've seen numerous scripts which fetch the authentication info from ldap, a file, another database or some other authentication store. This should be integrated into mysql. The mysql grant tables should be pluggable so it is possible to write a custom authentication plugin. We already have plugable engines and function (UDF) so this shouldn't be that hard …

Earlier I reported about two crashes related to MySQL 5.0.22 on Ubuntu 6.06 LTS.

I think those bugs show a lack of testing on the side of Cannonical/Ubuntu. And for MySQL there is a quite good test suite available, so it's not rocketsience.

There are multiple reasons why you could use the MySQL Test Framework:
1. Test if bug you previously experienced exists in the version you are using or planning to use.
2. Test if configuration changes have a good or bad result on the stability of mysqld.
3. Test if important functions still return the correct results (especially importand for financial systems)

$ echo "SELECT @@version;" > version.test
$ cp version.test version.result
$ mysql < version.test >> version.result
$ mysqltest --result-file=version.result …

1. Set this variable
thread_stack = 265K

2. Execute this query
mysql> SELECT 0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0
…

I found a new crasher in the MySQL 5.0 version which ships with Ubuntu 6.06 LTS.

> SELECT * FROM (SELECT mu.User FROM mysql.user mu UNION SELECT mu.user FROM mysql.user mu ORDER BY mu.user) a;
ERROR 2013 (HY000): Lost connection to MySQL server during query

The bug report: LP392236

On MySQL 5.0.51 on Debian stable it returns this error (like it should):
ERROR 1054 (42S22): Unknown column 'mu.user' in 'order clause'

The correct query should be like this (Using culumn a number):
> SELECT * FROM (SELECT mu.User FROM mysql.user mu UNION SELECT mu.user FROM mysql.user mu ORDER BY 1) a;

I've created a very simple MySQL scanning module for the metasploit framework.

1. Download the mysql_version file and rename it to mysql_version.rb and put it in the framework-3.2/modules/auxiliary/scanner/mysql directory of your metasploit installation.
http://compukid.no-ip.org/dev/scripts/mysql_version

2. Use using msfcli
./msfcli auxiliary/scanner/mysql/mysql_version RHOSTS=192.168.0.1 E
[*] 192.168.0.1:3306, MySQL server version: 5.0.81-1-log (Protocol 10)

3. More options:
set THREADS to 10 and RHOSTS to 192.168.0.0/24 to scan a whole network.

Last week, I wrote about an experimental video program that I am coordinating for Mozilla.

I’ve now posted a more complete overview of the program, along with a draft guide for the program testers and an early FAQ on the program.

Helping us in our early stages are the following good and brave souls:

• Alina Mierlus, Free Software/Open Source advocate and a driver of Mozilla.ro
• …

Since Heikki Tuuri and Peter Zaitsev‘s presentations at the MySQL User Conference 2008, I really wanted to try MySQL 5.1 with InnoDB plugin in production work to see how it compares to my current setups (MySQL 5.0.48 with integrated InnoDB).

First of all, the upgrade to MySQL 5.1.23-rc went without any particular quirks – I did not have to dump and reload tables, a simple mysql_upgrade script run was sufficient to put my DB to MySQL 5.1-readiness.

When starting a new MySQL instance you know that you have to do some warm-up work before getting any indicators – the buffer pool will be empty of indexes and data so most operations in the first hour of uptime will be IO-bound. You can also use clever …