Lorsque j'essaie d'envoyer une requête à une instance DB RDS exécutant le moteur MySQL Server, je reçois le message d'erreur « Le serveur MySQL a disparu » ou « La connexion au serveur a été perdue lors de la requête ».

La raison la plus courante de cette erreur est un dépassement du délai d'attente du serveur entraînant la fermeture de la connexion. Dans ce cas, vous recevez généralement l'un des codes d'erreur suivants :

Code d'erreur

Description

CR_SERVER_GONE_ERROR

Le client n'a pas pu envoyer une question au serveur.

CR_SERVER_LOST

Le client n'a pas reçu de message d'erreur en écrivant au serveur, mais il n'a pas reçu la réponse complète à la question (voire aucune réponse).

Examinez les causes et résolutions possibles suivantes de cette erreur :

  • Cette erreur peut se produire lorsqu'une connexion est restée inactive pendant une longue période et que le client n'a pas correctement mis fin à cette connexion. Dans ce cas, vérifiez que les délais d'attente des applications sont plus courts que les délais d'attente MySQL et veillez à ce que vos applications ferment les connexions inactives.
  • Si vous préférez une résolution rapide moins élégante, vous pouvez essayer d'augmenter les délais d'attente MySQL en augmentant la valeur des paramètres « wait_timeout » et « interactive_timeout » à l'aide d'un groupe de paramètres personnalisé.
  • Si la requête qui génère l'erreur récupère un ensemble de données volumineux, vous devrez peut-être augmenter la valeur du paramètre de taille « max_allowed_packet » à l'aide d'un groupe de paramètres personnalisé.
  • Si cette erreur se produit uniquement lors du renvoi d'ensembles de données volumineux, il est possible que le client utilise la grande valeur MTU 9001. Dans ce cas, vous souhaiterez peut-être réduire la valeur MTU de la configuration TCP/IP du client. Pour en savoir plus sur la modification de la valeur MTU de votre client, consultez Configuration de la valeur MTU d'une instance. Pour en savoir plus sur les valeurs MTU et les trames Jumbo, consultez Unité de transmission maximale (MTU) du réseau pour votre instance EC2.
  • Vérifiez que tous les paramètres « init_connect » sont correctement traités. Si la valeur affectée à l'un de ces paramètres empêche son traitement, les connexions client associées risquent d'échouer. Vérifiez que l'utilisateur dispose de l'autorisation EXECUTE sur les procédures référencées par un paramètre « init_connect ». Par exemple, lors de la mise en œuvre de la procédure de modification du fuseau horaire décrite dans le billet de blog Changing MySQL timezone on Amazon RDS, si l'utilisateur ne dispose pas de l'autorisation EXECUTE sur la procédure décrite, les connexions de cet utilisateur échouent lorsque le paramètre « init_connect » associé n'est pas traité.
  • Vérifiez que les autres connexions sont toujours en cours d'exécution lorsque ce problème se produit. Si toutes les connexions s'interrompent simultanément, le problème n'est probablement pas spécifique à la connexion. Dans ce cas, vérifiez que l'instance DB MySQL n'est pas en panne ou défaillante en consultant les événements Amazon RDS ainsi que les journaux des erreurs MySQL.
  • Consultez la documentation MySQL B.5.2.9 MySQL server has gone away pour voir les autres causes et résolutions possibles de ce problème.

RDS, MySQL, perte de connexion, dépassement de délai, CR_SERVER_GONE_ERROR, CR_SERVER_LOST, instance DB, groupe de paramètres


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support.

Date de publication : 23/11/2015