Pourquoi est-ce que je reçois le message d'erreur « Trop de connexions » lorsque je me connecte à mon instance MySQL Amazon Aurora ?

Brève description

Si le client reçoit le message d'erreur « Trop de connexions » lorsqu'il essaye de se connecter à un cluster ou une instance de base de données MySQL Amazon Aurora, cela signifie que toutes les connexions disponibles sont utilisées par d'autres clients. Ceci est défini par le paramètre max_connections.

Vous pouvez voir l'un des symptômes suivants :

• La valeur de la métrique DatabaseConnections dans Amazon CloudWatch est proche ou égale à la valeur max_connections de votre instance de base de données MySQL Aurora.
• La valeur du paramètre max_connections est supérieure à la mémoire disponible allouée par la classe d'instance de base de données pour les connexions. Vérifiez les signes comme une faible valeur de métrique FreeableMemory dans CloudWatch.
• Vous obtenez une ERREUR 1040 () : trop de connexions dans le journal des erreurs MySQL.

Vous pouvez atteindre une valeur max_connections pour les raisons suivantes :

• Augmentation soudaine ou progressive du nombre de connexions client/application à l'instance de base de données. Les causes sont les suivantes :
  • Augmentation de la charge de travail entraînant une augmentation des connexions.
  • Verrouillage au niveau de la table/ligne conduisant à une augmentation de la connexion client/application.
• Client/application ne ferme pas correctement les connexions après la fin de l'opération.
• Valeur plus élevée pour les paramètres de délai d'expiration de connexion comme wait_timeout et/ou interactive_timeout qui peuvent conduire à une augmentation des connexions en veille.

Avant de résoudre l'erreur de connexion maximale, affichez d'abord tous les threads qui s'exécutent actuellement sur votre instance de base de données. Ensuite, activez la journalisation sur votre instance de base de données.

Afficher les threads en cours d'exécution sur l'instance de base de données MySQL Aurora

La commande SHOW FULL PROCESSLIST affiche les threads en cours d'exécution sur votre instance de base de données. Connectez-vous à votre instance de base de données, puis exécutez la requête suivante :

SHOW FULL PROCESSLIST\G

Vous pouvez également exécuter la requête suivante pour obtenir le même jeu de résultats :

SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST

Remarque : vous devez accorder à votre compte utilisateur le privilège d'administration pour le serveur MySQL PROCESS afin de voir tous les threads exécutés sur une instance de base de données MySQL. Dans le cas contraire, SHOW PROCESSLIST affiche uniquement les threads associés au compte MySQL que vous utilisez. Pour plus d'informations, consultez la documentation MySQL relative aux privilèges fournis par MySQL.

Remarque : les instructions SHOW FULL PROCESSLIST et INFORMATION_SCHEMA.PROCESSLIST peuvent affecter négativement les performances, car elles nécessitent un mutex.

Activer la journalisation sur l'instance de base de données MySQL Aurora

Activez la journalisation sur votre instance de base de données MySQL Aurora en activant les paramètres de journalisation général_log, slow_query_log ou de journal d'audit avancé.

Résolution

Résolvez l'erreur de connexion maximale en utilisant l'une des méthodes suivantes :

• Examinez les connexions existantes et, si possible, annulez-les pour libérer la pression de connexion. Par exemple, commencez par mettre fin aux connexions en état de veille.
• Augmentez le nombre maximal de connexions à votre instance de base de données.

Annuler les connexions existantes sur votre instance de base de données

Fermez les sessions utilisateur ou les requêtes en cours d'exécution sur votre instance de base de données en exécutant les commandes rds_kill et rds_kill_query :

CALL mysql.rds_kill(thread-ID);
CALL mysql.rds_kill_query(thread-ID);

Augmenter le nombre maximal de connexions à votre instance de base de données

Augmentez le nombre maximal de connexions à votre instance de base de données en utilisant les méthodes suivantes :

• Mettez à l'échelle l'instance jusqu'à une classe d'instance de base de données avec plus de mémoire. Remarque : la mise à l'échelle de la classe d'instance de base de données provoque une interruption.
• Définissez une valeur plus grande pour le paramètre max_connections à l'aide d'un groupe de paramètres personnalisé au niveau de l'instance. L'augmentation du paramètre max_connections ne provoque pas de panne, mais si votre instance de base de données utilise un groupe de paramètres par défaut, remplacez le groupe de paramètres par un groupe de paramètres personnalisé. La modification du groupe de paramètres entraîne une panne. Pour plus d'informations, consultez la section Utilisation des groupes de paramètres de base de données.

