zoukankan      html  css  js  c++  java
  • 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:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    
    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/

  • 相关阅读:
    基于Servlet+JSP+JavaBean开发
    jsp&servlet报红线javax.servlet.jsp.XXXX cannot be resolved to a type类似错误解决办法
    java为什么要定义接口等相关解释
    SpringMVC的注解方式
    MyBatis映射
    hibernate、JDBC 实现 oracle ID 的自动增加 功能
    SSH框架的JSP网站添加数据为什么没反应
    又考完一科 又过完一年
    一个招标书文件的需求分析
    《需求分析》读后感之二
  • 原文地址:https://www.cnblogs.com/DataArt/p/10174444.html
Copyright © 2011-2022 走看看