Identification des problèmes de connectivité des bases de données Collecte de données sur les problèmes de connectivité Surveillance des connexions à la base de données Codes d’erreur de connectivité Recommandations de réglage des paramètres Exemples de résolution des problèmes de connexion à la base de données

Résolution des problèmes de connexion aux bases de données Aurora MySQL

Garantir une connectivité fiable entre vos applications et votre instance de base de données RDS est crucial pour le bon fonctionnement de vos charges de travail. Cependant, les problèmes de connectivité peuvent survenir en raison de divers facteurs, tels que les configurations réseau, les problèmes d’authentification ou les contraintes de ressources. Ce guide vise à fournir une approche complète pour résoudre les problèmes de connectivité rencontrés avec Aurora MySQL.

Table des matières

Identification des problèmes de connectivité des bases de données avec Aurora MySQL

L’identification de la catégorie spécifique du problème de connectivité permet de déterminer les causes potentielles et d’orienter le processus de résolution des problèmes. Chaque catégorie peut nécessiter des approches et des techniques différentes pour le diagnostic et la résolution. Les problèmes de connectivité des bases de données peuvent généralement être classés dans les catégories suivantes.

Erreurs et exceptions de connexion

Des erreurs et exceptions de connexion peuvent se produire pour diverses raisons, telles qu’une chaîne de connexion incorrecte, un échec d’authentification, une interruption du réseau ou un problème sur le serveur de base de données. Parmi les causes figurent une configuration erronée des paramètres de connexion, des identifiants non valides, une défaillance du réseau ou un crash/redémarrage du serveur de base de données. Les groupes de sécurité mal configurés, les paramètres du cloud privé virtuel (VPC), les listes de contrôle d'accès réseau ACLs () et les tables de routage associées aux sous-réseaux peuvent également entraîner des problèmes de connexion.

Limite de connexion atteinte

Ce problème survient lorsque le nombre de connexions simultanées au serveur de base de données dépasse la limite maximale autorisée. Les serveurs de bases de données sont généralement soumis à une limite maximale de connexions configurable, définie par le paramètre max_connections dans les groupes de paramètres de cluster et d’instance. En imposant une limite de connexion, le serveur de base de données s’assure qu’il dispose de suffisamment de ressources (par exemple, mémoire, CPU et descripteurs de fichiers) pour gérer efficacement les connexions existantes et fournir des performances acceptables. Parmi les causes citons des fuites de connexion dans l’application, un regroupement de connexions inefficace ou une augmentation inattendue du nombre de demandes de connexion.

Délai d’expiration de connexion

Les délais d’expiration de connexion se produisent lorsque l’application cliente ne parvient pas à établir une connexion avec le serveur de base de données dans le délai imparti. Parmi les causes les plus fréquentes figurent des dysfonctionnements réseau, une saturation du serveur, des règles de pare-feu ou une configuration incorrecte des paramètres de connexion.

Délai d’expiration de connexion inactive

Les connexions inactives qui restent inactives pendant une période prolongée peuvent être fermées automatiquement par le serveur de base de données pour économiser les ressources. Ce délai d’expiration est généralement configurable à l’aide de wait_timeout et interactive_timeout parameters. Il doit être ajusté en fonction des modèles d’utilisation des connexions de l’application. Les causes peuvent être liées à une logique d’application qui laisse des connexions inactives trop longtemps, ou à une gestion inadéquate des connexions.

Déconnexion intermittente des connexions existantes

Cette catégorie d’erreurs fait référence à un scénario dans lequel les connexions établies entre une application cliente et la base de données sont interrompues de façon inattendue ou déconnectées à intervalles irréguliers, alors qu’elles sont actives et en cours d’utilisation. Ces déconnexions se produisent de manière intermittente, c’est-à-dire à des intervalles irréguliers et de façon non prévisible. Voici les causes possibles :

Problèmes liés au serveur de base de données, tels que les redémarrages ou les basculements
Mauvaise gestion des connexions d’applications
Problèmes d’équilibrage de charge et de proxy
Instabilité réseau
Problèmes liés aux composants tiers ou aux intergiciels impliqués dans le chemin de connexion
Délais d’expiration d’exécution de requête
Contraintes de ressources côté serveur ou côté client

