Perfectly solves the problem of a large number of Got an error reading communication packets in MySQL error log.

Recently, after installing mysql, I found that a large number of read and write errors such as Got an error reading communication packets appeared in the error log, as shown below
Insert image description here

problem analysis

In fact, Aborted connection alarms are difficult to avoid. There will be more or less a small amount of Aborted connection information in the error log. This situation can be ignored. However, when Aborted connection alarms appear frequently in your error log, you should pay attention to it. , it may have a greater impact on the business.

possible factors

  • A client attempts to access a database but has no privileges for
    it.(没有权限)

  • A client uses an incorrect password.

  • A connection packet does not contain the right
    information.

  • It takes more than connect_timeout seconds to obtain a connect
    packet. (The time it takes for connect_timeout to obtain connection information)

  • The client program did not call mysql_close() before
    exiting.(The client did not call the mysql_close() function)

  • The client had been sleeping more than wait_timeout or
    interactive_timeout seconds without issuing any requests to the
    server. (The client's empty connection time was too long, exceeding wait_timeout and interactive_timeout time)

Ideas

Aborted_clients和Aborted_connects

Please check if these two statuses are normal first

mysql> show global status like '%abort%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 32    |
| Aborted_connects | 45533 |
+------------------+-------+
2 rows in set (0.03 sec)

Possible reasons for the increase Aborted_connectsin status variables:

The client tried to access the database but did not have database permissions.
The wrong password was used on the client side.
The client connection packet does not contain the correct information.
It takes more than connect_timeout seconds to obtain a connection packet.

Possible reasons for the increase Aborted_clientsin state variables:

The client program did not call mysql_close() before the program exited.
The client sleep time exceeds the number of seconds specified by the wait_timeout or interactive_timeout parameters.
The client program terminated suddenly during data transfer.

If it is normal, the state variable may not be that high,
Insert image description here
so let’s start with the following methods.

Solution

max_allowed_packet

Parameters that are too small may cause abnormal operation, but the maximum value of max_allowed_packet is 1G (1073741824). If the setting exceeds 1G, the final effective result will only be 1G.

1. Temporary solution, modify the value

mysql> show variables like 'max_allowed_packet';
+--------------------+------------+
| Variable_name      | Value      |
+--------------------+------------+
| max_allowed_packet | 1073741824 |
+--------------------+------------+
1 row in set (0.04 sec)

set global max_allowed_packet = 10 * 1024 * 1024;

2. However, restarting Mysql will still restore the default value, so it needs to be written in the configuration file.

#永久性解决方案:
#修改方法1(配置文件持久化修改):
vim /etc/my.cnf

[mysqld]
max_allowed_packet = 100M
timeout

Mainly due to wait_timeout, interactive_timeoutthese two parameter values, when MySQL is connected, the server's default "wait_timeout" is 8 hours, which means that if a connection is idle for more than 8 hours, Mysql will automatically disconnect the connection. If connections are idle for more than 8 hours, Mysql will disconnect them, and the DBCP connection pool does not know that the connection has expired. If a Client requests a connection at this time, DBCP will provide the expired Connection to the Client, which will cause an exception.

The default value of interactive_timeout is 28800.
The default value of wait_timeout is: 120

mysql> show global variables like '%timeout%';
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| have_statement_timeout      | YES      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 50       |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| rpl_stop_slave_timeout      | 31536000 |
| slave_net_timeout           | 60       |
| wait_timeout                | 28800    |
+-----------------------------+----------+
13 rows in set (0.05 sec)

Therefore, if this time is too small, it may cause abnormalities. Increase it according to the situation. These two values ​​​​are a global variable and can be dynamically increased

 set global interactive_timeout=28800;
timestamp

Please check whether your database time is synchronized with your system or server

mysql> select current_timestamp() from dual;
+---------------------+
| current_timestamp() |
+---------------------+
| 2021-04-27 09:32:10 |
+---------------------+
1 row in set (0.00 sec)

If it is different, then modify the configuration file, for example:

    [mysqld]
    max_allowed_packet=256M
    default-time_zone = '+8:00'
log_warnings

#Set the log_warnings parameter to 1

mysql> select @@log_warnings;
+----------------+
| @@log_warnings |
+----------------+
|              2 |
+----------------+
1 row in set

Set the log_warnings parameter to 1

mysql> set global log_warnings=1;

Query OK, 0 rows affected

mysql> select @@log_warnings;
+----------------+
| @@log_warnings |
+----------------+
|              1 |
+----------------+
1 row in set

At this time, the large number of logs above will not appear in the error log.

The official log_warningexplanation is this

Original English text

rint out warnings such as Aborted connection… to the error log. This option is enabled (1) by default. To disable it, use --log-warnings=0. Specifying the option without a level value increments the current value by 1. Enabling this option by setting it greater than 0 is recommended, for example, if you use replication (you get more information about what is happening, such as messages about network failures and reconnections). If the value is greater than 1, aborted connections are written to the error log, and access-denied errors for new connection attempts are written. See Section B.3.2.10, “Communication Errors and Aborted Connections”.
If a replica server was started with --log-warnings enabled, the
replica prints messages to the error log to provide information about
its status, such as the binary log and relay log coordinates where it
starts its job, when it is switching to another relay log, when it
reconnects after a disconnect, and so forth. The server logs messages
about statements that are unsafe for statement-based logging if
–log-warnings is greater than 0.

translate

Print out warnings such as Aborted connection... error log. This option is enabled by default (1). To disable it, use --log-warnings=0. Specifying the option without a level value increases the current value by 1. It is recommended to enable this option by setting it greater than 0, for example if you use replication (you will get more information about what is going on, such as messages about network failures and reconnections). If the value is greater than 1, aborted connections are written to the error log and access denied errors for new connection attempts are written. See Section B.3.2.10, “Communication Errors and Aborted Connections”.
If --log-warnings is enabled on replica server startup, the replica server
will print messages to the error log to provide information about its status, such as binary log and relay log coordinates (when it starts working, switch to another When relaying logs, when to start). Disconnect and reconnect, and so on. If --log-warnings is greater than 0
, the server will log messages about statements that are unsafe for statement-based logging.

Do you understand? Anyway, I didn’t understand. I still said what I said at the beginning: In fact, Aborted connection alarms are difficult to avoid. There will be more or less a small amount of Aborted connection information in the error log. This situation can be ignored, but when Aborted connection frequently appears in your error log Alarms should be paid attention to at this time, as they may have a greater impact on the business.
Some people will choose to set –log-warnings to 0, which is completely disabled, but it is not necessary. We filter out unnecessary logs and set the level to 1.

Summary
The above four points are my solutions to Got an error reading communication packets. In fact, there are also factors such as timeout, lack of permissions, wrong password, wrong connection configuration, etc.
——————————————
Copyright Statement: This article is an original article by CSDN blogger “Kangkang Lai” and follows the CC 4.0 BY-SA copyright agreement. Please attach the original source link for reprinting and this statement.
Original link: https://blog.csdn.net/KangKangShenShen/article/details/116208961

Guess you like

Origin blog.csdn.net/fth1002853070/article/details/132402247