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/

  • 相关阅读:
    Linux(Centos7)yum安装最新redis
    refresh table tablename ;MSCK REPAIR TABLE table_name;
    整个shuffle的流程图
    Vim简明教程
    centos vim 7.3 升级 + vim 简单配置文件
    Python——可变类型与不可变类型(即为什么函数默认参数要用元组而非列表)
    python——修饰符
    转——《将人性置之死地而后生》刘夙
    各学科领域入门书籍推荐
    python——关于Python Profilers性能分析器
  • 原文地址:https://www.cnblogs.com/DataArt/p/10174444.html
Copyright © 2011-2022 走看看