Il est essentiel d’identifier la cause première à l’aide d’une surveillance, d’une journalisation et d’une analyse approfondies. La mise en œuvre de mécanismes adaptés de gestion des erreurs, de regroupement des connexions et de nouvelles tentatives peut contribuer à réduire l’impact de ces déconnexions intermittentes sur les fonctionnalités de l’application et sur l’expérience utilisateur.

Collecte de données sur les problèmes de connectivité pour Aurora MySQL

La collecte de données complètes relatives aux composants de l’application, de la base de données, du réseau et de l’infrastructure est essentielle pour résoudre efficacement les problèmes de connectivité entre une application et une base de données Aurora MySQL. En collectant les journaux, les configurations et les données de diagnostic pertinents, vous obtenez des informations précieuses qui peuvent vous aider à identifier la cause première des problèmes de connectivité et à vous guider vers une résolution appropriée.

Les journaux et les configurations réseau, tels que les règles des groupes de sécurité, les paramètres de VPC et les tables de routage, sont essentiels pour identifier d’éventuels goulots d’étranglement ou des erreurs de configuration réseau susceptibles d’empêcher la connexion entre l’application et la base de données. En analysant ces composants réseau, vous pouvez vous assurer que les ports nécessaires sont ouverts, que les adresses IP sont autorisées et que les configurations de routage sont correctement configurées.

Horodatages

Enregistrez les horodatages exacts lorsque les problèmes de connectivité surviennent. Cette approche permet d’identifier des modèles ou de corréler les problèmes avec d’autres événements ou activités.

Journaux du moteur de base de données

Outre les journaux généraux de la base de données, consultez les journaux du moteur de base de données (par exemple, le journal d’erreurs MySQL et le journal des requêtes lentes) pour obtenir toute information pertinente ou erreur susceptible d’être liée aux problèmes de connectivité intermittents. Pour plus d’informations, consultez Journalisation pour les bases de données Aurora MySQL.

Journaux d’applications clientes

Collectez des journaux détaillés à partir des applications clientes qui se connectent à la base de données. Les journaux d’application offrent une visibilité sur les tentatives de connexion, les erreurs et toute autre information pertinente du point de vue de l’application, susceptibles de révéler des problèmes liés aux chaînes de connexion, aux informations d’identification d’authentification ou à la gestion des connexions dans l’application.

Les journaux de base de données, quant à eux, fournissent des informations sur les erreurs liées à la base de données, la lenteur des requêtes ou les événements susceptibles de contribuer aux problèmes de connectivité. Pour plus d’informations, consultez Journalisation pour les bases de données Aurora MySQL.

Variables d’environnement du client

Vérifiez si des variables d'environnement ou des paramètres de configuration côté client peuvent affecter la connexion à la base de données, tels que les paramètres du proxy, SSL/TLS les paramètres ou toute autre variable pertinente.

Versions de la bibliothèque cliente

Assurez-vous que le client utilise les dernières versions de tous les pilotes de base de données, bibliothèques ou frameworks utilisés pour la connectivité aux bases de données. Les versions obsolètes peuvent présenter des problèmes connus ou des problèmes de compatibilité.

Capture réseau du client

Effectuez une capture réseau côté client à l’aide d’un outil tel que Wireshark ou tcpdump lorsque des problèmes de connectivité surviennent. Cette opération peut contribuer à identifier les problèmes ou irrégularités liés au réseau côté client.

Topologie réseau du client

Il est important de bien comprendre la topologie réseau du client, notamment la présence éventuelle de pare-feux, d’équilibreurs de charge ou d’autres composants (tels que RDS Proxy ou Proxy SQL) qui se connectent à la base de données à la place du client.

Paramètres du système d’exploitation client

Vérifiez les paramètres du système d’exploitation du client susceptibles d’affecter la connectivité réseau, tels que les règles de pare-feu, les paramètres de l’adaptateur réseau et tout autre paramètre pertinent.

Configuration du regroupement de connexions

Si vous utilisez un mécanisme de regroupement de connexions dans votre application, passez en revue les paramètres de configuration et surveillez les métriques du regroupement (par exemple, les connexions actives, les connexions inactives et les délais d’expiration des connexions) pour vous assurer que le groupe fonctionne correctement. Vérifiez également les paramètres du regroupement, tels que la taille maximale du groupe, la taille minimale du groupe et les paramètres de validation de connexion, pour vous assurer qu’ils sont correctement configurés.

