Salut à toutes et tous !
Au sein de notre pôle d’administration à distance AllDB, nous traitons depuis presque 20 ans des incidents de base de données. Notre base d’incidents renferme un peu plus d’1 million de problèmes divers et variés sur 5 à 6 moteurs de base de données différents. Chaque incident s’étant produit une à plusieurs fois, pour vous donner un ordre d’idée rien que sur la partie MySQL / MariaDB qui est la moins représentée dans le volume d’incidents générés, nous avons recensé 1.2 milliard d’occurrences de codes erreurs depuis 2005, sur un échantillon de versions allant de la 3.23 à la 8.0 aujourd’hui.
Ce qu’on voulait vous proposer c’est une petite vulgarisation des codes erreurs principaux que nous avons rencontré au fil des années, de ce qu’ils signifient et comment corriger ces erreurs. Cette série va commencer avec MySQL/MariaDB mais se poursuivra avec les autres moteurs SQL Server, Oracle, PostgreSQL, etc…
Comprendre l’erreur Lost connection to MySQL server during query
Cette erreur générique indique simplement que le serveur MySQL ne perçoit plus de signe du programme à l’autre bout du canal d’une connexion cliente. Le problème peut survenir à toutes les étapes du cycle de vie d’une connexion : à son établissement , au milieu de l’exécution d’une requête, lorsque la connexion est inactive depuis un certain temps, lorsque l’instance est saturée et ne prend plus de connexions, ou que le serveur est injoignable (stoppé : MySQL Server has gone away), ou enfin lors d’un transfert de données massives entre le client et le serveur.
Elle sera souvent accompagnée d’un autre message qui précise l’origine du problème, par exemple ici il s’agit de la connexion entre un slave de réplication et le master:
121010 17:32:18 [Note] Start binlog_dump to slave_server(2), pos(mysql-bin.000020, 4137470) 121010 17:34:02 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013) 121010 17:34:02 [Note] Slave I_O thread: Failed reading log event, reconnecting to retry, log mysql-bin.000012 at position 107
Dans ce cas il se peut que le réseau sont coupé entre les 2 machines ou services, ou que le master soit lui-même stoppé. Cela vient du fonctionnement de type pull de la réplication où le slave IO streame les positions ou GTIDs depuis les binlogs du master vers des relaylogs locaux. Il est connecté en permanence via une connexion classique et est donc sujets aux mêmes problèmes que les connections clientes.
Résoudre l’erreur Lost connection to MySQL server during query
Il faut commencer par identifier la cause, qui on l’a vu peut être multiple:
- Le serveur MySQL est-il démarré et en capacité de répondre à une demande de connexion ? utiliser mysqlping par exemple pour valider que le serveur est disponible
- Le réseau est-il coupé entre le client et le serveur : firewall, panne réseau, etc… Utiliser un client telnet par exemple avec le nom de l’hôte et le port (par défaut TCP3306) pour valider que le flux est ouvert.
- Si vous étiez en train de transférer des données (mysqldump, mysqlpump ou LOAD DATA INFILE) il se peut qu’une partie des données dépasse le payload réseau client ou serveur, vérifier vos valeurs de max_allowed_packet des 2 côtés.
- Côté métrologie, vérifier la valeur de ‘Aborted Connects’ à intervalles réguliers pour évaluer s’il s’agit d’un problème isolé ou d’un blocage global.
MariaDB [(none)]> show global status like 'Aborted_connects' ; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | Aborted_connects | 2245 | +------------------+-------+ 1 row in set (0.000 sec)
Pour retrouver toute la série sur les codes erreurs, c’est par ici : https://blog.capdata.fr/index.php/category/codes-erreur/ !
Continuez votre lecture sur le blog :
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
- Que faire des “[Warning] Aborted connection” avec MySQL ? (Benjamin VESAN) [MySQL]
- Déplacer le répertoire de données (datadir) MySQL vers un nouvel emplacement sur Debian (Capdata team) [MySQL]
- Migrer d’un cluster Galera MariaDB 10.3 vers MariaDB 10.5 avec la réplication logique (David Baffaleuf) [ContainerMySQLNon classé]
- Nouveautés MySQL 8.0 : Variables persistés (Capdata team) [MySQL]