Summary of various MySQL problems and solutions

Original link of this article: https://blog.csdn.net/xzk9381/article/details/114872726

1. MySQL 5.7 Thread Blocking Solution

1.1 Problem description

An error is reported when executing the statement in the database: ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction.

1.2 Solution

View the threads in the current database

show full processlist;

If you don’t see the slow sql record thread being executed, check the INNODB_TRX transaction table to see if there is a locked transaction thread, and see if trx_mysql_thread_id is in the sleep thread in the show full processlist. If it is, it proves The thread transaction of this sleep has been stuck without commit or rollback, we need to manually kill it, for example, kill 32735

2. MySQL 5.7 is slow when connecting to the database remotely

2.1 Problem description

Use the mysql command to remotely access the database. After entering the password, you need to wait for 5s-10s to complete the connection, causing the background service to throw an exception.

2.2 Causes of the problem

Every time it accesses the database, mysql will try to resolve the domain name of the accessed machine. If it cannot be resolved at this time, it will fail after a period of time before the data can be retrieved.

2.3 Solution

Add the skip-name-resolve configuration item under [mysqld] in the mysql configuration file to prohibit domain name resolution, and restart the database to take effect

3. MySQL 5.7 binary installation error

3.1 Problem description

Use the binary installation package to install MySQL 5.7 in centos6.8 (minimal installation) and report an error:

error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

3.2 Solution

The libaio library is not installed by default during the minimal installation of CentOS, and you need to install it manually

yum install libaio-devel

4. Solution to the problem of truncated data using group concat function in MySQL 5.7

4.1 Problem description

When the GROUP_CONCAT function is called for query, the query does not stop and does not return any data (there is also a situation where the data queried is truncated, and the longest length does not exceed 1024 bytes)

4.2 Cause of the problem

The reason for this problem is that the official default group_concat_max_len configuration is 1024, which will limit the length of GROUP_CONCAT data. You can use the following command to query:

mysql> show variables like 'group_concat_max_len';
+----------------------+--------+
| Variable_name        | Value  |
+----------------------+--------+
| group_concat_max_len |  1024  |
+----------------------+--------+
1 row in set (0.05 sec)

# 官方手册对该配置的定义是：The maximum permitted result length in bytes for the GROUP_CONCAT() function

4.3 Solution

You can adjust group_concat_max_len to the maximum value of 18446744073709551615 (or set according to the maximum length of the actual return of the business)

Modify the MySQL configuration file, add group_concat_max_len = 18446744073709551615 (permanent effective) under [mysqld]
Set in the console (temporarily effective)

SET GLOBAL group_concat_max_len=18446744073709551615;
SET SESSION group_concat_max_len=18446744073709551615;

5. MySQL 报 ERROR: Packet for query is too large (2034> 1024)

5.1 Problem description

An error is reported when data is stored:

ERROR: Packet for query is too large (2034> 1024). You can change this value on the server by setting the max_allowed_packet’ variable.

5.2 Solution

Use the following command to view the max_allowed_packet setting in the current database

mysql> show variables like '%max_allowed_packet%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| max_allowed_packet       | 1024       |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
2 rows in set (0.00 sec)

# 这里显示max_allowed_packet的大小只有1M

Add or modify max_allowed_packet=128M in the my.cnf configuration file [mysqld], and restart mysql to take effect. If the value of max_allowed_packet is restored to 1024 after a period of time, you need to query whether the memory of the current server is insufficient, which will cause MySQL to automatically reset the parameter to 1024, and reserve enough memory to solve the problem.

6. MySQL 5.7 error "Waiting for table metadata lock" solution

6.1 Problem description

When performing DDL operations such as alt table in MySQL 5.7, the operation is blocked and cannot be executed. Use show processlist to view and find that the alt table operation of the table shows Waiting for table metadata lock.

6.2 Cause of the problem

When performing DDL operations such as alt table in MySQL 5.7, if there are uncommitted transactions in the table, the Waiting for table metadata lock state will appear

6.3 Solution

Use the following command to view uncommitted transactions from information_schema.innodb_trx. Generally, as long as these threads are killed, DDL operations will not be Waiting for table metadata lock

