Le cloud offre des environnements de travail très flexibles. Vous pouvez facilement le faire évoluer en ajoutant ou en supprimant des nœuds. En cas de besoin, vous pouvez facilement créer un clone de votre environnement. Cela peut être utilisé pour des processus tels que les mises à niveau, les tests de charge, la reprise après sinistre. Le principal problème auquel vous devez faire face est que les applications doivent se connecter aux bases de données d'une manière ou d'une autre, et les configurations flexibles peuvent être délicates pour les bases de données - en particulier avec les configurations maître-esclave. Heureusement, il existe des options pour faciliter ce processus.
Une façon consiste à utiliser un proxy de base de données. Il existe plusieurs proxys parmi lesquels choisir, mais dans cet article de blog, nous utiliserons ProxySQL, un proxy bien connu disponible pour MySQL et MariaDB. Nous allons montrer comment vous pouvez l'utiliser pour déplacer efficacement le trafic entre les nœuds MySQL sans impact visible pour l'application. Nous allons également expliquer certaines limites et inconvénients de cette approche.
Configuration initiale du cloud
D'abord, parlons de la configuration. Nous utiliserons des instances AWS EC2 pour notre environnement. Comme nous ne faisons que tester, nous ne nous soucions pas vraiment de la haute disponibilité autre que ce que nous voulons prouver comme étant possible - des modifications principales transparentes. Par conséquent, nous utiliserons un seul nœud d'application et un seul nœud ProxySQL. Conformément aux bonnes pratiques, nous colocaliserons ProxySQL sur le nœud de l'application et l'application sera configurée pour se connecter à ProxySQL via le socket Unix. Cela réduira les frais généraux liés aux connexions TCP et augmentera la sécurité - le trafic de l'application vers le proxy ne quittera pas l'instance locale, ne laissant que la connexion ProxySQL -> MySQL à chiffrer. Encore une fois, comme il s'agit d'un test simple, nous ne configurerons pas SSL. Dans les environnements de production, vous souhaitez le faire, même si vous utilisez VPC.
L'environnement ressemblera au schéma ci-dessous :
En tant qu'application, nous utiliserons Sysbench - un programme de référence synthétique pour MySQL . Il a une option pour désactiver et activer l'utilisation des transactions, que nous utiliserons pour démontrer comment ProxySQL les gère.
Installation d'un cluster de réplication MySQL à l'aide de ClusterControl
Pour rendre le déploiement rapide et efficace, nous allons utiliser ClusterControl pour déployer la configuration de réplication MySQL pour nous. L'installation de ClusterControl ne nécessite que quelques étapes. Nous n'entrerons pas dans les détails ici, mais vous devez ouvrir notre site Web, vous inscrire et l'installation de ClusterControl devrait être assez simple. N'oubliez pas que vous devez configurer SSH sans mot de passe entre l'instance ClusterControl et tous les nœuds que nous allons gérer avec.
Une fois ClusterControl installé, vous pouvez vous connecter. Un assistant de déploiement vous sera présenté :
Comme nous avons déjà des instances fonctionnant dans le cloud, nous allons donc simplement utiliser Option "Déployer". L'écran suivant s'affichera :
Nous choisirons la réplication MySQL comme type de cluster et nous devons fournir la connectivité des détails. Il peut s'agir d'une connexion en utilisant l'utilisateur root ou d'un utilisateur sudo avec ou sans mot de passe.
Dans la prochaine étape, nous devons prendre des décisions. Nous utiliserons Percona Server pour MySQL dans sa dernière version. Nous devons également définir un mot de passe pour l'utilisateur root sur les nœuds que nous allons déployer.
Dans la dernière étape, nous devons définir une topologie - nous irons avec ce que nous avons proposé au début - un maître et trois esclaves.
ClusterControl va démarrer le déploiement - nous pouvons le suivre dans l'onglet Activité, comme indiqué sur la capture d'écran ci-dessus.
Une fois le déploiement terminé, nous pouvons voir le cluster dans la liste des clusters :
Installation de ProxySQL 2.0 à l'aide de ClusterControl
La prochaine étape consistera à déployer ProxySQL. ClusterControl peut le faire pour nous.
Nous pouvons le faire dans Gérer -> Load Balancer.
Comme nous ne faisons que tester des choses, nous allons réutiliser l'instance ClusterControl pour ProxySQL et Sysbench. Dans la vraie vie, vous voudriez probablement utiliser votre "vrai" serveur d'applications. Si vous ne la trouvez pas dans la liste déroulante, vous pouvez toujours écrire l'adresse du serveur (IP ou nom d'hôte) à la main.
Nous souhaitons également définir les informations d'identification pour l'utilisateur de surveillance et d'administration. Nous avons également vérifié que ProxySQL 2.0 sera déployé (vous pouvez toujours le changer en 1.4.x si vous en avez besoin).
Dans la partie inférieure de l'assistant, nous définirons l'utilisateur qui sera créé à la fois dans MySQL et ProxySQL. Si vous avez une application existante, vous souhaiterez probablement utiliser un utilisateur existant. Si vous utilisez de nombreux utilisateurs pour votre application, vous pourrez toujours importer les autres ultérieurement, après le déploiement de ProxySQL.
Nous voulons nous assurer que toutes les instances MySQL seront configurées dans ProxySQL. Nous utiliserons des transactions explicites afin de définir le commutateur en conséquence. C'est tout ce que nous devions faire - le reste est de cliquer sur le bouton "Déployer ProxySQL" et de laisser ClusterControl faire son travail.
Une fois l'installation terminée, ProxySQL apparaîtra dans la liste des nœuds dans le cluster. Comme vous pouvez le voir sur la capture d'écran ci-dessus, il a déjà détecté la topologie et réparti les nœuds sur les groupes d'hôtes de lecture et d'écriture.
Installer Sysbench
La dernière étape consistera à créer notre "application" en installant Sysbench. Le processus est assez simple. Dans un premier temps, nous devons installer les prérequis, les bibliothèques et les outils nécessaires à la compilation de Sysbench :
[email protected]:~# apt install git automake libtool make libssl-dev pkg-config libmysqlclient-dev
Ensuite, nous voulons cloner le référentiel sysbench :
[email protected]:~# git clone https://github.com/akopytov/sysbench.git
Enfin, nous voulons compiler et installer Sysbench :
[email protected]:~# cd sysbench/
[email protected]:~/sysbench# ./autogen.sh && ./configure && make && make install
Ça y est, Sysbench est installé. Nous devons maintenant générer des données. Pour cela, dans un premier temps, nous devons créer un schéma. Nous nous connecterons au ProxySQL local et, à travers lui, nous créerons un schéma "sbtest" sur le maître. Veuillez noter que nous avons utilisé le socket Unix pour la connexion avec ProxySQL.
[email protected]:~/sysbench# mysql -S /tmp/proxysql.sock -u sbtest -psbtest
mysql> CREATE DATABASE sbtest;
Query OK, 1 row affected (0.01 sec)
Nous pouvons maintenant utiliser sysbench pour remplir la base de données avec des données. Encore une fois, nous utilisons le socket Unix pour la connexion avec le proxy :
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --events=0 --time=3600 --mysql-socket=/tmp/proxysql.sock --mysql-user=sbtest --mysql-password=sbtest --tables=32 --report-interval=1 --skip-trx=on --table-size=100000 --db-ps-mode=disable prepare
Une fois les données prêtes, nous pouvons procéder à nos tests.
Conclusion
Dans la deuxième partie de ce blog, nous discuterons de la gestion des connexions par ProxySQL, du basculement et de ses paramètres qui peuvent nous aider à gérer le commutateur principal de la manière la moins intrusive pour l'application.