Querying a statement that takes more than 30s actually takes more than 2 minutes.
mysql> select version(); +------------+ | version() | +------------+ | 5.6.30-log | +------------+ 1 row in set (0.12 sec) mysql> select * from message_1707 where create_date >'2017-01-01' limit 10; ERROR 2013 (HY000): Lost connection to MySQL server during query mysql> show variables like 'innodb_buffer_pool_size'; +-------------------------+------------+ | Variable_name | Value | +-------------------------+------------+ | innodb_buffer_pool_size | 3221225472 | +-------------------------+------------+ 1 row in set (0.00 sec)
Official reference: https://dev.mysql.com/doc/refman/5.7/en/error-lost-connection.html, after the adjustment, the net_read_timeout problem remains the same. At this time, it is found that the company's network packet loss seems to be quite serious. The remote server was changed from Alibaba Cloud DNAT to SLB, and the same problem persisted after adjustment.
Another detail is captured below. The second query prompts to reconnect to the database, indicating that the database has been restarted, and no other colleagues remotely operate the machine during this period.
mysql> select * from message_1707 where create_date >'2017-01-01' limit 10; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 16 Current database: bluestore_core_log ERROR 2013 (HY000): Lost connection to MySQL server during query
Looking at the system log, the mysqld service has indeed been restarted, but there is no detailed error message
[root@HD1_db_archive ~]# tail -f /var/log/mysqld.log 2018-04-26 15:29:54 17062 [Note] InnoDB: 128 rollback segment(s) are active. 2018-04-26 15:29:54 17062 [Note] InnoDB: Waiting for purge to start 2018-04-26 15:29:54 17062 [Note] InnoDB: 5.6.30 started; log sequence number 164799934660 2018-04-26 15:29:54 17062 [Note] Server hostname (bind-address): '*'; port: 3306 2018-04-26 15:29:54 17062 [Note] IPv6 is available. 2018-04-26 15:29:54 17062 [Note] - '::' resolves to '::'; 2018-04-26 15:29:54 17062 [Note] Server socket created on IP: '::'. 2018-04-26 15:29:54 17062 [Note] Event Scheduler: Loaded 0 events 2018-04-26 15:29:54 17062 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.6.30-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL) 180426 15:31:53 mysqld_safe Number of processes running now: 0 180426 15:31:53 mysqld_safe mysqld restarted 2018-04-26 15:31:53 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.30-log) starting as process 17143 ... 2018-04-26 15:31:53 17143 [Note] Plugin 'FEDERATED' is disabled. 2018-04-26 15:31:53 17143 [Note] InnoDB: Using atomics to ref count buffer pool pages 2018-04-26 15:31:53 17143 [Note] InnoDB: The InnoDB memory heap is disabled 2018-04-26 15:31:53 17143 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2018-04-26 15:31:53 17143 [Note] InnoDB: Memory barrier is not used 2018-04-26 15:31:53 17143 [Note] InnoDB: Compressed tables use zlib 1.2.3 2018-04-26 15:31:53 17143 [Note] InnoDB: Using Linux native AIO 2018-04-26 15:31:53 17143 [Note] InnoDB: Using CPU crc32 instructions 2018-04-26 15:31:53 17143 [Note] InnoDB: Initializing buffer pool, size = 3.0G 2018-04-26 15:31:53 17143 [Note] InnoDB: Completed initialization of buffer pool 2018-04-26 15:31:53 17143 [Note] InnoDB: Highest supported file format is Barracuda. 2018-04-26 15:31:53 17143 [Note] InnoDB: The log sequence numbers 164799934660 and 164799934660 in ibdata files do not match the log sequence number 164799934670 in the ib_logfiles! 2018-04-26 15:31:53 17143 [Note] InnoDB: Database was not shutdown normally! 2018-04-26 15:31:53 17143 [Note] InnoDB: Starting crash recovery. 2018-04-26 15:31:53 17143 [Note] InnoDB: Reading tablespace information from the .ibd files... 2018-04-26 15:31:53 17143 [Note] InnoDB: Restoring possible half-written data pages 2018-04-26 15:31:53 17143 [Note] InnoDB: from the doublewrite buffer... 2018-04-26 15:31:54 17143 [Note] InnoDB: 128 rollback segment(s) are active. 2018-04-26 15:31:54 17143 [Note] InnoDB: Waiting for purge to start 2018-04-26 15:31:54 17143 [Note] InnoDB: 5.6.30 started; log sequence number 164799934670 2018-04-26 15:31:54 17143 [Note] Server hostname (bind-address): '*'; port: 3306 2018-04-26 15:31:54 17143 [Note] IPv6 is available. 2018-04-26 15:31:54 17143 [Note] - '::' resolves to '::'; 2018-04-26 15:31:54 17143 [Note] Server socket created on IP: '::'. 2018-04-26 15:31:54 17143 [Note] Event Scheduler: Loaded 0 events 2018-04-26 15:31:54 17143 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.6.30-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
In fact, it is normal to query large tables at the beginning. I have adjusted innodb_buffer_pool_size = 3G. The machine with 4G before normal does not configure this item, and the default value is used. After changing to 2G, the query becomes normal (the solution is to reduce the innodb_buffer_pool_size) .
mysql> select * from message_1707 where create_date >'2017-01-01' limit 10; +----------+--------------------+--------------------+---------------------+-----------------+-------------+------------+---------------------------+---------------------+ | id | content | expressNo | receive_date | receiver_mobile | send_result | express_id | error_desc | create_date | +----------+--------------------+--------------------+---------------------+-----------------+-------------+------------+---------------------------+---------------------+ | 32089073 | Notification of successful pickup | 280589800000 | 2016-12-31 16:33:01 | 1847633xxxx | 0 | 18897191 | | 32089074 | Notification of successful pickup | 667193800000 | 2016-12-31 12:22:04 | 1885927xxxx | 0 | 18878152 | | 32089075 | Notification of successful pickup | VIP_NH0100000002 | 2016-12-31 12:24:46 | 1360601xxxx | 0 | 18878542 | | 32089076 | Notification of successful pickup | 883942483995100000 | 2016-12-31 13:29:31 | 1385005xxxx | 0 | 18884697 | | 32089077 | Notification of successful pickup | 211365200000 | 2016-12-31 12:22:43 | 1332832xxxx | 0 | 18878245 | | 32089078 | Notification of successful pickup | 533148560000 | 2016-12-31 10:45:45 | 1598583xxxx | 0 | 18864370 | | 32089079 | Notification of successful pickup | 221034880000 | 2016-12-31 10:58:43 | 1563761xxxx | 0 | 18866152 | | 32089080 | Notification of successful pickup | 423871440000 | 2016-12-31 20:36:46 | 1571135xxxx | 0 | 18904861 | | 32089081 | Notification of successful pickup | 3937050300000 | 2016-12-31 12:16:46 | 1571156xxxx | 0 | 18877449 | | 32089082 | Notification of successful pickup | 423922650000 | 2016-12-31 16:36:22 | 1870828xxxx | 0 | 18897502 | +----------+--------------------+--------------------+---------------------+-----------------+-------------+------------+---------------------------+---------------------+ 10 rows in set (2 min 15.37 sec) mysql> show variables like 'innodb_buffer_pool_size'; +-------------------------+------------+ | Variable_name | Value | +-------------------------+------------+ | innodb_buffer_pool_size | 2147483648 | +-------------------------+------------+ 1 row in set (0.00 sec)
Then check the introduction of the innodb_buffer_pool_size option on the official website according to the ideas provided by netizens: https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html
I haven't found an introduction to this item in 5.6. The official website states that innodb_buffer_pool_size must be a multiple of innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances, but 5.6 does not have the innodb_buffer_pool_chunk_size parameter. When I wrote 3G in the configuration file, it was also 3G through mysql statistics. To check here, you may need to open debug, and you don't have the energy to toss. If you change the innodb_buffer_pool_size, you won't have to worry about it.
mysql> SELECT @@innodb_buffer_pool_size/1024/1024/1024; +------------------------------------------+ | @@innodb_buffer_pool_size/1024/1024/1024 | +------------------------------------------+ | 3.000000000000 | +------------------------------------------+