Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Gestion des connexions
À mesure que la demande en faveur de votre application augmente, le trafic frontend augmente. Dans un scénario classique, vous configurez la mise à l'échelle automatique au niveau de l'application pour gérer une telle hausse du trafic entrant. Par conséquent, le niveau d'application commence à se mettre à l'échelle automatiquement et de nouveaux serveurs d'applications (instances) sont ajoutés pour répondre à l'augmentation du trafic. Comme tous les serveurs d'applications ont des paramètres de groupe de connexions à la base de données préconfigurés, le nombre de connexions entrantes vers la base de données augmente proportionnellement au nombre d'instances récemment déployées.
Par exemple, 20 serveurs d'applications configurés avec 200 connexions à la base de données ouvriraient chacun un total de 4 000 connexions à la base de données. Si le groupe d'applications augmente pour atteindre 200 instances (par exemple, pendant les heures de pointe), le nombre total de connexions atteindra 40 000. Dans le cadre d'une charge de travail type, la plupart de ces connexions sont probablement inactives. Toutefois, l'augmentation du nombre de connexions peut limiter la capacité de mise à l'échelle de votre base de données Amazon Aurora Édition compatible avec MySQL. Cela s'explique par le fait que même les connexions inactives consomment de la mémoire et d'autres ressources du serveur, telles que les descripteurs de fichiers. Aurora compatible MySQL utilise généralement moins de mémoire que MySQL Community Edition pour maintenir le même nombre de connexions. Cependant, l'utilisation de la mémoire pour les connexions inactives n'est toujours pas nulle.
Variables de configuration
Vous pouvez contrôler le nombre de connexions entrantes autorisées pour votre base de données à l'aide de deux principales variables de configuration du serveur : max_connections et max_connect_errors.
Variable de configuration max_connections
La variable de configuration max_connections limite le nombre de connexions à la base de données pour chaque instance MySQL. Il est recommandé de la définir sur une valeur 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, soyez particulièrement prudent avec le paramètre max_connections. Les structures de mémoire du schéma de performance sont dimensionnées automatiquement en fonction des variables de configuration du serveur, notamment max_connections. Plus la variable est élevée, plus le schéma de performance utilise de mémoire. Dans les cas extrêmes, cela peut entraîner des out-of-memory problèmes sur des types d'instances plus petits. Notez que l'activation de l'Analyse des performances activera automatiquement le schéma de performance.
Variable de configuration max_connect_errors
La variable de configuration max_connect_errors détermine le nombre de demandes de connexion interrompues successives autorisées par un hôte client donné. Si l'hôte client dépasse le nombre spécifié d'échecs de tentatives de connexion successives, le serveur le bloque. D'autres tentatives de connexion de la part de ce client génèrent une erreur.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
Si vous rencontrez des erreurs « l'hôte est bloqué », évitez d'augmenter la valeur de la max_connect_errors variable. Examinez plutôt les compteurs de diagnostic du serveur dans la variable d'état aborted_connects et la table host_cach. Utilisez les informations collectées pour identifier et corriger les clients qui rencontrent des problèmes de connexion. Notez également que ce paramètre n'a aucun effet si skip_name_resolve est défini sur 1 (valeur par défaut).
Consultez le Manuel de référence de MySQL pour en savoir plus sur les points suivants :
Implémenter un groupe de connexions
Un événement de mise à l'échelle peut ajouter d'autres serveurs d'applications, ce qui peut entraîner le dépassement du nombre de connexions actives entièrement chargées par le serveur de base de données. L'ajout d'un groupe de connexions ou d'une couche proxy entre les serveurs d'applications et la base de données agit comme un entonnoir, en réduisant le nombre total de connexions sur la base de données. L'objectif principal d'un proxy est de réutiliser les connexions aux bases de données par le biais du multiplexage.
D'un côté, le proxy se connecte à la base de données avec un nombre de connexions contrôlé. De l'autre côté, le proxy accepte les connexions aux applications. Il propose également des fonctionnalités supplémentaires, telles que la mise en cache des requêtes, la mise en mémoire tampon des connexions, la réécriture et le routage des requêtes, ainsi que l'équilibrage de charge. La couche du groupe de connexions doit être configurée pour maintenir le nombre maximal de connexions à la base de données en dessous du nombre de connexions complètement chargées. Proxy Amazon RDS
Vous pouvez également explorer les proxys tiers suivants qui peuvent être utilisés avec Aurora compatible MySQL :
Éviter les tempêtes de connexion
Réfléchissez au comportement de votre groupe de connexions en cas de surcharge de la base de données ou de réplica trop en retard par rapport au nœud primaire. Lorsque vous configurez votre serveur proxy ou vos groupes de connexions, veillez à ne pas réinitialiser l'ensemble du groupe de connexions en raison de la lenteur des réponses de la base de données (en raison de problèmes matériels ou de stockage sous-jacents ou à des contraintes de ressources de base de données).
Le démarrage soudain de centaines de connexions génère une tempête de connexion, car un grand nombre de demandes de nouvelles connexions à la base de données sont toutes lancées en même temps. La tempête consomme énormément de ressources. La création d'une connexion à une base de données dans MySQL est une opération coûteuse, car le backend échange plusieurs paquets réseau pour la première prise de contact, lance un nouveau processus, alloue de la mémoire, gère l'authentification, etc. Si un grand nombre de demandes sont reçues en peu de temps, la base de données peut donner l'impression de ne pas répondre.
MySQL dispose d'un mécanisme pour se protéger contre un tel pic de demandes de connexion. La variable back_log peut être définie sur le nombre de demandes qui peuvent être empilées pendant une courte période avant que MySQL ne cesse momentanément de répondre aux nouvelles demandes. La valeur est appliquée par un thread de gestion des connexions, qui peut lui-même être submergé par une tempête de connexion. Pour plus d'informations, consultez le manuel de référence MySQL
Si votre connexion est configurée pour être réinitialisée lorsque la base de données est lente, vous relancerez le cycle encore et encore. De même, si vous anticipez une augmentation soudaine du trafic de base de données à certains moments de la journée (par exemple, à l'ouverture de la bourse), préchauffez votre groupe de connexions afin de ne pas essayer d'ouvrir de nombreuses connexions au même moment où une charge de trafic importante commence.
