Lien original de cet article: https://blog.csdn.net/xzk9381/article/details/114872726
1. Solution de blocage des threads MySQL 5.7
1.1 Description du problème
Une erreur est signalée lors de l'exécution de l'instruction dans la base de données: ERREUR 1205 (HY000): Délai d'attente de verrouillage dépassé; essayez de redémarrer la transaction.
1.2 Solution
- Afficher les fils dans la base de données actuelle
show full processlist;
- Si vous ne voyez pas le thread d'enregistrement SQL lent en cours d'exécution, vérifiez la table des transactions INNODB_TRX pour voir s'il existe un thread de transaction qui est verrouillé, et voyez si trx_mysql_thread_id est dans le thread de veille dans la liste de processus show full. Si tel est le cas, cela prouve que la transaction de thread de ce sommeil a été bloquée sans validation ni annulation, nous devons la tuer manuellement, par exemple, tuer 32735
2. MySQL 5.7 est lent lors de la connexion à distance à la base de données
2.1 Description du problème
Utilisez la commande mysql pour accéder à distance à la base de données. Après avoir entré le mot de passe, vous devez attendre 5 s-10 s pour terminer la connexion, ce qui fait que le service d'arrière-plan lève une exception.
2.2 Causes du problème
Chaque fois qu'il accède à la base de données, mysql essaiera de résoudre le nom de domaine de la machine accédée. S'il ne peut pas être résolu à ce moment, il échouera après un certain temps avant que les données puissent être récupérées.
2.3 Solution
Ajoutez l'élément de configuration skip-name-resolution sous [mysqld] dans le fichier de configuration mysql pour interdire la résolution de nom de domaine, et redémarrez la base de données pour prendre effet
3. Erreur d'installation binaire MySQL 5.7
3.1 Description du problème
Utilisez le package d'installation binaire pour installer MySQL 5.7 dans centos6.8 (installation minimale) et signaler une erreur:
erreur lors du chargement des bibliothèques partagées: libaio.so.1: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type
3.2 Solution
La bibliothèque libaio n'est pas installée par défaut lors de l'installation minimale de CentOS, et vous devez l'installer manuellement
yum install libaio-devel
4. Solution au problème des données tronquées à l'aide de la fonction group concat dans MySQL 5.7
4.1 Description du problème
Lorsque la fonction GROUP_CONCAT est appelée pour la requête, la requête ne s'arrête pas et ne renvoie aucune donnée (il existe également une situation où les données interrogées sont tronquées et la plus longue longueur ne dépasse pas 1024 octets)
4.2 Cause du problème
La raison de ce problème est que la configuration officielle par défaut de group_concat_max_len est 1024, ce qui limitera la longueur des données GROUP_CONCAT. Vous pouvez utiliser la commande suivante pour interroger:
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
Vous pouvez ajuster group_concat_max_len à la valeur maximale de 18446744073709551615 (ou définir en fonction de la durée maximale du retour réel de l'entreprise)
- Modifiez le fichier de configuration MySQL, ajoutez group_concat_max_len = 18446744073709551615 (permanent effectif) sous [mysqld]
- Défini dans la console (temporairement effectif)
SET GLOBAL group_concat_max_len=18446744073709551615;
SET SESSION group_concat_max_len=18446744073709551615;
5. MySQL 报 ERREUR: le paquet pour la requête est trop volumineux (2034> 1024)
5.1 Description du problème
Une erreur est signalée lors du stockage des données:
ERREUR: le paquet pour la requête est trop volumineux (2034> 1024). Vous pouvez modifier cette valeur sur le serveur en définissant la variable max_allowed_packet '.
5.2 Solution
- Utilisez la commande suivante pour afficher le paramètre max_allowed_packet dans la base de données actuelle
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
- Ajoutez ou modifiez max_allowed_packet = 128M dans le fichier de configuration my.cnf [mysqld], et redémarrez mysql pour prendre effet. Si la valeur de max_allowed_packet est restaurée à 1024 après un certain temps, vous devez demander si la mémoire du serveur actuel est insuffisante, ce qui obligera MySQL à réinitialiser automatiquement le paramètre à 1024 et réserver suffisamment de mémoire pour résoudre le problème.
6. Erreur MySQL 5.7 "En attente du verrouillage des métadonnées de la table"
6.1 Description du problème
Lors de l'exécution d'opérations DDL telles que la table alt dans MySQL 5.7, l'opération est bloquée et ne peut pas être exécutée. Utilisez show processlist pour voir et trouver que l'opération alt table de la table indique En attente de verrouillage des métadonnées de la table.
6.2 Cause du problème
Lors de l'exécution d'opérations DDL telles que la table alt dans MySQL 5.7, s'il y a des transactions non validées dans la table, l'état En attente de verrouillage des métadonnées de la table apparaîtra
6.3 Solution
- Utilisez la commande suivante pour afficher les transactions non validées à partir de information_schema.innodb_trx. En règle générale, tant que ces threads sont supprimés, les opérations DDL n'attendront pas le verrouillage des métadonnées de la table.
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
- Ajustez le seuil de délai de verrouillage. lock_wait_timeout représente le délai (en secondes) pour l'acquisition du verrou de métadonnées, et la plage de valeurs autorisée est comprise entre 1 et 31536000 (1 an). La valeur par défaut est 31536000, ajustez-la à 30 minutes
set session lock_wait_timeout = 1800;
set global lock_wait_timeout = 1800;
Lien original de cet article: https://blog.csdn.net/xzk9381/article/details/114872726
7. Solution à l'erreur MySQL 1418 (HY000)
7.1 Description du problème
Une fois que MySQL a ouvert bin-log, une erreur avec le numéro d'erreur 1418 se produira lors de l'appel de procédures stockées ou de fonctions et de déclencheurs:
ERREUR 1418 (HY000): Cette fonction n'a aucun de DETERMINISTIC, NO SQL ou READS SQL DATA dans sa déclaration et la journalisation binaire est activée (vous pouvez utiliser la variable moins sûre log_bin_trust_function_creators)
7.2 Cause du problème
Parce que CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, ALTER FUNCTION, CALL, DROP PROCEDURE, DROP FUNCTION et d'autres instructions seront écrites dans le journal binaire, puis exécutées sur le serveur esclave. Cependant, un sous-programme indéterminé (procédure stockée, fonction, déclencheur) qui effectue une mise à jour n'est pas répétable. L'exécution sur le serveur esclave (par rapport au serveur maître est une exécution répétée) peut entraîner des données restaurées différentes des données d'origine. A situation où le serveur est différent du serveur principal.
Afin de résoudre ce problème, MySQL impose que sur le serveur principal, à moins que le sous-programme ne soit déclaré déterministe ou ne modifie pas les données, la création ou le remplacement du sous-programme sera rejeté. Cela signifie que lors de la création d'un sous-programme, vous devez soit déclarer qu'il est déterministe, soit qu'il ne modifie pas les données.
Il existe deux façons de déclarer:
- L'instruction est déterministe: DETERMINISTIC et NOT DETERMINISTIC indiquent si un sous-programme produit toujours le même résultat pour une entrée donnée. Si aucune fonctionnalité n'est donnée, la valeur par défaut est NOT DETERMINISTIC, donc DETERMINISTIC doit être spécifié explicitement pour déclarer qu'un sous-programme est déterministe. Ce que je veux expliquer ici, c'est que l'utilisation de la fonction NOW () (ou de ses synonymes) ou de la fonction RAND () ne rendra pas un sous-programme non déterministe. Pour NOW (), le journal binaire comprend un horodatage et sera exécuté correctement. RAND () peut être copié correctement tant qu'il est appelé une fois dans un sous-programme. Par conséquent, on peut considérer que l'horodatage et la graine de nombre aléatoire sont des entrées déterministes dans le sous-programme, et ils sont les mêmes sur le serveur maître et le serveur esclave.
- Déclarez si les données seront modifiées: CONTAINS SQL, NO SQL, READS SQL DATA, MODIFIES SQL est utilisé pour indiquer si le sous-programme lit ou écrit des données.
NO SQL et READS SQL DATA indiquent que le sous-programme ne modifie pas les données, mais que l'un d'entre eux doit être spécifié explicitement, car s'il en est spécifié, la spécification par défaut est CONTAINS SQL.
En d'autres termes, lorsque bin-log est activé, vous devez spécifier si la fonction créée est des types suivants:
- DÉTERMINISTE: Incertain
- NO SQL: Il n'y a pas d'instruction SQl, et bien sûr les données ne seront pas modifiées
- LISE LES DONNÉES SQL: il suffit de lire les données, bien sûr cela ne modifiera pas les données
- MODIFIE LES DONNÉES SQL: Pour modifier les données
- CONTAINS SQL: contient des instructions SQL
Par défaut, si les instructions CREATE PROCEDURE ou CREATE FUNCTION peuvent être acceptées, l'une des instructions DETERMINISTIC ou NO SQL et READS SQL DATA doit être spécifiée explicitement, sinon une erreur 1418 sera générée.
7.3 Solution
Il existe deux solutions:
- Lors de la création d'un sous-programme (procédure stockée, fonction, déclencheur), déclarez-le comme l'un des DETERMINISTIC ou NO SQL et READS SQL DATA
CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`()
DETERMINISTIC
BEGIN
#Routine body goes here...
END;
- Faites confiance au créateur du sous-programme, interdisez l'exigence de l'autorité SUPER lors de la création ou de la modification du sous-programme, définissez 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 à l'erreur MySQL Échec de la liaison de communication
8.1 Description du problème
Le processus tomcat signale une erreur après la connexion à la base de données:
Provoqué par: org.apache.commons.dbcp.SQLNestedException: impossible de créer PoolableConnectionFactory (échec de la liaison de communication Le dernier paquet envoyé avec succès au serveur remonte à 0 milliseconde. Le pilote n'a reçu aucun paquet du serveur.)
8.2 Causes du problème
Selon le message d'erreur, il peut être jugé que la connexion dans le pool de connexions n'est pas valide, c'est-à-dire que le temps valide wait_timeout a expiré. Après vous être connecté à mysql, vérifiez que la durée valide de wait_timeout est de 28800, soit 8 heures.
mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.01 sec)
8.3 Solution
Modifiez l'attribut wait_timeout et augmentez la valeur à 31536000 (365 jours, la valeur maximale de linux est d'un an)
# 在my.cnf配置文件中，[mysqlId]下添加wati_timeout、interactive_timeout属性，重启mysql
wait_timeout = 31536000
interactive_timeout = 31536000
9. ERREUR 1129 (00000)… est bloquée en raison de nombreuses erreurs de connexion
9.1 Description du problème
Une erreur est signalée lors de la connexion à la base de données:
ERREUR 1129 (00000): # HY000Host '192.168.31.242' est bloqué en raison de nombreuses erreurs de connexion; débloquer avec 'mysqladmin flush-hosts'
9.2 Cause du problème
Il y a trop d'erreurs de connexion (trop de tentatives de connexion), dépassant le nombre d'éléments de configuration max_connection_errors dans le fichier de configuration.
9.3 Solution
- Entrez la commande suivante sur le serveur mysql pour vider le cache
mysqladmin flush-hosts -uroot -p
- Ajoutez la configuration suivante dans le fichier de configuration my.cnf [mysqld] et redémarrez la base de données
max_connection_errors = 1000
10. MySQL5.7 查询 时 报错 ： [Err] 1055 - L'expression n ° 1 de la liste SELECT n'est pas dans la clause GROUP BY… c'est incompatible avec sql_mode = only_full_group_by
10.1 Description du problème
Migrez la base de données de la version 5.5 vers la version 5.7, et le message d'erreur détaillé lors de l'exécution de l'instruction de requête est le suivant:
[Err] 1055 - L'expression n ° 1 de la liste SELECT n'est pas dans la clause GROUP BY et contient la colonne non agrégée 'cdxc.a.id' qui n'est pas fonctionnellement dépendante des colonnes de la clause GROUP BY; ceci est incompatible avec sql_mode = only_full_group_by
10.2 Cause du problème
Dans MySQL 5.7, sql_mode est défini sur ONLY_FULL_GROUP_BY par défaut. Pour l'utiliser, vous devez utiliser les mêmes règles de groupe qu'Oracle. Les colonnes de sélection doivent être dans le groupe ou elles doivent être des colonnes d'agrégation (SUM, AVG, MAX, MIN).
10.3 Solution
- Interroger la configuration actuelle de sql_mode
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)
- Supprimez ONLY_FULL_GROUP_BY dans la configuration, écrivez le reste de la configuration sous [mysqld] dans le fichier de configuration et redémarrez le service de base de données, le format est le suivant
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
- Ou entrez directement le contenu suivant dans la base de données (besoin de quitter la base de données et de le ressaisir pour prendre effet)
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 报错 Valeur datetime incorrecte: «0000-00-00 00:00:00» pour la colonne
11.1 Description du problème
mysql5.7 signale une erreur lors de l'exécution d'une instruction SQL import: mysql 5.7 Erreur: valeur datetime incorrecte: '0000-00-00 00:00:00' pour la colonne xxx
11.2 Causes du problème
À partir de la version 5.7, datetime ne prend plus en charge le format «0000-00-00 00:00:00».
11.3 Solution
- Remplacez l'instruction SQL qui contient «0000-00-00 00:00:00» par «1970-01-01 00:00:01» dans l'instruction SQL à importer
sed -i 's/0000-00-00 00:00:00/1970-01-01 00:00:01/g' test.sql
- Modifiez sql_mode, supprimez NO_ZERO_IN_DATE et NO_ZERO_DATE dans 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 报错 ： La transaction multi-instruction nécessitait plus de «max_binlog_cache_size» octets de stockage; augmentez cette variable mysqld et réessayez
12.1 Description du problème
Lorsque des transactions importantes telles que des mises à jour par lots ou des suppressions de MySQL sont effectuées, les erreurs suivantes seront signalées:
Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this mysqld variable and try again
12.2 Cause du problème
Cela est dû au fait que de grandes transactions de mises à jour et de suppressions écriront un grand nombre de journaux binaires, ce qui peut rendre le cache du journal binaire trop petit et provoquer des échecs d'exécution. Il y aura également des cas où la bibliothèque maître s'exécute avec succès mais la bibliothèque esclave n'est pas synchronisée. En effet, bien que les paramètres max_binlog_cache_size du maître et de l'esclave soient définis de la même manière, le cache binlog utilisé n'est pas nécessairement le même, ce qui provoque l'interruption de la réplication maître-esclave car le cache binlog est trop petit.
12.3 Solution
Vérifiez d'abord la taille max_binlog_cache_size actuellement définie dans MySQL:
mysql> show variables like 'max_binlog_cache_size';
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| max_binlog_cache_size | 134217728 |
+-----------------------+-----------+
Vérifiez que la valeur de ce paramètre est 134217728, soit 128 Mo (128 * 1024 * 1024), et définissez-la sur une taille appropriée, par exemple, 256 Mo:
# 在控制台中设置
mysql> set global max_binlog_cache_size=268435456;
Query OK, 0 rows affected (0.05 sec)
# 在配置文件 [mysqld] 中添加如下内容进行设置
max_binlog_cache_size = 256M
Lien original de cet article: https://blog.csdn.net/xzk9381/article/details/114872726