Chaîne de connexion

La chaîne de connexion inclut généralement des paramètres tels que le nom d’hôte ou de point de terminaison, le numéro de port, le nom de la base de données et les informations d’identification d’authentification. L’analyse de la chaîne de connexion permet d’identifier les erreurs de configuration potentielles ou les paramètres incorrects susceptibles de provoquer des problèmes de connectivité. Par exemple, un nom d’hôte ou un numéro de port incorrect peut empêcher le client d’accéder à l’instance de base de données, tandis que des informations d’identification d’authentification non valides peuvent entraîner des échecs d’authentification et des rejets de connexion. En outre, la chaîne de connexion peut révéler des problèmes liés au regroupement des connexions, aux délais d’expiration ou à d’autres paramètres spécifiques à la connexion susceptibles de contribuer aux problèmes de connectivité. La fourniture de la chaîne de connexion complète utilisée par l’application cliente permet d’identifier les erreurs de configuration sur le client.

Métriques de base de données

Surveillez les indicateurs de base de données tels que l'utilisation du processeur, de la mémoire et du disque I/O lorsque des problèmes de connectivité surviennent. Elles permettent de déterminer si l’instance de base de données est confrontée à des problèmes de contention des ressources ou de performances.

Version du moteur de base de données

Notez la version du moteur de base de données Aurora MySQL. AWS publie régulièrement des mises à jour visant à résoudre des problèmes connus, corriger des failles de sécurité et améliorer les performances. Par conséquent, nous vous recommandons vivement de passer aux dernières versions disponibles, car ces mises à jour incluent souvent des corrections de bogues et des améliorations spécifiquement liées à la connectivité, aux performances et à la stabilité. Fournir les informations de version de la base de données, ainsi que les autres informations collectées, peut aider Support à diagnostiquer et à résoudre efficacement les problèmes de connectivité.

Métriques de réseau

Collectez des métriques de réseau tels que la latence, la perte de paquets et le débit lorsque des problèmes de connectivité surviennent. Des outils tels que ping, traceroute et les outils de surveillance réseau permettent de recueillir ces données.

Détails sur la source et le client

Déterminez les adresses IP des serveurs d’applications, des équilibreurs de charge ou de tout autre composant qui initie les connexions à la base de données. Il peut s’agir d’une seule adresse IP ou d’une plage d’adresses IP (notation CIDR). Si la source est une EC2 instance Amazon, il est également utile de vérifier le type d'instance, la zone de disponibilité, l'ID de sous-réseau et les groupes de sécurité associés à l'instance, ainsi que les détails de l'interface réseau tels que l'adresse IP privée et l'adresse IP publique.

En analysant minutieusement les données collectées, vous pouvez identifier les erreurs de configuration, les contraintes de ressources, les perturbations du réseau ou les autres problèmes sous-jacents à l’origine des problèmes de connectivité intermittents ou persistants. Ces informations vous permettent de prendre des mesures ciblées, telles que l’ajustement des configurations, la résolution des problèmes de réseau ou la gestion des connexions au niveau de l’application.

Surveillance des connexions aux bases de données pour Aurora MySQL

Pour surveiller et résoudre les problèmes de connectivité, vous pouvez utiliser les métriques et fonctionnalités suivantes.

CloudWatch métriques

CPUUtilization : l’utilisation élevée de l’UC sur l’instance de base de données peut ralentir l’exécution des requêtes, ce qui peut entraîner des délais d’expiration ou des rejets de connexion.
DatabaseConnections : surveille le nombre de connexions actives à l’instance de base de données. Un nombre élevé de connexions proche de la valeur maximale configurée peut indiquer des problèmes de connectivité potentiels ou une saturation du regroupement de connexions.
FreeableMemory : la faible quantité de mémoire disponible peut entraîner des problèmes de performances et de connectivité en raison de contraintes de ressources.
NetworkReceiveThroughput et NetworkTransmitThroughput : des pics ou des baisses inhabituels du débit réseau peuvent indiquer des problèmes de connectivité ou des goulots d’étranglement du réseau.

