• 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/

  • 相关阅读:
    主从复制之GTID(全局事务标识符)
    mysql8之MGR
    Headless Services无头服务
    面试题 01.01. 判定字符是否唯一
    344. 反转字符串
    1299. 将每个元素替换为右侧最大元素
    1528. 重新排列字符串
    832. 翻转图像
    1748. 唯一元素的和
    1365. 有多少小于当前数字的数字
  • 原文地址:https://www.cnblogs.com/DataArt/p/10174444.html
Copyright © 2020-2023  润新知