ProxySQL est un outil que nous utilisons fortement dès lors que nous sommes en présence de base de données MariaDB / MySQL. Il nous permet de facilement ajouter une couche entre le moteur de bases de données et l’applicatif pour
- nous permettre de surveiller le trafic qui passe
- obtenir des statistiques sur l’utilisation des requêtes notamment, celles les plus utilisées / consommatrices / lentes
- ajouter une petite couche de firewalling sur les requêtes
- du routage fin dans le cas d’un cluster de bases de données où on veut dédier des serveurs pour la lecture et d’autres pour l’écriture (cluster Galera)
- ajouter du cache sur des requêtes alors que l’applicatif ne le supporte pas nativement
ProxySQL a d’autres fonctionnalités que nous n’utilisons pas pour le moment car le cas ne s’est pas présenté, mais il est, par exemple, possible de modifier une requête et de la réécrire. L’idéal est de la corriger à la source mais quand cela n’est pas possible ou que cela demande un certain temps, ce petit « patch » peut vous sauver des productions.
Comment fonctionne t-il ?
C’est un daemon qui écoute sur le port 6033 … (les plus alertes auront noté l’utilisation du port du protocole MySQL à l’envers (3306)), et dispose d’un port de gestion qui est le port 6032. Ce port de gestion est utilisable avec le client classique MySQL ou MariaDB pour donner des instructions de configuration à ProxySQL
ProxySQL écoute sur le port 6033 et se tient prêt à recevoir les connexions utilisateur. Ainsi, une application PHP, Java, Golang … se connectera sur le port 6033 et bénéficiera directement des fonctionnalités de ProxySQL.
ProxySQL maintient un pool de connexion avec ses clients directs mais également avec le ou les serveurs de base de données. La mise en oeuvre est très simple, il suffit de modifier le port de l’application et c’est fait
Quelques cas d’usage chez Devclic
Surveillance du trafic en vue d’optimiser les performances
Dans le cadre de notre activité d’infogérance, nous utilisons ProxySQL pour surveiller les bases de données que nous avons en gestion en l’activant sur les solutions de serveurs que nous infogérons.
L’application se connecte à ProxySQL et nous avons alors un log complet de tout ce qui passe par celui-ci et pouvons identifier des requêtes qui sont lentes, non optimisées, la récurrence de celles-ci avec par exemple ce type de requêtes que nous demandons à ProxySQL
select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text from stats_mysql_query_digest where count_star > 100 order by average_time_ms desc limit 4;Nous avons alors en sortie la liste des 4 requêtes les plus appelées / consommatrices de temps
Grâce à ces informations, nous pouvons tester la requête au moyen d’un EXPLAIN et voir les décisions qui sont prises par le moteur pour traiter la requête. On peut avoir la même chose avec le slowlog mais ici, on a une donnée rapide qui est le temps de la requête vis à vis du nombre de requête. Cela évite un long processus couteux de retraitement des logs
Gestion de la charge dans le cas d’un cluster Galera
Nous utilisons des clusters Galera pour la gestion des entrées DNS via des applications que nous avons développées et qui répondent au serveur DNS en lui fournissant les enregistrements DNS demandés.
C’est un savant mélange entre génération à la volée d’enregistrements DNS et de données stockées dans des clusters Galera
Dans le cas des maintenances que nous sommes amenés à réaliser, ProxySQL va router les requêtes vers les noeuds en fonction de contraintes que nous lui donnons et de l’état de chaque noeud Galera
Au besoin, nous avons également la possibilité de mettre en place du cache sur des requêtes (exemple un flood sur le DNS)
Nos noeuds Galera sont répartis entre 5 sites, l’application n’a aucune idée qu’elle fonctionne en cluster, c’est ProxySQL qui s’occupe de gérer cela.