Remarque : le nombre maximal de connexions autorisées à une instance de base de données MySQL Aurora est déterminé par le paramètre max_connections dans le groupe de paramètres de niveau instance de l'instance de base de données. Consultez l'exemple suivant :

max_connections = GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})

Vérifiez la valeur actuelle du paramètre max_connections pour votre instance de base de données. Pour ce faire, vérifiez le groupe de paramètres attaché à votre instance de base de données ou exécutez la requête suivante :

select @@max_connections;

Le paramètre max_connections a les spécifications suivantes :

• Peut être défini sur le cluster de base de données et le groupe de paramètres d'instance de base de données. Toutefois, le paramètre au niveau de l'instance prend effet.
• La valeur autorisée est un entier compris entre 1 et 16 000.
• Dynamique par nature (aucun redémarrage n'est nécessaire pour modifier cette valeur de paramètre).

Pour plus d'informations sur la valeur par défaut de max_connections pour chaque classe d'instance de base de données disponible pour Aurora MySQL, reportez-vous à la section Maximum de connexions à une instance de base de données Aurora MySQL.

Remarque : les instances de base de données MySQL Aurora et Amazon Relational Database Service (Amazon RDS) MySQL ont différentes quantités de surcharge mémoire. La valeur max_connections peut être différente pour les instances de base de données MySQL et RDS MySQL d'Aurora qui utilisent la même classe d'instance. Les valeurs répertoriées s'appliquent uniquement à Aurora MySQL.

Bonnes pratiques pour régler le paramètre max_connections

Veillez à tenir compte des éléments suivants lorsque vous travaillez avec le paramètre max_connections pour votre instance de base de données.

• Les limites de connexion par défaut sont réglées pour les systèmes qui utilisent les valeurs par défaut pour d'autres grands consommateurs de mémoire, notamment le groupe tampon et le cache de requêtes. Si vous modifiez ces paramètres pour votre cluster de base de données, envisagez d'ajuster la limite de connexion pour tenir compte de l'augmentation ou de la diminution de la mémoire disponible sur les instances de base de données.
• Définissez une valeur max_connections légèrement supérieure au nombre maximal de connexions que vous comptez ouvrir sur chaque instance de base de données.
• Si vous avez également activé performance_schema, faites attention au paramètre max_connections. Les structures de mémoire de type Performance Schema sont dimensionnées automatiquement en fonction des variables de configuration du serveur, y compris max_connections. Plus vous définissez la variable, plus le schéma Performance Schema utilise de mémoire. Dans les cas extrêmes, cela peut entraîner des problèmes d'insuffisance de la mémoire sur les types d'instances plus petits, notamment que T2 et T3. Il est recommandé de conserver la valeur par défaut de max_connections si vous utilisez Performance Schema. Si vous envisagez d'augmenter la valeur max_connections vers une valeur nettement supérieure à la valeur par défaut, pensez à désactiver le schéma de performance. Remarque : si vous activez Performance Insights pour une instance de base de données MySQL Aurora, cela active automatiquement le Performance Schema.

Vous pouvez également prendre en compte les paramètres de connexion MySQL suivants pour le réglage :

• wait_timeout : nombre de secondes pendant lesquelles le serveur attend l'activité sur une connexion TCP/IP ou UNIX non interactive avant de la fermer.
• interactive_timeout : nombre de secondes pendant lesquelles le serveur attend l'activité sur une connexion interactive avant de la fermer.
• net_read_timeout : nombre de secondes d'attente de plus de données provenant d'une connexion TCP/IP avant l'abandon de la lecture.
• net_write_timeout : nombre de secondes d'attente sur les connexions TCP/IP pour qu'un bloc soit écrit avant l'abandon de l'écriture.
• max_execution_time : délai d'exécution pour les instructions SELECT, en millisecondes.
• max_connect_errors : un hôte est privé d'autres connexions si la qualité de connexions interrompues dépasse ce nombre.
• max_user_connections : nombre maximal de connexions simultanées autorisées sur un compte MySQL donné.

Remarque : cet article n'inclut pas les valeurs recommandées ou personnalisées pour ces paramètres, car ces valeurs varient en fonction du cas d'utilisation individuel.

Informations connexes

Nombre maximal de connexions à une instance de base de données MySQL Aurora

Comment vérifier les requêtes en cours d'exécution sur mon instance de base de données MySQL Amazon RDS ?

Arrêt d'une session ou d'une requête