We also have patch in work for 5.0.67

If you need patch for 5.0.61 or any other version we can do backport on consulting basics.

Is it possible to update the patch to 5.0.61? Thanks.

First, I enabled the general query log in my production server, and collected some data. I let it run for 60 hours (2 1/2 days), which captured peak times, and all typical usage.
I used a trick to turn off the general query log without restarting mysql - i moved the log file aside, touched a replacement, but didn’t give the mysql user write permision to it. I then used mysqladmin to flush all the logs, and when it couldn’t open a handle to the new general query log file, it simply stopped logging.

Now, get an identical piece of hardware as your production server - preferably built by clonig the HDD so you have identical OS and filesystem layout.
Recompile the same version of mysql, with this patch applied (we compile mysql from source ourselves anyway, so this is still a fair performance test). Get the database on it current up to the point you turned on the general query log.
To do this, i used a backup from a few weeks earlier, and used mysqlbinlog to extract the rest of the data from the binary logs, up until the start point. I could actually see the last line in the catchup sql matching one of the first in the general query log, so rewinded one second, and knew i was spot on.
You now have an identical server, with data in a state ready to be benchmarked.
It’s worth taking a database dump here, in case you want to run the benchmark again.

Now pump your query log acquired earlier through the below perl script. It’s very quick, very dirty, and probably very buggy, but seemed to work acceptably well in our case.
It rebuilds the timing, connections, and queries the server saw, based on the contents of query log - it creates a seperate thread for each connection, and runs each query at (about) the right time, relative to the start of the run.
That means if you have 60 hours worth of dump data, the script will run for 60 hours replaying it. This was important for us, because we have short bursts of very high load, long periods of quite low load, and even the odd moment of practically zero load. This recreates all of them, just like they were in real life.
It’s worth running this script on a seperate box with lot’s of cores - it’s very thread-hungry.

The script (replay_query_log.pl):

#!perl

use Time::Local;
use DBI();

# Setup who your DB host host, and a hash of copnnection passwords.
# You need one password entry for each user that connects
# in the logs you want to replay - you can get by grepping
# for ‘Connect’, and using cut/sed/sort/uniq liberally.
#
my $DBHOST=”slush”;
my %passwords = ( “user” => “pass”,
“reporting” => “reporting”,
“user-no-pw” => “”,
“etc” => “etc”
);

# skip the first 3 lines
();
();
();

# Process the query log, and build a couple of hashes from it:
#
# Hash 1: %queries - keyed by connection id and datetime,
# - is an array of all queries by that connection at that time.
# Hash 2: %starttime - keyed by connection id
# - contains the time the first query run by this conenction started
#
# The first hash is used to actually runt he queries, the second is used to
# avoid fork bombing the box, by only forking the processes when needed.

while ()
{
# datetime line
if(s/^(0[0-9])([01][0-9])([0-3][0-9])\s+(1?[0-9]):([0-5][0-9]):([0-5][0-9])//)
{
# Convert to unix epoch - makes date arithmetic dead easy.
$datetime = Time::Local::timelocal($6, $5, $4, $3, $2-1, “20″.$1);
$dt_min = $datetime if (($datetime < $dt_min) || !(defined $dt_min));
}
# query type line
if(s/^\s+([0-9]+) ((Query)|(Quit)|(Connect)|(Statistics)|(Binlog Dump Log))//)
{
# If we enter this loop, it means a new query/type has started.
# Save the old one (if it exists), and reinitialise the vars
# for the next
push @{$queries{$connection}{$datetime}}, $query if length($query);
$connection = $1;
$starttime{$connection} = $datetime if (($datetime $_)
{
sleep $now - $_;
}
# Now that the threads are due to start, we fork, and connect
foreach (@{$startconn{$_}})
{
my $conn = $_;
my $DBUSER = $dbun{$conn}[0];
my $DBNAME = $dbun{$conn}[1];
my $DBPASS = $passwords{$DBUSER};
my $pid = fork();
if($pid == 0)
{
###print “forked\n”;
my $dbh;
# Each connection has multiple queries, so we
# iterate the hash, waiting for the correct time
# to run each one.
# I use while(){ sleep 1 } rather than sleep n to
# avoid timing issues - this garauntees the query will
# run within +/- 0.5s of when it’s due, which is good
# enough for our purposes (usually).
foreach (sort keys %{$queries{$conn}})
{
my $dt = $_;
while((time() - $offset) connect(”DBI:mysql:database=$DBNAME;host=$DBHOST”,
“$DBUSER”, “$DBPASS”)
|| die “Couldn’t create dbh”;
}
foreach (@{$queries{$conn}{$_}})
{
my $sth = $dbh->prepare($_);
$sth->execute();
$sth->finish();
}
}
$dbh->disconnect();
###print “died\n”;
exit; # very important.
} else
{
# Don’t do this.
#waitpid($pid,0);
}
}
}

# done!!!

I got some quite interesting numbers our of it, and have learned a lot about how our database behaves.

Now - this is not a well tested script - it’s probably rife with bugs, so use with caution. Any bugfixes, enhancements, or comments - please post them back here.

Hopefully this will help some-one else out.