• Make sure that nothing can access it
  (take it off the load balancer).
• in mysql client do: STOP SLAVE;
• in mysql client do: FLUSH TABLES;
  (if it gets stuck here, then you might need to fix it. You can try UNLOCK TABLES.)
• in command line do: /etc/init.d/mysql stop

...do your what you need to do here...

• in command line do: /etc/init.d/mysql start
  (check for errors, sometimes in my.cnf)
• in mysql client do: START SLAVE;
  (normally this would be done automatically when you restart mysql)
• in mysql client do: SHOW SLAVE STATUS\G
  (check that replication is working properly)
• After you are satisfied, set up the slave server back on the load balancer

The problem I am going to describe is likely to be around since the very beginning of MySQL, however unless you carefully analyse and profile your queries, it might easily go unnoticed. I used it as one of the examples in our talk given at phpDay.it conference last week to demonstrate some pitfalls one may hit when designing schemas and queries, but then I thought it could be a good idea to publish this on the blog as well.

To demonstrate the issue let’s use a typical example – a sales query. Our data is a tiny store directory consisting of three very simple tables:

PLAIN TEXT SQL:

1. CREATE TABLE `products` (
2.   `prd_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
3.   `prd_name` varchar(32) NOT NULL,
4.   PRIMARY KEY (`prd_id`),
5.   KEY …

The implementation of MySQL Monitoring is critical for any organization that uses a database and wants to avoid the inevitable disaster. There are 3 important components that all serve a key purpose to “MySQL Monitoring” in general:

• Monitoring – Historical and graphical information
• Alerting – Tell me when something is wrong
• Dashboard – The State of NOW

Monitoring

There is no one option for Monitoring that is significantly better then another. A short list of what’s on offer can be found at http://monitoring-mysql.com/monitoring-products. What’s important is you have monitoring in place so historically you can review situations and compare across your servers and enabling the better identification of physical or database bottlenecks. My recommendations for products are …

We have secured approval for our final two speakers and now have a full schedule for the 4 day MySQL track at ODTUG Kaleidoscope conference. The conference is in Washington DC from Monday June 28th to Thursday July 1st. Welcome to Josh Sled and Craig Sylvester that will be joining our existing list of speakers.

This conference will include 19 sessions of dedicated MySQL content from Monday thru Thursday by well qualified MySQL community members, as well a forums discussion and reception on Monday night. You don’t need to be an Oracle developer to get the benefit of this conference. We will offering a discount code for MySQL attendees in the upcoming days.

If you are in the DC area, the Monday night forum (known as the sundown sessions) as well as the reception are FREE for the MySQL community. This was a great jesture of the Oracle …

I used to warn people with few details and lots of hand waving that LOAD DATA INFILE should not be run on important MySQL servers in production. I spent a few hours today crashing slaves during LOAD DATA INFILE and now have a much better warning. It should be OK to use LOAD DATA INFILE when the slaves use rpl_transaction_enabled, the loaded table has a primary key and the load doesn't run for a long time.

Replication isn't crash proof on a MySQL slave even when InnoDB is used. I have written about this before and rpl_transaction_enabled fixes the problem for InnoDB. The MySQL docs have a brief warning about the problem and a few other warnings are …

At a customer we had a nice example of how the MySQL Optimizer is cheating when used in combination with the MySQL Cluster. The customer had queries running not too slow in the development environment but when he tried them on the acceptance test environment (with more data) the query was running much too long which was unacceptable because this query can occur many times per second.

What has happened?

First of all we had a look at the execution plan of the query generated by the MySQL Optimizer:

EXPLAIN
SELECT t0.*, t1.*
  FROM t2
  JOIN t0 ON t2.t0_id = t0.id
  JOIN t1 ON t1.t0_id = t0.id
 WHERE t2.productnumber LIKE '%3301'
   AND t0.organization_id = 157
   AND t0.type = 'User';

1 row in set (8.78 sec)

+-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+
| table | type   | possible_keys       | key           | key_len | ref      | rows | Extra …

InnoDB Plugin 1.1 doesn’t add any recovery specific improvements on top of what we already have in Plugin 1.0.7. The details on the latter are available in this blog. Yet, when I tried to recover another big recovery dataset I created, I got the following results for total recovery time:

• Plugin 1.0.7: 46min 21s
• Plugin 1.1: 32min 41s

Plugin 1.1 recovery is 1.5 times faster. Why would that happen? The numerous concurrency improvements in Plugin 1.1 and MySQL 5.5 can’t really affect the recovery. The honor goes to Native Asynchronous IO on Linux. Let’s try without it:

• Plugin 1.1 with –innodb-use-native-aio=0: 49min 07s

which is about the same as 1.0.7 time. My numerous other recovery runs showed that the random fluctuations account for 2-3min of a …

Two examples of escaping data are the following:

• Before you insert a value into a SQL query, using for example mysqli::real_escape_string() or PDO::quote().
• Before you insert data into your output HTML, using htmlspecialchars().

The question I'd like to ask today is, when to do this? There are two possible moments:

1. Right when the data comes in. For SQL this used to be done with 'magic quotes' quite a bit in PHP-land. In general I don't see this happening a lot anymore for SQL. I do however see data encoded using htmlentities/htmlspecialchars before entering the database.
2. The other way to go about it, is to only escape …

The binary version for MySQL Cluster 6.3.33 has now been made available at http://www.mysql.com/downloads/cluster/6.3.html#downloads

A description of all of the changes (fixes) that have gone into MySQL Cluster 6.3.33 (compared to 6.3.32) can be found in the MySQL Cluster 6.3.33 ChangeLog .

Recently I was working with the output of pstack from a hung MySQL server and wanted to use Poor Man's Profiler in order to combine stack traces. Unfortunately, the awk magic expects the output from gdb's thread apply all bt output.

gdb output:

Thread 10 (Thread 0xa644db90 (LWP 26275)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7f33b1a in do_sigwait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7f33bbf in sigwait () from /lib/tls/i686/cmov/libpthread.so.0
#3  0x081cc4fc in signal_hand ()
#4  0xb7f2b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d25e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 9 (Thread 0xa641cb90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select …