Métriques de Performance Insights

Pour résoudre les problèmes de connectivité dans Aurora MySQL à l’aide de Performance Insights, analysez les métriques de base de données suivantes :

Aborted_clients
Aborted_connects
Connexions
max_connections
Threads_connected
Threads_created
Threads_running

Ces métriques peuvent vous aider à identifier les goulots d’étranglement de connexion, détecter les problèmes de réseau ou d’authentification, optimiser le regroupement des connexions et garantir une gestion efficace des threads. Pour plus d’informations, consultez Compteurs Performance Insights pour Aurora MySQL.

Fonctionnalité de Performance Insights

Charge de la base de données : visualisez la charge de la base de données au fil du temps et corrélez-la aux problèmes de connectivité ou à la dégradation des performances.
Statistiques SQL : analysez les statistiques SQL pour identifier les requêtes ou les opérations de base de données inefficaces susceptibles d’entraîner des problèmes de connectivité.
Requêtes principales : identifiez et analysez les requêtes les plus gourmandes en ressources, en vue d’identifier les problèmes de performance potentiels ou les requêtes de longue durée susceptibles de provoquer des problèmes de connectivité.

En surveillant ces métriques et en tirant parti de Performance Insights, vous pouvez acquérir une meilleure visibilité sur les performances de l’instance de base de données, l’utilisation des ressources et les goulots d’étranglement potentiels susceptibles de causer des problèmes de connectivité. Par exemple :

Un niveau DatabaseConnections proche de la limite maximale peut indiquer une saturation du regroupement de connexions ou une mauvaise gestion des connexions, ce qui peut entraîner des problèmes de connectivité.
Un niveau CPUUtilization élevé ou FreeableMemory faible peut indiquer des contraintes de ressources, susceptibles de ralentir l’exécution des requêtes et de provoquer des délais d’expiration ou des rejets de connexion.
L’analyse des Requêtes principales et des Statistiques SQL permet d’identifier les requêtes inefficaces ou gourmandes en ressources susceptibles de contribuer aux problèmes de connectivité.

En outre, la surveillance CloudWatch des journaux et la configuration d'alarmes peuvent vous aider à identifier les problèmes de connectivité et à y répondre de manière proactive avant qu'ils ne s'aggravent.

Il est important de noter que si ces métriques et outils peuvent fournir des informations précieuses, ils doivent être utilisés conjointement avec d’autres processus de résolution des problèmes. En examinant également les configurations réseau, les règles des groupes de sécurité et la gestion des connexions au niveau de l’application, vous pouvez diagnostiquer et résoudre de manière exhaustive les problèmes de connectivité liés aux instances de base de données Aurora MySQL.

Surveillance supplémentaire pour Aurora MySQL

CloudWatch métriques

AbortedClients : suit le nombre de connexions client qui n’ont pas été fermées correctement.
AuroraSlowConnectionHandleCount : suit le nombre d’opérations de gestion des connexions lentes, en indiquant les problèmes de connectivité potentiels ou les goulots d’étranglement liés aux performances.
AuroraSlowHandshakeCount : indique le nombre d’opérations d’établissement de liaison lentes, également susceptible de révéler des problèmes de connectivité.
ConnectionAttempts : indique le nombre de tentatives de connexion effectuées à l’instance de base de données Aurora MySQL.

Variables d’état globales

Aurora_external_connection_count : indique le nombre de connexions de base de données à l’instance de base de données, à l’exclusion des connexions au service RDS utilisées pour la surveillance de l’état de la base de données.

En surveillant ces métriques et ces variables d’état globales, vous pouvez acquérir une meilleure visibilité sur les modèles de connexion, les erreurs et les goulots d’étranglement potentiels susceptibles de provoquer des problèmes de connectivité avec votre instance Amazon Aurora MySQL.

Par exemple, un nombre élevé de AbortedClients ou AuroraSlowConnectionHandleCount peut indiquer des problèmes de connectivité.

En outre, la configuration d' CloudWatch alarmes et de notifications peut vous aider à identifier les problèmes de connectivité et à y répondre de manière proactive avant qu'ils ne s'aggravent et n'affectent les performances de votre application.

Codes d’erreur de connectivité pour Aurora MySQL

