Introduction

• wait_timeout
• interactive_timeout
• net_read_timeout
• net_write_timeout

What do these timeouts do in MySQL? If you search the web for one or more of these, you may find complaints that no comprehensive explanation exists for all of these timeouts in one place (besides the obvious documentation of dynamic server system variables in MySQL). This blog post seeks to provide a central documentation source for timeouts and provide some practical explanation.

Knowing what timeouts do helps in a troubleshooting effort. It’s good to understand when an issue is timeout related and when it’s not, and to know the right reasons for changing timeout variables, or the right time to ask the developer or ad-hoc user to please tune the variables in the session, instead of …

If you see the “Waiting for table metadata lock” error, you may be wondering what is the best course of action to prevent it in the future. I have briefly discussed troubleshooting metadata locks before, however, that post more illustrated how easy it is to encounter the “Waiting for table metadata lock” error in both MyISAM and InnoDB. It provides simple examples for reproducing using both storage engines, so one could hopefully more easily identify where the locks are stemming from in their particular case.

Pin-pointing which transaction holds the locks is a different story. There are feature requests filed in MySQL and MariaDB bugs databases to track this information, but they are recent, and no ETA is scheduled for either yet, as far as I know:

http://bugs.mysql.com/bug.php?id=69527 …

When InnoDB appears hung, I know the natural reaction is to check SHOW ENGINE INNODB STATUS.

In fact, it’s the first thing I check when InnoDB tables are involved.

However, I just want to iterate how valuable SHOW FULL PROCESSLIST and/or mysqladmin debug outputs can be even when it seems mysqld is hung on on InnoDB table.

Two recent cases I’ve encountered illustrate why.

Case #1:

MySQL appeared hung on the following simple, single-row INSERT:

---TRANSACTION 0 2035648699, ACTIVE 76629 sec, process no 9047,
OS thread id 3069426592, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
...
INSERT INTO test (id, parent, text) VALUES (180370, 70122, 'test table')

At least that’s what it seemed per the INNODB STATUS, but unfortunately, there wasn’t any further information to go on.

The next time it occurred, SHOW FULL PROCESSLIST was captured at the time.

…

There are several parameters to set a timeout on MySQL :

But I would like to focus on wait_timeout (or interactive_timeout depending on how you connect)

This timeout allows MySQL to automatically close a connection in case of non-activity during the time defined by this parameter (default value is 28000 seconds).

The problem I wish to explain here may happen when this timeout is set to a low value (about 10 to 30 seconds).

Indeed, in this case, this timeout may have serious consequences, look at that :
[The wait_timeout parameter is set to 10 seconds in this case]

You are connected through the standard MySQL client and you need to run a delete query (bypass autocommit) :

• mysql> start transaction; …

There are several parameters to set a timeout on MySQL :

But I would like to focus on wait_timeout (or interactive_timeout depending on how you connect)

This timeout allows MySQL to automatically close a connection in case of non-activity during the time defined by this parameter (default value is 28000 seconds).

The problem I wish to explain here may happen when this timeout is set to a low value (about 10 to 30 seconds).

Indeed, in this case, this timeout may have serious consequences, look at that :
[The wait_timeout parameter is set to 10 seconds in this case]

You are connected through the standard MySQL client and you need to run a delete query (bypass autocommit) :

• mysql> start transaction;
• [ You …

When running query against a database the following error can be generated:

ERROR 2006 (HY000) at line NNN: MySQL server has gone away

Where "NNN" is the line number of the script currently being run where the error occurred.

Possible Causes and Resolution

This is a general error which can have a number of possible causes. The one certainty is that the MySQL database is no longer listening on

What makes you think jdbc autoreconnect is needed?
Application is idle for long periods at a time?
Wait_timeout too short?
Network failure or glitches?

Some good suggestions form Mark Matthews - Bug #5020

Having encountered the problem again myself today, trying to make jdbc for mysql reconnect any terminated connections using autoreconnect=true I figured out a way to work it out from the pooling side.


Introduction to the problem:

On the mysql side wait_timeout is set to default 8hrs and any connections idle for longer than that were beomg terminated despite setting the connection string to: url=jdbc:mysql://localhost:3306/dbname?autoReconnect=true. The application was thence throwing an exception.

The solution was to introduce a ping from the pooler which for “Ibatis”, the pooler technology used …