Certaines autres raisons courantes pour lesquelles le serveur MySQL a disparu sont :
-
Vous (ou l'administrateur de la base de données) avez tué le thread en cours d'exécution avec une instruction KILL ou une commande mysqladmin kill.
-
Vous avez tenté d'exécuter une requête après avoir fermé la connexion au serveur. Cela indique une erreur de logique dans l'application qui doit être corrigée.
-
Une application client exécutée sur un hôte différent ne dispose pas des privilèges nécessaires pour se connecter au serveur MySQL à partir de cet hôte.
-
Vous avez obtenu un délai d'expiration de la connexion TCP/IP côté client. Cela peut arriver si vous avez utilisé les commandes :mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) ou mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...). Dans ce cas, augmenter le délai peut aider à résoudre le problème.
-
Vous avez rencontré un timeout côté serveur et la reconnexion automatique dans le client est désactivée (le drapeau de reconnexion dans la structure MYSQL est égal à 0).
-
Vous utilisez un client Windows et le serveur a interrompu la connexion (probablement parce que wait_timeout a expiré) avant que la commande ne soit émise.
-
Le problème sous Windows est que, dans certains cas, MySQL n'obtient pas d'erreur du système d'exploitation lors de l'écriture sur la connexion TCP/IP au serveur, mais l'obtient à la place lorsqu'il essaie de lire la réponse à partir de la connexion.
-
La solution à cela est soit de faire un mysql_ping () sur la connexion s'il s'est écoulé beaucoup de temps depuis la dernière requête (c'est ce que fait Connector/ODBC) ou de définir wait_timeout sur le serveur mysqld si haut qu'il en pratique jamais fois sortie.
-
Vous pouvez également obtenir ces erreurs si vous envoyez une requête au serveur qui est incorrecte ou trop volumineuse. Si mysqld reçoit un paquet trop volumineux ou en panne, il suppose que quelque chose s'est mal passé avec le client et ferme la connexion. Si vous avez besoin de requêtes volumineuses (par exemple, si vous travaillez avec de grandes colonnes BLOB), vous pouvez augmenter la limite de requête en définissant la variable max_allowed_packet du serveur, qui a une valeur par défaut de 4 Mo. Vous devrez peut-être également augmenter la taille maximale des paquets côté client. Plus d'informations sur la configuration de la taille de paquet sont données dans la Section B.5.2.10, « Paquet trop grand ».
-
Une instruction INSERT ou REPLACE qui insère un grand nombre de lignes peut également provoquer ce type d'erreurs. L'une ou l'autre de ces instructions envoie une seule requête au serveur quel que soit le nombre de lignes à insérer; ainsi, vous pouvez souvent éviter l'erreur en réduisant le nombre de lignes envoyées par INSERT ou REPLACE.
-
Vous obtenez également une connexion perdue si vous envoyez un paquet de 16 Mo ou plus si votre client est antérieur à 4.0.8 et votre serveur est 4.0.8 et supérieur, ou l'inverse.
-
Il est également possible de voir cette erreur si les recherches de nom d'hôte échouent (par exemple, si le serveur DNS sur lequel repose votre serveur ou votre réseau tombe en panne). En effet, MySQL dépend du système hôte pour la résolution des noms, mais n'a aucun moyen de savoir s'il fonctionne. Du point de vue de MySQL, le problème est indiscernable de tout autre délai d'attente du réseau.
-
Vous pouvez également voir l'erreur Le serveur MySQL a disparu si MySQL est démarré avec l'option --skip-networking.
-
Un autre problème de réseau pouvant provoquer cette erreur se produit si le port MySQL (3306 par défaut) est bloqué par votre pare-feu, empêchant ainsi toute connexion au serveur MySQL.
-
Vous pouvez également rencontrer cette erreur avec des applications qui fork des processus enfants, qui essaient tous d'utiliser la même connexion au serveur MySQL. Cela peut être évité en utilisant une connexion distincte pour chaque processus enfant.
-
Vous avez rencontré un bogue où le serveur est mort lors de l'exécution de la requête.
Vérifiez ce lien :Gone Away
