Avoir un équilibreur de charge ou un proxy inverse devant votre serveur MySQL ou MariaDB ajoute un peu de complexité à la configuration de votre base de données, ce qui peut entraîner certaines choses qui se comportent différemment. Théoriquement, un équilibreur de charge qui se trouve devant les serveurs MySQL (par exemple un HAProxy devant un cluster Galera) devrait simplement agir comme un gestionnaire de connexions et distribuer les connexions aux serveurs principaux selon un algorithme d'équilibrage. MySQL, d'autre part, a sa propre façon de gérer les connexions client. Idéalement, nous aurions besoin de configurer ces deux composants ensemble afin d'éviter les comportements inattendus et de réduire la surface de dépannage lors du débogage des problèmes.
Si vous avez une telle configuration, il est important de comprendre ces composants car ils peuvent avoir un impact sur les performances globales de votre service de base de données. Dans cet article de blog, nous allons plonger dans les max_connections de MySQL et HAProxy maxconn respectivement. Notez que le délai d'expiration est un autre paramètre important que nous devrions connaître, mais nous allons le couvrir dans un article séparé.
Connexions maximales de MySQL
Ressources associées Équilibrage de charge MySQL avec HAProxy - Tutoriel Webinaire Replay et Q&R :comment déployer et gérer ProxySQL, HAProxy et MaxScaleWebinar Replay &Slides :Comment créer des infrastructures de base de données évolutives avec MariaDB et HAProxyLe nombre de connexions autorisées à un serveur MySQL est contrôlé par le max_connections variable système. La valeur par défaut est 151 (MySQL 5.7).
Pour déterminer un bon nombre pour max_connections , les formules de base sont :
Où,
**Variable innodb_additional_mem_pool_size est supprimé dans MySQL 5.7.4+. Si vous utilisez l'ancienne version, tenez compte de cette variable.
Et,
En utilisant les formules ci-dessus, nous pouvons calculer un max_connections approprié valeur pour ce serveur MySQL particulier. Pour démarrer le processus, arrêtez toutes les connexions des clients et redémarrez le serveur MySQL. Assurez-vous que vous n'avez que le nombre minimum de processus en cours d'exécution à ce moment précis. Vous pouvez utiliser 'mysqladmin' ou 'SHOW PROCESSLIST' à cette fin :
$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query | 0 | NULL | show processlist | 0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)À partir de la sortie ci-dessus, nous pouvons dire qu'un seul utilisateur est connecté au serveur MySQL qui est root. Ensuite, récupérez la RAM disponible (en Mo) de l'hôte (regardez sous la colonne 'disponible') :
$ free -m
total used free shared buff/cache available
Mem: 3778 1427 508 148 1842 1928
Swap: 2047 4 2043Juste pour info, la colonne "disponible" donne une estimation de la quantité de mémoire disponible pour démarrer de nouvelles applications, sans échange (uniquement disponible dans le noyau 3.14+).
Ensuite, spécifiez la mémoire disponible, 1928 Mo dans la déclaration suivante :
mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
| 265 |
+--------------------------+**Variable innodb_additional_mem_pool_size est supprimé dans MySQL 5.7.4+. Si vous utilisez l'ancienne version, tenez compte de cette variable.
À partir de cet exemple, nous pouvons avoir jusqu'à 265 connexions MySQL simultanément en fonction de la RAM disponible de l'hôte. Cela n'a pas de sens de configurer une valeur plus élevée que cela. Ensuite, ajoutez la ligne suivante dans le fichier de configuration MySQL, sous la directive [mysqld] :
max_connections = 265Redémarrez le service MySQL pour appliquer la modification. Lorsque le nombre total de connexions simultanées atteint 265, vous obtenez une erreur "Too many connections" lorsque vous essayez de vous connecter au serveur mysqld. Cela signifie que toutes les connexions disponibles sont utilisées par d'autres clients. MySQL autorise en fait max_connections +1 clients à connecter. La connexion supplémentaire est réservée aux comptes disposant du privilège SUPER. Donc, si vous rencontrez cette erreur, vous devez essayer d'accéder au serveur en tant qu'utilisateur root (ou tout autre utilisateur SUPER) et consulter la liste des processus pour démarrer le dépannage.
Les connexions maximales de HAProxy
HAProxy a 3 types de connexions maximales (maxconn) - global, defaults/listen et default-server. Supposons qu'une instance HAProxy soit configurée avec deux écouteurs, un pour l'écoute multi-écrivain sur le port 3307 (les connexions sont distribuées à tous les serveurs MySQL principaux) et un autre est un écrivain unique sur le port 3308 (les connexions sont transmises à un seul serveur MySQL) :
global
...
maxconn 2000 #[a]
...
defaults
...
maxconn 3 #[b]
...
listen mysql_3307
...
maxconn 8 #[c]
balance leastconn
default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
server db1 192.168.55.171 check
server db2 192.168.55.172 check
server db3 192.168.55.173 check
listen mysql_3308
...
default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
server db1 192.168.55.171 check
server db2 192.168.55.172 check backup #[f]Regardons la signification de certaines lignes de configuration :
global.maxconn [a]
Le nombre total de connexions simultanées autorisées à se connecter à cette instance HAProxy. Habituellement, cette valeur est la valeur la plus élevée de toutes. Dans ce cas, HAProxy acceptera un maximum de 2000 connexions à la fois et les distribuera à tous les écouteurs définis dans le processus HAProxy, ou travailleur (vous pouvez exécuter plusieurs processus HAProxy en utilisant nbproc option).
HAProxy cessera d'accepter les connexions lorsque cette limite sera atteinte. Le paramètre "ulimit-n" est automatiquement ajusté à cette valeur. Étant donné que les sockets sont considérés comme équivalents aux fichiers du point de vue du système, la limite par défaut des descripteurs de fichiers est plutôt faible. Vous souhaiterez probablement augmenter la limite par défaut en ajustant le noyau pour les descripteurs de fichiers.
defaults.maxconn [b]
Valeur de connexions maximale par défaut pour tous les écouteurs. Cela n'a pas de sens si cette valeur est supérieure à global.maxconn .
Si la ligne "maxconn" est manquante sous la strophe "listen" (listen.maxconn ), l'auditeur obéira à cette valeur. Dans ce cas, l'écouteur mysql_3308 obtiendra un maximum de 3 connexions à la fois. Pour être sûr, définissez cette valeur égale à global.maxconn , divisé par le nombre d'auditeurs. Cependant, si vous souhaitez donner la priorité à d'autres auditeurs pour avoir plus de connexions, utilisez listen.maxconn à la place.
écouter.maxconn [c]
Les connexions maximales autorisées pour l'écouteur correspondant. L'écouteur a priorité sur defaults.maxconn si spécifié. Cela n'a pas de sens si cette valeur est supérieure à global.maxconn .
Pour une répartition équitable des connexions aux serveurs principaux comme dans le cas d'un écouteur multi-écrivain (mysql_3307), définissez cette valeur sur listen.default-server.maxconn multiplier par le nombre de serveurs principaux. Dans cet exemple, une meilleure valeur devrait être 12 au lieu de 8 [c]. Si nous choisissons de nous en tenir à cette configuration, db1 et db2 devraient recevoir un maximum de 3 connexions chacune, tandis que db3 recevra un maximum de 2 connexions (en raison de l'équilibrage de moindre connexion), ce qui équivaut à 8 connexions au total. Il n'atteindra pas la limite spécifiée dans [d].
Pour l'écouteur à écriture unique (mysql_3308) où les connexions doivent être allouées à un et un seul serveur principal à la fois, définissez cette valeur pour qu'elle soit identique ou supérieure à listen.default-server.maxconn .
écouter.default-server.maxconn [d][e]
Il s'agit du nombre maximal de connexions que chaque serveur principal peut recevoir à la fois. Cela n'a pas de sens si cette valeur est supérieure à listen.maxconn ou defaults.maxconn . Cette valeur doit être inférieure ou égale aux max_connections de MySQL variable. Sinon, vous risquez d'épuiser les connexions au serveur MySQL principal, en particulier lorsque les variables de délai d'attente de MySQL sont configurées à une valeur inférieure aux délais d'expiration de HAProxy.
Dans cet exemple, nous avons configuré chaque serveur MySQL pour qu'il n'obtienne qu'un maximum de 4 connexions à la fois pour les nœuds Galera multi-écrivains [d]. Alors que le nœud Galera à écrivain unique obtiendra un maximum de 3 connexions à la fois, en raison de la limite qui s'applique à partir de [b]. Puisque nous avons spécifié "sauvegarde" [f] à l'autre nœud, le nœud actif obtiendra immédiatement les 3 connexions allouées à cet écouteur.
L'explication ci-dessus peut être illustrée dans le schéma suivant :
Pour résumer la distribution des connexions, db1 devrait obtenir un nombre maximum de 6 connexions (3 de 3307 + 3 de 3308). Le db2 obtiendra 3 connexions (sauf si db1 tombe en panne, où il en obtiendra 3 supplémentaires) et db3 s'en tiendra à 2 connexions indépendamment des changements de topologie dans le cluster.
Surveillance des connexions avec ClusterControl
Avec ClusterControl, vous pouvez surveiller l'utilisation de la connexion MySQL et HAProxy à partir de l'interface utilisateur. La capture d'écran suivante fournit un résumé du conseiller de connexion MySQL (ClusterControl -> Performance -> Advisors) où il surveille les connexions MySQL actuelles et jamais utilisées pour chaque serveur du cluster :
Pour HAProxy, ClusterControl s'intègre à la page de statistiques HAProxy pour collecter des métriques. Ceux-ci sont présentés sous l'onglet Nœuds :
À partir de la capture d'écran ci-dessus, nous pouvons dire que chaque serveur principal sur un écouteur multi-écrivain obtient un maximum de 8 connexions. 4 sessions simultanées sont en cours. Ceux-ci sont mis en surbrillance dans le carré rouge supérieur, tandis que l'écouteur à écrivain unique dessert 2 connexions et les transmet respectivement à un seul nœud.
Conclusion
La configuration du nombre maximal de connexions pour HAProxy et le serveur MySQL est importante pour assurer une bonne répartition de la charge sur nos serveurs de base de données et protéger les serveurs MySQL contre la surcharge ou l'épuisement de ses connexions.