Voici quelques erreurs de connectivité courantes concernant les bases de données Aurora MySQL, ainsi que leurs codes d’erreur et leurs explications.

Error Code 1040: Too many connections

Cette erreur se produit lorsque le client essaie d’établir un nombre de connexions supérieur au maximum autorisé par le serveur de base de données. Les causes possibles sont notamment les suivantes :

Mauvaise configuration du regroupement de connexions : si vous utilisez un mécanisme de regroupement de connexions, assurez-vous que la taille maximale de ce dernier n’est pas trop élevée et que les connexions sont correctement rétablies dans le regroupement.
Configuration de l’instance de base de données : vérifiez le paramètre de connexions maximales autorisées pour l’instance de base de données et ajustez-le si nécessaire en définissant le paramètre max_connections.
Haute simultanéité : la connexion simultanée d’un grand nombre de clients ou d’applications à la base de données peut entraîner l’atteinte du seuil maximal de connexions autorisées.

Error Code 1045: Access denied for user ’...’@’...’ (using password: YES/NO)

Cette erreur indique un échec d’authentification lors de la tentative de connexion à la base de données. Les causes possibles sont notamment les suivantes :

Compatibilité des plug-ins d’authentification : vérifiez si le plug-in d’authentification utilisé par le client est compatible avec le mécanisme d’authentification du serveur de base de données.
Nom d’utilisateur ou mot de passe incorrect : vérifiez que le nom d’utilisateur et le mot de passe utilisés dans la chaîne de connexion ou le mécanisme d’authentification sont corrects.
Autorisations utilisateur : assurez-vous que l’utilisateur dispose des autorisations nécessaires pour se connecter à l’instance de base de données depuis l’hôte ou le réseau spécifié.

Error Code 1049: Unknown database ’...’

Cette erreur indique que le client tente de se connecter à une base de données qui n’existe pas sur le serveur. Les causes possibles sont notamment les suivantes :

Base de données non créée : assurez-vous que la base de données spécifiée a été créée sur le serveur de base de données.
Nom de base de données incorrect : vérifiez l’exactitude du nom de base de données utilisé dans la chaîne de connexion ou dans la requête.
Autorisations utilisateur : vérifiez que l’utilisateur dispose des autorisations nécessaires pour accéder à la base de données spécifiée.

Error Code 1153: Got a packet bigger than ’max_allowed_packet’ bytes

Cette erreur se produit lorsque le client tente d’envoyer ou de recevoir des données qui dépassent la taille de paquet maximale autorisée par le serveur de base de données. Les causes possibles sont notamment les suivantes :

Ensembles de requêtes ou de résultats volumineux : si vous exécutez des requêtes impliquant de grandes quantités de données, la limite de taille des paquets peut être dépassée.
Paramètres de taille de paquet mal configurés : vérifiez le paramètre max_allowed_packet sur le serveur de base de données et ajustez-le si nécessaire.
Problèmes de configuration réseau : assurez-vous que la configuration réseau (par exemple, la taille MTU) autorise les tailles de paquets requises.

Error Code 1226: User ’...’ has exceeded the ’max_user_connections’ resource (current value: ...)

Cette erreur indique que l’utilisateur a dépassé le nombre maximal de connexions simultanées autorisées par le serveur de base de données. Les causes possibles sont notamment les suivantes :

Mauvaise configuration du regroupement de connexions : si vous utilisez un mécanisme de regroupement de connexions, assurez-vous que la taille maximale de ce dernier n’est pas configurée au-delà de la limite de connexions autorisée pour l’utilisateur.
Configuration de l’instance de base de données : vérifiez le paramètre max_user_connections pour l’instance de base de données et ajustez-le si nécessaire.
Haute simultanéité : si plusieurs clients ou applications se connectent simultanément à la base de données en utilisant le même utilisateur, la limite de connexions spécifique à cet utilisateur peut être atteinte.

Error Code 2003: Can’t connect to MySQL server on ’...’ (10061)

Cette erreur se produit généralement lorsque le client ne parvient pas à établir une TCP/IP connexion avec le serveur de base de données. Elle peut être due à divers problèmes, notamment :

