The Downside of MySQL Auto-reconnect

A few days ago I was doing some cleanup on a passive master database using the MySQL client. I didn’t want my commands to be replicated so I executed set sql_log_bin=0 in my session.

One of my queries dropped an unused schema that I knew was corrupt, so I wasn’t too surprised when the drop database command crashed the MySQL server. After the crash, the server came back up quickly, and my client automatically reconnected, so it was safe to keep running queries right?

Wrong.

When the client reconnected I lost my session state, so sql_log_bin reverted to 1, and any commands I ran from that point forward would be replicated, which I did not want.

This behavior makes sense, and it’s documented in the manual:

Automatic reconnection can be convenient because you need not implement your own reconnect code, but if a reconnection does occur, several aspects of the connection state are reset on the server side and your application will not know about it. The connection-related state is affected as follows:

Any active transactions are rolled back and autocommit mode is reset.

All table locks are released.

All TEMPORARY tables are closed (and dropped).

Session variables are reinitialized to the values of the corresponding variables. This also affects variables that are set implicitly by statements such as SET NAMES.

User variable settings are lost.

Prepared statements are released.

HANDLER variables are closed.

The value of LAST_INSERT_ID() is reset to 0.

Locks acquired with GET_LOCK() are released.

But it’s easy to overlook such details when working with automatic features like MySQL client auto-reconnect. In this specific case I didn’t execute any other commands in the reconnected session so I didn’t inadvertantly replicate anything, but this incident served as a good reminder to be vigilant about my session state when using the MySQL client.

Here’s a snippet from my session to show the value of sql_log_bin before and after the crash:

mysql> set sql_log_bin = 0;

Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_log_bin;

+---------------+

| @@sql_log_bin |

+---------------+

|             0 |

+---------------+

1 row in set (0.00 sec)

mysql> drop database test;

Query OK, 1 row affected (0.19 sec)

mysql> select @@sql_log_bin;

+---------------+

| @@sql_log_bin |

+---------------+

|             0 |

+---------------+

1 row in set (0.00 sec)

mysql> drop database reports;

ERROR 2013 (HY000): Lost connection to MySQL server during query

mysql> select @@sql_log_bin;

ERROR 2006 (HY000): MySQL server has gone away

No connection. Trying to reconnect...

Connection id:    505

Current database: *** NONE ***

+---------------+

| @@sql_log_bin |

+---------------+

|             1 |

+---------------+

1 row in set (0.00 sec)

https://mechanics.flite.com/blog/2013/05/03/the-downside-of-mysql-auto-reconnect/

巴特西

The Downside of MySQL Auto-reconnect

最新文章

热门文章