Dans la première partie de la série, nous vous avons montré comment déployer une configuration de réplication MySQL avec ProxySQL avec WHM et cPanel. Dans cette partie, nous allons montrer quelques opérations post-déploiement pour la maintenance, la gestion, le basculement ainsi que les avantages par rapport à la configuration autonome.
Gestion des utilisateurs MySQL
Avec cette intégration activée, la gestion des utilisateurs MySQL devra se faire depuis WHM ou cPanel. Sinon, la table ProxySQL mysql_users ne se synchroniserait pas avec ce qui est configuré pour notre maître de réplication. Supposons que nous ayons déjà créé un utilisateur appelé plusieursn_user1 (le nom d'utilisateur MySQL est automatiquement préfixé par cPanel pour se conformer à la limitation de MySQL), et nous aimerions affecter à la base de données plusieursn_db1 comme ci-dessous :
Ce qui précède entraînera la sortie suivante de la table mysql_users dans ProxySQL :
Si vous souhaitez créer des ressources MySQL en dehors de cPanel, vous pouvez utiliser ClusterControl -> Gérer -> Schémas et utilisateurs puis importez l'utilisateur de la base de données dans ProxySQL en allant dans ClusterControl -> Nodes -> choisissez le nœud ProxySQL -> Users -> Import Users .
Le module Proxysqlhook que nous utilisons pour synchroniser les utilisateurs de ProxySQL envoie les journaux de débogage dans /usr/local/cpanel/logs/error_log. Utilisez ce fichier pour inspecter et comprendre ce qui se passe dans les coulisses. Les lignes suivantes apparaîtraient dans le fichier journal cPanel si nous installions une application Web appelée Zikula à l'aide de Softaculous :
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Vous verriez des lignes répétées comme "Vérifier si {utilisateur DB} existe" car WHM crée plusieurs utilisateurs/hôtes MySQL pour chaque demande d'utilisateur de création de base de données. Dans notre exemple, WHM créerait ces 3 utilisateurs :
ProxySQL n'a besoin que du nom d'utilisateur, du mot de passe et des informations de groupe d'hôtes par défaut lors de l'ajout d'un utilisateur. Par conséquent, les lignes de vérification sont là pour éviter plusieurs insertions du même utilisateur.
Si vous souhaitez modifier le module et y apporter des améliorations, n'oubliez pas de réenregistrer le module en exécutant la commande suivante sur le serveur WHM :
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookSurveillance et mise en cache des requêtes
Avec ProxySQL, vous pouvez surveiller toutes les requêtes provenant de l'application qui lui sont passées ou qui la traversent. Le WHM standard ne fournit pas ce niveau de détail dans la surveillance des requêtes MySQL. Voici toutes les requêtes MySQL qui ont été capturées par ProxySQL :
Avec ClusterControl, vous pouvez facilement rechercher les requêtes les plus répétées et les mettre en cache via la fonction de cache de requête ProxySQL. Utilisez le menu déroulant "Order By" pour trier les requêtes par "Count Star", passez à la requête que vous souhaitez mettre en cache et cliquez sur le bouton "Cache Query" en dessous. La boîte de dialogue suivante apparaît :
L'ensemble de résultats des requêtes mises en cache sera stocké et servi par ProxySQL lui-même, réduisant ainsi le nombre d'accès au backend, ce qui déchargera votre cluster de réplication MySQL dans son ensemble. L'implémentation du cache de requêtes ProxySQL est fondamentalement différente du cache de requêtes MySQL. Il s'agit d'un cache basé sur le temps et expirera après un délai appelé "Cache TTL". Dans cette configuration, nous aimerions mettre en cache la requête ci-dessus pendant 5 secondes (5000 ms) après avoir atteint le groupe de lecteurs où le groupe d'hôtes de destination est 20.
Division et équilibrage en lecture/écriture
En écoutant le port 3306 par défaut de MySQL, ProxySQL agit en quelque sorte comme le serveur MySQL lui-même. Il parle des protocoles MySQL sur le frontend et le backend. Les règles de requête définies par ClusterControl lors de la configuration de ProxySQL diviseront automatiquement toutes les lectures (^SELECT .* en langage Regex) vers le groupe d'hôtes 20 qui est le groupe de lecteurs, et le reste sera transmis au groupe d'hôtes écrivain 10, comme indiqué dans le section de règles de requête suivante :
Avec cette architecture, vous n'avez pas à vous soucier de diviser les requêtes en lecture/écriture car ProxySQL fera le travail pour vous. Les utilisateurs n'ont que peu ou pas de modifications du code, ce qui permet aux utilisateurs de l'hébergement d'utiliser toutes les applications et fonctionnalités fournies par WHM et cPanel de manière native, comme pour se connecter à une configuration MySQL autonome.
En termes d'équilibrage des connexions, si vous avez plus d'un nœud actif dans un groupe d'hôtes particulier (comme le groupe d'hôtes lecteur 20 dans cet exemple), ProxySQL répartira automatiquement la charge entre eux en fonction d'un certain nombre de critères - poids, délai de réplication, connexions utilisées , la charge globale et la latence. ProxySQL est connu pour être très efficace dans un environnement à forte concurrence en implémentant un mécanisme avancé de regroupement de connexions. Cité du billet de blog ProxySQL, ProxySQL n'implémente pas seulement la connexion persistante, mais également le multiplexage des connexions. En fait, ProxySQL peut gérer des centaines de milliers de clients, tout en transférant tout leur trafic vers quelques connexions au backend. ProxySQL peut donc gérer N connexions client et M connexions backend , où N> M (même N milliers de fois plus grand que M).
Basculement et récupération MySQL
Avec ClusterControl gérant le cluster de réplication, le basculement est effectué automatiquement si la récupération automatique est activée. En cas de panne du maître :
- ClusterControl détectera et vérifiera la défaillance du maître via le client MySQL, SSH et ping.
- ClusterControl attendra 3 secondes avant de commencer une procédure de basculement.
- ClusterControl promouvra l'esclave le plus récent pour qu'il devienne le prochain maître.
- Si l'ancien maître revient en ligne, il sera démarré en lecture seule, sans participer à la réplication active.
- C'est aux utilisateurs de décider ce qu'il adviendra de l'ancien maître. Il pourrait être réintroduit dans la chaîne de réplication en utilisant la fonctionnalité "Reconstruire l'esclave de réplication" dans ClusterControl.
- ClusterControl ne tentera d'effectuer le basculement maître qu'une seule fois. En cas d'échec, l'intervention de l'utilisateur est requise.
Vous pouvez surveiller l'ensemble du processus de basculement sous ClusterControl -> Activité -> Tâches -> Basculement vers un nouveau maître comme indiqué ci-dessous :
Pendant le basculement, toutes les connexions aux serveurs de base de données seront mises en file d'attente dans ProxySQL. Ils ne seront pas terminés avant l'expiration du délai, contrôlé par mysql-default_query_timeout variable qui est de 86400000 millisecondes ou 24 heures. Les applications ne verraient probablement pas d'erreurs ou d'échecs dans la base de données à ce stade, mais le compromis est une latence accrue, dans un seuil configurable.
À ce stade, ClusterControl présentera la topologie comme ci-dessous :
Si nous souhaitons autoriser l'ancien maître à se joindre à la réplication une fois qu'il est opérationnel et disponible, nous aurions besoin de le reconstruire en tant qu'esclave en allant dans ClusterControl -> Nodes -> choisir l'ancien maître -> Reconstruire la réplication Esclave -> choisissez le nouveau maître -> Continuer . Une fois la reconstruction terminée, vous devriez obtenir la topologie suivante (notez que 192.168.0.32 est maintenant le maître) :
Consolidation du serveur et mise à l'échelle de la base de données
Avec cette architecture, nous pouvons consolider de nombreux serveurs MySQL qui résident sur chaque serveur WHM en une seule configuration de réplication. Vous pouvez mettre à l'échelle plus de nœuds de base de données au fur et à mesure de votre croissance, ou avoir plusieurs clusters de réplication pour tous les prendre en charge et gérés par un seul serveur ClusterControl. Le schéma d'architecture suivant illustre si nous avons deux serveurs WHM connectés à un seul cluster de réplication MySQL via le fichier de socket ProxySQL :
Ce qui précède nous permet de séparer les deux niveaux les plus importants de notre système d'hébergement - l'application (front-end) et la base de données (back-end). Comme vous le savez peut-être, la colocalisation de MySQL dans le serveur WHM entraîne généralement l'épuisement des ressources, car MySQL a besoin d'une énorme allocation de RAM initiale pour démarrer et fonctionner correctement (principalement en fonction de innodb_buffer_pool_size variable). Considérant que l'espace disque est suffisant, avec la configuration ci-dessus, vous pouvez avoir plus de comptes d'hébergement hébergés par serveur, où toutes les ressources du serveur peuvent être utilisées par les applications de niveau frontal.
La mise à l'échelle du cluster de réplication MySQL sera beaucoup plus simple avec une architecture à plusieurs niveaux. Si disons que le maître nécessite une maintenance évolutive (mise à niveau de la RAM, du disque dur, du RAID, de la carte réseau), nous pouvons basculer le rôle du maître vers un autre esclave (ClusterControl -> Nodes -> pick a slave -> Promote Slave ) puis effectuez la tâche de maintenance sans affecter le service MySQL dans son ensemble. Pour une opération scale-out (ajouter plus d'esclaves), vous pouvez effectuer cela sans même affecter le maître en effectuant la mise en scène directement à partir de n'importe quel esclave actif. Avec ClusterControl, vous pouvez même mettre en scène un nouvel esclave à partir d'une sauvegarde MySQL existante (compatible PITR uniquement) :
La reconstruction d'un esclave à partir d'une sauvegarde n'apportera pas de charge supplémentaire au maître. ClusterControl copiera le fichier de sauvegarde sélectionné du serveur ClusterControl vers le nœud cible et y effectuera la restauration. Une fois cela fait, le nœud se connectera au maître et commencera à récupérer toutes les transactions manquantes depuis l'heure de restauration et rattrapera le maître. Lorsqu'il est en retard, ProxySQL n'inclura pas le nœud dans l'ensemble d'équilibrage de charge jusqu'à ce que le retard de réplication soit inférieur à 10 secondes (configurable lors de l'ajout d'une table mysql_servers via l'interface d'administration ProxySQL).
Réflexions finales
ProxySQL étend les capacités de WHM cPanel dans la gestion de la réplication MySQL. Avec ClusterControl gérant votre cluster de réplication, toutes les tâches complexes impliquées dans la gestion du cluster de réplication sont désormais plus faciles que jamais.