État de l’instance de base de données : assurez-vous que l’instance de base de données présente l’état available et qu’elle ne fait l’objet d’aucune opération de maintenance ou de sauvegarde.
Règles de pare-feu : vérifiez si des pare-feux (système d’exploitation, réseau ou groupe de sécurité) bloquent la connexion sur le port spécifié (généralement 3306 pour MySQL).
Nom d’hôte ou point de terminaison incorrect : assurez-vous que le nom d’hôte ou le point de terminaison utilisé dans la chaîne de connexion est correct et correspond à l’instance de base de données.
Problèmes de connectivité réseau : vérifiez que l’ordinateur client peut accéder à l’instance de base de données via le réseau. Vérifiez l’existence d’éventuelles pannes réseau, de problèmes de routage ou de mauvaises configurations de VPC ou de sous-réseau.

Error Code 2005: Unknown MySQL server host ’...’ (11001)

Cette erreur se produit lorsque le client ne parvient pas à convertir le nom d’hôte ou le point de terminaison du serveur de base de données en adresse IP. Les causes possibles sont notamment les suivantes :

Problèmes de résolution DNS : vérifiez que l’ordinateur client peut résoudre correctement le nom d’hôte à l’aide du DNS. Vérifiez les paramètres DNS, le cache DNS et essayez d’utiliser l’adresse IP au lieu du nom d’hôte.
Nom d’hôte ou point de terminaison incorrect : vérifiez l’exactitude du nom d’hôte ou du point de terminaison utilisé dans la chaîne de connexion.
Problèmes de configuration réseau : assurez-vous que la configuration réseau du client (par exemple, VPC, sous-réseau et tables de routage) autorise la résolution DNS et la connectivité à l’instance de base de données.

Error Code 2026: SSL connection error

Cette erreur se produit en cas de problème de SSL/TLS configuration ou de validation du certificat lors de la tentative de connexion. Les causes possibles sont notamment les suivantes :

Expiration du certificat — Vérifiez si le SSL/TLS certificat utilisé par le serveur a expiré et doit être renouvelé.
Problèmes de validation des certificats : vérifiez que le client est en mesure de valider correctement le SSL/TLS certificat du serveur et que le certificat est fiable.
Problèmes de configuration réseau — Assurez-vous que la configuration réseau autorise les SSL/TLS connexions et ne bloque pas ou n'interfère pas avec le processus de SSL/TLS prise de contact.
SSL/TLS configuration mismatch – Make sure that the SSL/TLSles paramètres (par exemple, les suites de chiffrement et les versions de protocole) du client et du serveur sont compatibles.

La compréhension des explications détaillées et des causes possibles de chaque code d’erreur permet de mieux diagnostiquer et corriger les problèmes de connectivité rencontrés avec les bases de données Aurora MySQL.

Recommandations de réglage des paramètres pour Aurora MySQL

Nombre maximal de connexions

Le réglage de ces paramètres permet d’éviter les problèmes de connexion provoqués par l’atteinte de la limite maximale de connexions autorisées. Assurez-vous que ces valeurs sont définies de manière appropriée en fonction des exigences de simultanéité et des contraintes de ressources de votre application.

max_connections : ce paramètre spécifie le nombre maximum de connexions simultanées autorisées à l’instance de base de données.
max_user_connections : ce paramètre peut être spécifié lors de la création et de la modification d’un utilisateur. Il définit le nombre maximal de connexions simultanées autorisées pour un compte utilisateur spécifique.

Taille du tampon réseau

L’augmentation de ces valeurs peut améliorer les performances du réseau, en particulier pour les charges de travail impliquant des transferts de données ou des jeux de résultats importants. Faites néanmoins attention, car l’augmentation de la taille des tampons entraîne une consommation mémoire plus importante.

net_buffer_length : ce paramètre définit la taille initiale de la connexion client et des tampons de résultats, en équilibrant l’utilisation de la mémoire avec les performances des requêtes.
max_allowed_packet : ce paramètre spécifie la taille maximale d’un seul paquet réseau qui peut être envoyé ou reçu par l’instance de base de données.

Compression réseau (côté client)

L’activation de la compression réseau peut réduire l’utilisation de la bande passante du réseau, mais elle peut augmenter la charge de l’UC du côté client et du côté serveur.

