ProxySQL est l'un des meilleurs proxys pour MySQL. Il a introduit un grand nombre d'options pour les administrateurs de bases de données. Il a permis de façonner le trafic de la base de données en retardant, en mettant en cache ou en réécrivant les requêtes à la volée. Il peut également être utilisé pour créer un environnement dans lequel les basculements n'affecteront pas les applications et seront transparents pour elles. Nous avons déjà couvert les fonctionnalités ProxySQL les plus importantes dans les articles de blog précédents :
- Comment utiliser ClusterControl et ProxySQL pour la mise en cache des requêtes
- Comment créer un pare-feu SQL avec ClusterControl et ProxySQL
- Comment déployer un cluster ProxySQL
- Comment déployer facilement l'environnement de réplication MySQL avec ProxySQL pour une haute disponibilité
Nous avons même un tutoriel couvrant ProxySQL montrant comment il peut être utilisé dans les configurations MySQL et MariaDB.
Tout récemment, ProxySQL 2.0.3 a été publié, étant une version de correctif pour la série 2.0. Les bugs sont en cours de correction et la ligne 2.0 semble commencer à obtenir la traction qu'elle mérite. Dans cet article de blog, nous aimerions discuter des changements majeurs introduits dans ProxySQL 2.0.
Lectures causales à l'aide de GTID
Tous ceux qui ont dû faire face à un décalage de réplication et qui ont lutté avec des scénarios de lecture après écriture affectés par le décalage de réplication seront certainement très satisfaits de cette fonctionnalité. Jusqu'à présent, dans les environnements de réplication MySQL, la seule façon d'assurer des lectures causales était de lire à partir du maître (et peu importe si vous utilisez une réplication asynchrone ou semi-synchrone). Une autre option était d'opter pour Galera, qui avait une option pour imposer des lectures causales depuis, comme, toujours (d'abord c'était wsrep-causal-reads et maintenant c'est wsrep-sync-wait). Tout récemment (en 8.0.14), la réplication de groupe MySQL a obtenu une fonctionnalité similaire. La réplication régulière, cependant, à elle seule, ne peut pas résoudre ce problème. Heureusement, ProxySQL est là et il nous apporte une option pour définir sur la base de règles par requête avec ce que le groupe d'hôtes lit et qui correspond à cette règle de requête doit être cohérent. L'implémentation est fournie avec le lecteur binlog ProxySQL et peut fonctionner avec le format binlog ROW pour MySQL 5.7 et versions ultérieures. Seul Oracle MySQL est pris en charge en raison du manque de fonctionnalités requises dans MariaDB. Cette fonctionnalité et ses détails techniques ont été expliqués sur le blog officiel de ProxySQL.
SSL pour les connexions frontales
ProxySQL a toujours pris en charge la connexion SSL backend, mais il manquait le cryptage SSL pour les connexions provenant des clients. Ce n'était pas si grave étant donné que le modèle de déploiement recommandé consistait à colocaliser ProxySQL sur les nœuds d'application et à utiliser un socket Unix sécurisé pour se connecter de l'application au proxy. Cela reste une recommandation, surtout si vous utilisez ProxySQL pour la mise en cache des requêtes (les sockets Unix sont plus rapides que la connexion TCP, même les locales et avec le cache, il est bon d'éviter d'introduire une latence inutile). Ce qui est bien, c'est qu'avec ProxySQL 2.0, il y a maintenant un choix car il a introduit le support SSL pour les connexions entrantes. Vous pouvez facilement l'activer en définissant mysql-have_ssl sur "true". L'activation de SSL n'a pas d'impact inacceptable sur les performances. Au contraire, selon les résultats du blog officiel ProxySQL, la baisse des performances est très faible.
Prise en charge native du cluster Galera
Galera Cluster est pris en charge par ProxySQL presque depuis le début, mais jusqu'à présent, cela a été fait via le script externe qui (généralement) a été appelé à partir du planificateur interne de ProxySQL. Il appartenait au script de s'assurer que la configuration de ProxySQL était correcte, que l'écrivain (ou les écrivains) a été correctement détecté et configuré dans le groupe d'hôtes des écrivains. Le script a pu détecter les différents états que le nœud Galera peut avoir (Primaire, non principal, Synchronisé, Donateur/Désynchronisé, Rejoindre, Rejoindre) et marquer le nœud en conséquence comme étant disponible ou non. Le principal problème est que le script original n'a jamais été conçu comme autre chose que la preuve de concept écrite en Bash. Pourtant, comme il a été distribué avec ProxySQL, il a commencé à être amélioré, modifié par des contributeurs externes. D'autres (comme Percona) ont cherché à créer leurs propres scripts, fournis avec leur logiciel. Certains correctifs ont été introduits dans le script à partir du référentiel ProxySQL, certains ont été introduits dans la version Percona du script. Cela a semé la confusion et même si tous les scripts couramment utilisés traitaient 95 % des cas d'utilisation, aucun des plus populaires ne couvrait vraiment toutes les différentes situations et variables que le cluster Galera pourrait finir par utiliser. Heureusement, ProxySQL 2.0 est livré avec un support natif pour Galera Cluster. Cela permet à ProxySQL de prendre en charge en interne la réplication MySQL, la réplication de groupe MySQL et maintenant Galera Cluster. La façon dont c'est fait est très similaire. Nous aimerions couvrir la configuration de cette fonctionnalité car elle peut ne pas être claire au premier coup d'œil.
Comme pour la réplication MySQL et la réplication de groupe MySQL, une table a été créée dans ProxySQL :
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Il existe de nombreux paramètres à configurer et nous allons les parcourir un par un. Tout d'abord, il existe quatre groupes d'hôtes :
- Writer_hostgroup - il contiendra tous les écrivains (avec read_only=0) jusqu'au paramètre 'max_writers'. Par défaut, il n'y a qu'un seul rédacteur
- Backup_writer_hostgroup - il contient les écrivains restants (read_only=0) qui restent après l'ajout de "max_writers" à writer_hostgroup
- Reader_hostgroup - il contient des lecteurs (read_only=1), il peut également contenir des écrivains de sauvegarde, selon le paramètre "writer_is_also_reader"
- Offline_hostgroup - il contient des nœuds qui ont été jugés inutilisables (soit hors ligne, soit dans un état qui les rend impossibles à gérer le trafic)
Ensuite, nous avons les paramètres restants :
- Actif - si l'entrée dans mysql_galera_hostgroups est active ou non
- Max_writers - combien de nœuds au maximum peuvent être placés dans le writer_hostgroup
- Writer_is_also_reader - si défini sur 0, les écrivains (read_only=0) ne seront pas placés dans reader_hostgroup. Si défini sur 1, les écrivains (read_only=0) seront placés dans reader_hostgroup. Si défini sur 2, les nœuds de backup_writer_hostgroup seront placés dans reader_hostgroup. Celui-ci est un peu complexe donc nous présenterons un exemple plus tard dans ce billet de blog
- Max_transactions_behind :basé sur wsrep_local_recv_queue, la file d'attente maximale acceptable. Si la file d'attente sur le nœud dépasse max_transactions_behind, le nœud donné sera marqué comme SHUNNED et il ne sera pas disponible pour le trafic
La principale surprise pourrait être la gestion des lecteurs, qui est différente de la façon dont le script inclus dans ProxySQL fonctionnait. Tout d'abord, ce que vous devez garder à l'esprit, c'est le fait que ProxySQL utilise read_only=1 pour décider si le nœud est un lecteur ou non. Ceci est courant dans les configurations de réplication, pas si courant dans Galera. Par conséquent, vous souhaiterez très probablement utiliser le paramètre « writer_is_also_reader » pour configurer la manière dont les lecteurs doivent être ajoutés au groupe d'hôtes reader. Considérons trois nœuds Galera, tous ont read_only=0. Nous avons également max_writers=1 car nous voulons diriger toutes les écritures vers un nœud. Nous avons configuré mysql_galera_hostgroups comme suit :
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Passons en revue toutes les options :
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Ce résultat est différent de ce que vous verriez dans les scripts - là, vous auriez des nœuds restants marqués comme lecteurs. Ici, étant donné que nous ne voulons pas que les écrivains soient des lecteurs et qu'il n'y ait pas de nœud avec read_only=1, aucun lecteur ne sera configuré. Un écrivain (selon max_writers), nœuds restants dans backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Ici, nous voulons que nos rédacteurs agissent en tant que lecteurs, donc tous (actifs et de sauvegarde) seront placés dans le reader_hostgroup.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)C'est un paramètre pour ceux qui ne veulent pas que leur rédacteur actif gère les lectures. Dans ce cas, seuls les nœuds de backup_writer_hostgroup seront utilisés pour les lectures. Veuillez également garder à l'esprit que le nombre de lecteurs changera si vous définissez max_writers sur une autre valeur. Si nous le définissions sur 3, il n'y aurait pas d'écrivains de sauvegarde (tous les nœuds se retrouveraient dans le groupe d'hôtes de l'écrivain) donc, encore une fois, il n'y aurait pas de nœuds dans le groupe d'hôtes du lecteur.
Bien sûr, vous souhaiterez configurer les règles de requête en fonction de la configuration du groupe d'hôtes. Nous n'aborderons pas ce processus ici, vous pouvez vérifier comment cela peut être fait dans le blog ProxySQL. Si vous souhaitez tester son fonctionnement dans un environnement Docker, nous avons un blog qui explique comment exécuter le cluster Galera et ProxySQL 2.0 sur Docker.
Autres modifications
Ce que nous avons décrit ci-dessus sont les améliorations les plus notables de ProxySQL 2.0. Il y en a beaucoup d'autres, selon le changelog. Il convient de mentionner les améliorations apportées au cache de requêtes (par exemple, l'ajout de PROXYSQL FLUSH QUERY CACHE) et les modifications qui permettent à ProxySQL de s'appuyer sur super_read_only pour déterminer le maître et les esclaves dans la configuration de la réplication.
Nous espérons que ce bref aperçu des modifications apportées à ProxySQL 2.0 vous aidera à déterminer la version de ProxySQL à utiliser. Veuillez garder à l'esprit que la branche 1.4, même si elle n'obtiendra aucune nouvelle fonctionnalité, elle est toujours maintenue.