select trx_state, trx_started, trx_mysql_thread_id, trx_query from information_schema.innodb_trx \G

# 字段说明：
# trx_state: 事务状态，一般为RUNNING
# trx_started: 事务执行的起始时间，若时间较长，则要分析该事务是否合理
# trx_mysql_thread_id: MySQL的线程ID，用于kill
# trx_query: 事务中的sql

Adjust the lock timeout threshold. lock_wait_timeout represents the timeout (in seconds) for acquiring the metadata lock, and the allowed value range is 1 to 31536000 (1 year). The default value is 31536000, adjust it to 30 minutes

set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;

Original link of this article: https://blog.csdn.net/xzk9381/article/details/114872726

7. Solution to MySQL error 1418 (HY000)

7.1 Problem description

After MySQL opens bin-log, an error with error number 1418 will occur when calling stored procedures or functions and triggers:

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)

7.2 Cause of the problem

Because CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, ALTER FUNCTION, CALL, DROP PROCEDURE, DROP FUNCTION and other statements will be written into the binary log, and then executed on the slave server. However, an indeterminate subroutine (stored procedure, function, trigger) that performs an update is not repeatable. Execution on the slave server (relative to the master server is repeated execution) may cause the restored data to be different from the original data. A situation where the server is different from the main server.

In order to solve this problem, MySQL mandates that on the main server, unless the subprogram is declared deterministic or does not change the data, the creation or replacement of the subprogram will be rejected. This means that when creating a subroutine, you must either declare that it is deterministic or that it does not change the data.

There are two ways to declare:

The statement is deterministic: DETERMINISTIC and NOT DETERMINISTIC indicate whether a subroutine always produces the same result for a given input. If no feature is given, the default is NOT DETERMINISTIC, so DETERMINISTIC must be specified explicitly to declare that a subroutine is deterministic. What I want to explain here is: using the NOW() function (or its synonyms) or the RAND() function will not make a subroutine non-deterministic. For NOW(), the binary log includes a timestamp and will be executed correctly. RAND() can be copied correctly as long as it is called once in a subroutine. Therefore, it can be considered that the timestamp and the random number seed are deterministic inputs to the subroutine, and they are the same on the master server and the slave server.
Declare whether the data will be changed: CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL is used to indicate whether the subroutine reads or writes data.
Both NO SQL and READS SQL DATA point out that the subroutine does not change the data, but one of them must be specified explicitly, because if any is specified, the default specification is CONTAINS SQL.

In other words, when bin-log is turned on, you must specify whether the created function is of the following types:

DETERMINISTIC: Uncertain
NO SQL: There is no SQl statement, and of course the data will not be modified
READS SQL DATA: just read the data, of course it will not modify the data
MODIFIES SQL DATA: To modify the data
CONTAINS SQL: Contains SQL statements

By default, if CREATE PROCEDURE or CREATE FUNCTION statements are allowed to be accepted, one of DETERMINISTIC or NO SQL and READS SQL DATA must be specified explicitly, otherwise a 1418 error will be generated.

7.3 Solution

There are two solutions:

When creating a subroutine (stored procedure, function, trigger), declare it as one of DETERMINISTIC or NO SQL and READS SQL DATA

CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`()
    DETERMINISTIC
BEGIN
 #Routine body goes here...
END;

Trust the creator of the subroutine, prohibit the requirement of SUPER authority when creating or modifying the subroutine, set log_bin_trust_routine_creators=1

# 方法1，在mysql控制台中直接修改（临时生效）
SET GLOBAL log_bin_trust_function_creators = 1;

# 方法二，在MySQL启动时，加上--log-bin-trust-function-creators选项，参数设置为1

# 方法三，在my.cnf配置文件[mysqld]中添加如下内容，重启后生效
log-bin-trust-function-creators = 1

8. Solutions to MySQL error Communications link failure

8.1 Problem description

The tomcat process reports an error after connecting to the database:

Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.)

8.2 Causes of the problem

According to the error message, it can be judged that the connection in the connection pool is invalid, that is, the valid time wait_timeout has expired. After logging in to mysql, check that the valid time of wait_timeout is 28800, which is 8 hours.

mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)

8.3 Solution

Modify the wait_timeout attribute and increase the value to 31536000 (365 days, the maximum value of linux is one year)

# 在my.cnf配置文件中，[mysqlId]下添加wati_timeout、interactive_timeout属性，重启mysql
wait_timeout = 31536000
interactive_timeout = 31536000

9. ERROR 1129 (00000)…is blocked because of many connection errors

9.1 Problem description

An error is reported when connecting to the database:

ERROR 1129 (00000): #HY000Host ‘192.168.31.242’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’

9.2 Cause of the problem

There are too many connection errors (too many connection attempts), exceeding the number of max_connection_errors configuration items in the configuration file.

9.3 Solution

Enter the following command on the mysql server to clear the cache

mysqladmin flush-hosts -uroot -p

Add the following configuration in the my.cnf configuration file [mysqld] and restart the database

max_connection_errors = 1000

10. MySQL5.7查询时报错：[Err] 1055 - Expression #1 of SELECT list is not in GROUP BY clause…this is incompatible with sql_mode=only_full_group_by

10.1 Problem description

Migrating the database from version 5.5 to version 5.7, the detailed error message when executing the query statement is as follows:

[Err] 1055 - Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column ‘cdxc.a.id’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

10.2 Cause of the problem

In MySQL 5.7, sql_mode is set to ONLY_FULL_GROUP_BY by default. To use this is to use the same group rules as oracle. Select columns must be in the group, or they must be aggregate columns (SUM, AVG, MAX, MIN).

10.3 Solution

Query the current sql_mode configuration

mysql> select @@sql_mode;
+--------------------------------+
| @@sql_mode					 |                                 
+--------------------------------+
|ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+--------------------------------+
1 row in set (0.04 sec)

Remove ONLY_FULL_GROUP_BY in the configuration, write the rest of the configuration under [mysqld] in the configuration file, and restart the database service, the format is as follows

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Or directly enter the following content in the database (need to exit the database and re-enter to take effect)

set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

11. MySQL5.7报错Incorrect datetime value: ‘0000-00-00 00:00:00’ for column

11.1 Problem description

mysql5.7 reports an error when executing sql statement import: mysql 5.7 Error: Incorrect datetime value: '0000-00-00 00:00:00' for column xxx

11.2 Causes of the problem

Starting from version 5.7, datetime no longer supports the format of '0000-00-00 00:00:00'.

11.3 Solution

Replace the SQL statement that contains '0000-00-00 00:00:00' with '1970-01-01 00:00:01' in the SQL statement to be imported

sed -i 's/0000-00-00 00:00:00/1970-01-01 00:00:01/g' test.sql

Modify sql_mode, delete NO_ZERO_IN_DATE and NO_ZERO_DATE in sql_mode

# 查询sql_mode
select @@sql_mode;

# 在控制台中重新设置sql_mode
set global sql_mode='STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION';

# 在配置文件[mysqld]中添加如下内容重新设置sql_mode
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

12. MySQL 5.7 报错：Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

12.1 Problem description

When large transactions such as batch updates or deletions of MySQL are performed, the following errors will be reported:

Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again

12.2 Cause of the problem

This is because large transactions of updates and deletions will write a large number of binlogs, which may cause the binlog cache to be too small and cause execution failures. There will also be cases where the master library executes successfully but the slave library is out of sync. This is because although the max_binlog_cache_size parameters of the master and slave are set the same, the actual binlog cache used is not necessarily the same, which leads to the interruption of the master-slave replication due to the small binlog cache.

12.3 Solution

First check the max_binlog_cache_size currently set in MySQL:

mysql> show variables like 'max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+

Check that the value of this parameter setting is 134217728, which is 128M (128 * 1024 * 1024), and set it to a suitable size, for example, 256M:

# 在控制台中设置
mysql> set global max_binlog_cache_size=268435456;
Query OK, 0 rows affected (0.05 sec)

# 在配置文件 [mysqld] 中添加如下内容进行设置
max_binlog_cache_size = 256M

Original link of this article: https://blog.csdn.net/xzk9381/article/details/114872726