compress— Ce paramètre active ou désactive la compression réseau pour les client/server communications.
compress_protocol : ce paramètre spécifie le protocole de compression à utiliser pour les communications réseau.

Réglage des performances réseau

Le réglage de ces délais permet de mieux gérer les connexions inactives et d’éviter une surcharge des ressources, mais attention : des valeurs trop faibles peuvent entraîner des déconnexions prématurées.

interactive_timeout : ce paramètre indique le nombre de secondes pendant lesquelles le serveur attend une activité sur une connexion interactive avant de la fermer.
wait_timeout : ce paramètre détermine le nombre de secondes pendant lesquelles le serveur attend une activité sur une connexion non interactive avant de la fermer.

Paramètres de délai d’expiration réseau

Le réglage de ces délais permet de résoudre les problèmes liés à la lenteur ou à l’absence de réponse des connexions. Soyez toutefois prudent : des valeurs trop faibles peuvent provoquer des échecs de connexion prématurés.

net_read_timeout : ce paramètre indique le nombre de secondes à attendre pour recevoir davantage de données d’une connexion avant de mettre fin à l’opération de lecture.
net_write_timeout : ce paramètre détermine le nombre de secondes à attendre avant qu’un bloc soit écrit sur une connexion avant de mettre fin à l’opération d’écriture.

Exemples de résolution des problèmes de connexion aux bases de données pour Aurora MySQL

Les exemples suivants montrent comment identifier et résoudre les problèmes de connexion aux bases de données Aurora MySQL.

Exemple 1 : résolution des problèmes liés aux tentatives de connexion infructueuses

Les tentatives de connexion peuvent échouer pour plusieurs raisons, notamment les échecs d'authentification, les échecs de SSL/TLS prise de contact, la max_connections limite atteinte et les contraintes de ressources sur l'instance de base de données.

Vous pouvez suivre le nombre de connexions ayant échoué à partir de Performance Insights ou à l’aide de la commande suivante.


mysql> show global status like 'aborted_connects';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 7     |
+------------------+-------+
1 row in set (0.00 sec)

Si le nombre Aborted_connects augmente au fil du temps, il est possible que l’application rencontre des problèmes de connectivité intermittents.

Vous pouvez utiliser Aurora Advanced Auditing pour enregistrer les connexions et les déconnexions des clients. Vous pouvez le faire en définissant les paramètres suivants dans le groupe de paramètres de cluster de bases de données :

server_audit_logging = 1
server_audit_events = CONNECT

Voici un extrait des journaux d’audit relatifs à un échec de connexion.


1728498527380921,auora-mysql-node1,user_1,172.31.49.222,147189,0,FAILED_CONNECT,,,1045
1728498527380940,auora-mysql-node1,user_1,172.31.49.222,147189,0,DISCONNECT,,,0

Où :

1728498527380921 : l’horodatage de l’époque à laquelle l’échec de connexion s’est produit
aurora-mysql-node1 : l’identifiant d’instance du nœud du cluster Aurora MySQL sur lequel la connexion a échoué
user_1 : le nom de l’utilisateur de base de données pour lequel la connexion a échoué
172.31.49.222 : l’adresse IP privée du client à partir duquel la connexion a été établie
147189 : l’identifiant de connexion de l’échec de connexion
FAILED_CONNECT : indique que la connexion a échoué.
1045 : le code de retour. Une valeur différente de zéro indique une erreur. Dans ce cas, 1045 correspond à un accès refusé.

Pour plus d’informations, consultez Codes d’erreur serveur et Codes d’erreur client dans la documentation MySQL.

Vous pouvez également examiner les journaux d’erreurs d’Aurora MySQL pour rechercher d’éventuels messages d’erreur associés, par exemple :


2024-10-09T19:26:59.310443Z 220 [Note] [MY-010926] [Server] Access denied for user 'user_1'@'172.31.49.222' (using password: YES) (sql_authentication.cc:1502)

Exemple 2 : résolution des problèmes de déconnexion anormale des clients

Vous pouvez suivre le nombre de déconnexions anormales des clients à partir de Performance Insights ou à l’aide de la commande suivante.


mysql> show global status like 'aborted_clients';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Aborted_clients | 9     |
+-----------------+-------+
1 row in set (0.01 sec)

Si le nombre Aborted_clients augmente au fil du temps, cela signifie que l’application ne ferme pas correctement les connexions à la base de données. Si les connexions ne sont pas correctement fermées, cela peut entraîner des fuites de ressources et des problèmes de performances potentiels. Le fait de laisser des connexions ouvertes inutilement peut entraîner une consommation excessive de ressources système (mémoire, descripteurs de fichiers), pouvant à terme bloquer l’application ou le serveur, voire provoquer un redémarrage.

Vous pouvez utiliser la requête suivante pour identifier les comptes qui ne ferment pas correctement les connexions. Elle récupère le nom du compte utilisateur, l’hôte à partir duquel l’utilisateur se connecte, le nombre de connexions non fermées et le pourcentage de connexions non fermées.


SELECT
    ess.user,
    ess.host,
    (a.total_connections - a.current_connections) - ess.count_star AS not_closed,
    (((a.total_connections - a.current_connections) - ess.count_star) * 100) / (a.total_connections - a.current_connections) AS pct_not_closed
FROM
    performance_schema.events_statements_summary_by_account_by_event_name AS ess
    JOIN performance_schema.accounts AS a ON (ess.user = a.user AND ess.host = a.host)
WHERE
    ess.event_name = 'statement/com/quit'
    AND (a.total_connections - a.current_connections) > ess.count_star;

+----------+---------------+------------+----------------+
| user     | host          | not_closed | pct_not_closed |
+----------+---------------+------------+----------------+
| user1    | 172.31.49.222 |          1 |        33.3333 |
| user1    | 172.31.93.250 |       1024 |        12.1021 |
| user2    | 172.31.93.250 |         10 |        12.8551 |
+----------+---------------+------------+----------------+
3 rows in set (0.00 sec)

Après avoir identifié les comptes utilisateurs et les hôtes à partir desquels les connexions ne sont pas fermées, vous pouvez vérifier le code qui ne ferme pas les connexions correctement.

Par exemple, avec le connecteur MySQL en Python, utilisez la méthode close() de l’objet de connexion pour fermer les connexions. Voici un exemple de fonction qui établit une connexion à une base de données, exécute une requête et ferme la connexion :


import mysql.connector

def execute_query(query):
    # Establish a connection to the database
    connection = mysql.connector.connect(
        host="your_host",
        user="your_username",
        password="your_password",
        database="your_database"
    )

    try:
        # Create a cursor object
        cursor = connection.cursor()

        # Execute the query
        cursor.execute(query)

        # Fetch and process the results
        results = cursor.fetchall()
        for row in results:
            print(row)

    finally:
        # Close the cursor and connection
        cursor.close()
        connection.close()

Dans cet exemple, la méthode connection.close() est appelée dans le bloc finally pour s’assurer que la connexion est fermée, qu’une exception se produise ou non.

Exemple 3 : résolution des problèmes liés à l'échec des tentatives de connexion IAM

La connectivité avec les utilisateurs d' AWS Identity and Access Management (IAM) peut échouer pour plusieurs raisons, notamment :

Configuration de la politique IAM incorrecte
Identifiants de sécurité expirés
Problèmes liés à la connectivité réseau
Incompatibilité des autorisations de base de données

Pour résoudre ces erreurs d'authentification, activez la fonctionnalité d'exportation des iam-db-auth-error journaux dans votre base de données Amazon Relational Database Service (RDS) ou Aurora. Cela vous permettra d'afficher les messages d'erreur d'authentification détaillés dans le groupe de CloudWatch journaux de votre cluster Amazon RDS ou Amazon Aurora.

Une fois activé, vous pouvez consulter ces journaux pour identifier et résoudre la cause spécifique de vos échecs d'authentification IAM.

Par exemple :


2025-09-22T12:02:30,806 [ERROR] Failed to authorize the connection request for user 'user_1' due to an internal IAM DB Auth error. (Status Code: 500, Error Code: InternalError)

and


2025-09-22T12:02:51,954 [ERROR] Failed to authenticate the connection request for user 'user_2' because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)

Pour obtenir des conseils de dépannage, reportez-vous au guide de dépannage Aurora pour l'authentification IAM DB.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Journalisation pour Aurora MySQL

Résolution des problèmes de performance des requêtes