MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Comment migrer la base de données WHMCS vers MariaDB Galera Cluster

WHMCS est une solution tout-en-un de gestion des clients, de facturation et d'assistance pour les sociétés d'hébergement Web. C'est l'un des leaders dans le monde de l'automatisation de l'hébergement à utiliser avec le panneau de contrôle de l'hébergement lui-même. WHMCS s'exécute sur une pile LAMP, avec MySQL/MariaDB comme fournisseur de base de données. Généralement, WHMCS est installé en tant qu'instance autonome (application et base de données) indépendamment en suivant le guide d'installation de WHMCS ou via des outils d'installation de logiciels tels que cPanel Site Software ou Softaculous. La base de données peut être rendue hautement disponible en migrant vers un cluster Galera de 3 nœuds.

Dans cet article de blog, nous allons vous montrer comment migrer la base de données WHMCS d'un serveur MySQL autonome (fourni par le serveur WHM/cPanel lui-même) vers un cluster externe MariaDB Galera à trois nœuds pour améliorer la disponibilité de la base de données. L'application WHMCS elle-même continuera à fonctionner sur le même serveur cPanel. Nous vous donnerons également quelques conseils de réglage pour optimiser les performances.

Déploiement du cluster de bases de données

  1. Installez ClusterControl :
    $ whoami
root
$ wget https://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc
    Suivez les instructions en conséquence jusqu'à ce que l'installation soit terminée. Ensuite, allez sur http://192.168.55.50/clustercontrol (192.168.55.50 étant l'adresse IP de l'hôte ClusterControl) et enregistrez un utilisateur super administrateur avec un mot de passe et d'autres détails requis.
  2. Configurer SSH sans mot de passe de ClusterControl à tous les nœuds de la base de données :
    $ whoami
root
$ ssh-keygen -t rsa # Press enter on all prompts
$ ssh-copy-id 192.168.55.51
$ ssh-copy-id 192.168.55.52
$ ssh-copy-id 192.168.55.53
  3. Configurer le déploiement de la base de données pour notre cluster MariaDB Galera à 3 nœuds. Nous allons utiliser la dernière version prise en charge MariaDB 10.3 : Assurez-vous d'obtenir toutes les coches vertes après avoir appuyé sur "Entrée" lors de l'ajout des détails du nœud. Attendez que la tâche de déploiement se termine et vous devriez voir que le cluster de bases de données est répertorié dans ClusterControl.
  4. Déployez un nœud ProxySQL (nous allons le colocaliser avec le nœud ClusterControl) en allant dans Gérer -> Équilibreur de charge -> ProxySQL -> Déployer ProxySQL . Spécifiez les détails requis suivants : Sous "Ajouter un utilisateur de base de données", vous pouvez demander à ClusterControl de créer un nouvel utilisateur ProxySQL et MySQL lors de la configuration , ainsi nous mettons l'utilisateur comme "portal_whmcs", assigné avec TOUS LES PRIVILÈGES sur la base de données "portal_whmcs.*". Ensuite, cochez toutes les cases pour "Inclure" et choisissez enfin "faux" pour "Avez-vous utilisé des transactions implicites ?".

Une fois le déploiement terminé, vous devriez voir quelque chose comme ceci sous la vue Topologie :

Ressources associées Le meilleur fournisseur d'hébergement d'Australie tire parti de ClusterControl pour offrir une expérience de classe mondiale à ses utilisateurs Équilibrage de charge de base de données pour MySQL et MariaDB avec ProxySQL - Tutoriel MySQL haute disponibilité sur cPanel avec Galera Cluster

Le déploiement de notre base de données est maintenant terminé. Gardez à l'esprit que nous ne couvrons pas la redondance du niveau de l'équilibreur de charge dans ce billet de blog. Vous pouvez y parvenir en ajoutant un équilibreur de charge secondaire et en les enchaînant avec Keepalived. Pour en savoir plus à ce sujet, consultez les didacticiels ProxySQL au chapitre "4.2. Haute disponibilité pour ProxySQL".

Installation WHMCS

Si WHMCS est déjà installé et en cours d'exécution, vous pouvez ignorer cette étape.

Prenez note que WHMCS nécessite une licence valide que vous devez acheter au préalable afin d'utiliser le logiciel. Ils ne fournissent pas de licence d'essai gratuite, mais ils offrent une garantie de remboursement de 30 jours sans poser de questions, ce qui signifie que vous pouvez toujours annuler l'abonnement avant l'expiration de l'offre sans être facturé.

Pour simplifier le processus d'installation, nous allons utiliser le logiciel de site cPanel (vous pouvez opter pour l'installation manuelle de WHMCS) sur l'un de nos sous-domaines, selfportal.mytest.io. Après avoir créé le compte dans WHM, allez dans cPanel> Logiciel> Logiciel de site> WHMCS et installez l'application Web. Connectez-vous en tant qu'utilisateur administrateur et activez la licence pour commencer à utiliser l'application.

À ce stade, notre instance WHMCS s'exécute en tant qu'installation autonome, se connectant au serveur MySQL local.

ClusterControlConsole unique pour l'ensemble de votre infrastructure de base de donnéesDécouvrez les autres nouveautés de ClusterControlInstallez ClusterControl GRATUITEMENT

Migration de la base de données WHMCS vers le cluster MariaDB Galera

L'exécution de WHMCS sur un serveur MySQL autonome expose l'application à un point de défaillance unique (SPOF) du point de vue de la base de données. MariaDB Galera Cluster offre une redondance à la couche de données avec des fonctionnalités de clustering intégrées et une prise en charge de l'architecture multimaître. Combinez cela avec un équilibreur de charge de base de données, par exemple ProxySQL, et nous pouvons améliorer la disponibilité de la base de données WHMCS avec des modifications très minimes de l'application elle-même.

Cependant, il existe un certain nombre de bonnes pratiques que WHMCS (ou d'autres applications) doivent suivre afin de travailler efficacement sur Galera Cluster, notamment :

  • Toutes les tables doivent être exécutées sur le moteur de stockage InnoDB/XtraDB.
  • Toutes les tables doivent avoir une clé primaire définie (la clé primaire multi-colonnes est prise en charge, la clé unique ne compte pas).

Selon la version installée, dans notre installation d'environnement de test (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 via le logiciel du site), les deux points ci-dessus ne répondaient pas à l'exigence. La configuration par défaut de cPanel/WHM MySQL est fournie avec la ligne suivante dans /etc/my.cnf :

default-storage-engine=MyISAM

Ce qui précède entraînerait la création de tables supplémentaires gérées par les modules complémentaires WHMCS au format du moteur de stockage MyISAM si ces modules sont activés. Voici la sortie du moteur de stockage après avoir activé 2 modules (nouveaux TLD et tableau d'affichage du personnel) :

MariaDB> SELECT tables.table_schema, tables.table_name, tables.engine FROM information_schema.tables WHERE tables.table_schema='whmcsdata_whmcs' and tables.engine <> 'InnoDB';
+-----------------+----------------------+--------+
| table_schema    | table_name           | engine |
+-----------------+----------------------+--------+
| whmcsdata_whmcs | mod_enomnewtlds      | MyISAM |
| whmcsdata_whmcs | mod_enomnewtlds_cron | MyISAM |
| whmcsdata_whmcs | mod_staffboard       | MyISAM |
+-----------------+----------------------+--------+

La prise en charge de MyISAM est expérimentale dans Galera, ce qui signifie que vous ne devez pas l'exécuter en production. Dans le pire des cas, cela pourrait compromettre la cohérence des données et entraîner des échecs de réplication du jeu d'écriture en raison de sa nature non transactionnelle.

Un autre point important est que chaque table doit avoir une clé primaire définie. Selon la procédure d'installation de WHMCS que vous avez effectuée (comme pour nous, nous avons utilisé le logiciel de site cPanel pour installer WHMCS), certaines des tables créées par le programme d'installation ne sont pas accompagnées d'une clé primaire définie, comme indiqué dans la sortie suivante :

MariaDB [information_schema]> SELECT TABLES.table_schema, TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;
+-----------------+------------------------------------+
| table_schema    | table_name                         |
+-----------------+------------------------------------+
| whmcsdata_whmcs | mod_invoicedata                    |
| whmcsdata_whmcs | tbladminperms                      |
| whmcsdata_whmcs | tblaffiliates                      |
| whmcsdata_whmcs | tblconfiguration                   |
| whmcsdata_whmcs | tblknowledgebaselinks              |
| whmcsdata_whmcs | tbloauthserver_access_token_scopes |
| whmcsdata_whmcs | tbloauthserver_authcode_scopes     |
| whmcsdata_whmcs | tbloauthserver_client_scopes       |
| whmcsdata_whmcs | tbloauthserver_user_authz_scopes   |
| whmcsdata_whmcs | tblpaymentgateways                 |
| whmcsdata_whmcs | tblproductconfiglinks              |
| whmcsdata_whmcs | tblservergroupsrel                 |
+-----------------+------------------------------------+

En remarque, Galera autoriserait toujours l'existence de tables sans clé primaire. Cependant, les opérations DELETE ne sont pas prises en charge sur ces tables et cela vous exposerait à des problèmes beaucoup plus importants comme un plantage de nœud, une dégradation des performances de la certification du jeu d'écriture ou des lignes peuvent apparaître dans un ordre différent sur différents nœuds.

Pour surmonter cela, notre plan de migration doit inclure l'étape supplémentaire de correction du moteur de stockage et de la structure du schéma, comme indiqué dans la section suivante.

Plan de migration

En raison des restrictions expliquées dans le chapitre précédent, notre plan de migration doit ressembler à ceci :

  1. Activer le mode de maintenance WHMCS
  2. Effectuez des sauvegardes de la base de données whmcs à l'aide d'une sauvegarde logique
  3. Modifier les fichiers de vidage pour répondre aux exigences de Galera (convertir le moteur de stockage)
  4. Allumez l'un des nœuds Galera et laissez les nœuds restants s'éteindre
  5. Restaurer vers le nœud Galera choisi
  6. Corrigez la structure du schéma pour répondre aux exigences de Galera (clés primaires manquantes)
  7. Amorcer le cluster à partir du nœud Galera choisi
  8. Démarrez le deuxième nœud et laissez-le se synchroniser
  9. Démarrez le troisième nœud et laissez-le se synchroniser
  10. Modifier la base de données pointant vers le point de terminaison approprié
  11. Désactiver le mode de maintenance WHMCS

La nouvelle architecture peut être illustrée comme ci-dessous :

Le nom de notre base de données WHMCS sur le serveur cPanel est "whmcsdata_whmcs" et nous allons migrer cette base de données vers un cluster externe MariaDB Galera à trois nœuds déployé par ClusterControl. En plus du serveur de base de données, nous avons un ProxySQL (colocalisé avec ClusterControl) en cours d'exécution pour agir en tant qu'équilibreur de charge MariaDB, fournissant le point de terminaison unique à notre instance WHMCS. Le nom de la base de données sur le cluster sera changé en "portal_whmcs" à la place, afin que nous puissions facilement le distinguer.

Tout d'abord, activez le mode de maintenance à l'échelle du site en accédant à WHMCS > Configuration > Paramètres généraux > Général > Mode de maintenance > Cochez pour activer - empêche l'accès à la zone client lorsqu'il est activé . Cela garantira qu'il n'y aura aucune activité de la part de l'utilisateur final pendant l'opération de sauvegarde de la base de données.

Étant donné que nous devons apporter de légères modifications à la structure du schéma pour bien l'adapter à Galera, c'est une bonne idée de créer deux fichiers de vidage distincts. Un avec le schéma uniquement et un autre pour les données uniquement. Sur le serveur WHM, exécutez la commande suivante en tant que root :

$ mysqldump --no-data -uroot whmcsdata_whmcs > whmcsdata_whmcs_schema.sql
$ mysqldump --no-create-info -uroot whmcsdata_whmcs > whmcsdata_whmcs_data.sql

Ensuite, nous devons remplacer toutes les occurrences MyISAM dans le fichier de vidage du schéma par 'InnoDB' :

$ sed -i 's/MyISAM/InnoDB/g' whmcsdata_whmcs_schema.sql

Vérifiez que nous n'avons plus de lignes MyISAM dans le fichier de vidage (il ne devrait rien renvoyer) :

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Transférez les fichiers de vidage du serveur WHM vers mariadb1 (192.168.55.51) :

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Créez la base de données MySQL. Depuis ClusterControl, accédez à Gérer -> Schémas et utilisateurs -> Créer une base de données et indiquez le nom de la base de données. Ici, nous utilisons un nom de base de données différent appelé "portal_whmcs". Sinon, vous pouvez créer manuellement la base de données avec la commande suivante :

$ mysql -uroot -p 
MariaDB> CREATE DATABASE 'portal_whmcs';

Créez un utilisateur MySQL pour cette base de données avec ses privilèges. Depuis ClusterControl, accédez à Gérer -> Schémas et utilisateurs -> Utilisateurs -> Créer un nouvel utilisateur et précisez ce qui suit :

Si vous choisissez de créer l'utilisateur MySQL manuellement, exécutez les instructions suivantes :

$ mysql -uroot -p 
MariaDB> CREATE USER 'portal_whmcs'@'%' IDENTIFIED BY 'ghU51CnPzI9z';
MariaDB> GRANT ALL PRIVILEGES ON portal_whmcs.* TO [email protected]'%';

Notez que l'utilisateur de base de données créé doit être importé dans ProxySQL, pour permettre à l'application WHMCS de s'authentifier auprès de l'équilibreur de charge. Allez dans Nœuds -> choisissez le nœud ProxySQL -> Utilisateurs -> Importer des utilisateurs et sélectionnez "portal_whmcs"@"%", comme indiqué dans la capture d'écran suivante :

Dans la fenêtre suivante (Paramètres utilisateur), spécifiez le groupe d'hôtes 10 comme groupe d'hôtes par défaut :

L'étape de préparation de la restauration est maintenant terminée.

Dans Galera, la restauration d'une grande base de données via mysqldump sur un cluster à nœud unique est plus efficace, ce qui améliore considérablement le temps de restauration. Sinon, chaque nœud du cluster devrait certifier chaque instruction de l'entrée mysqldump, ce qui prendrait plus de temps.

Puisque nous avons déjà un cluster MariaDB Galera à trois nœuds en cours d'exécution, arrêtons le service MySQL sur mariadb2 et mariadb3, un nœud à la fois pour une mise à l'échelle progressive. Pour arrêter les nœuds de la base de données, depuis ClusterControl, allez simplement dans Nodes -> Node Actions -> Stop Node -> Proceed . Voici ce que vous verriez dans le tableau de bord ClusterControl, où la taille du cluster est 1 et le statut de db1 est Synced and Primary :

Ensuite, sur mariadb1 (192.168.55.51), restaurez le schéma et les données en conséquence :

$ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_schema.sql
$ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_data.sql

Une fois importé, nous devons corriger la structure de la table pour ajouter la colonne "id" nécessaire (sauf pour la table "tblaffiliates") ainsi que l'ajout de la clé primaire sur toutes les tables qui en manquaient :

$ mysql -uportal_whmcs -p
MariaDB> USE portal_whmcs;
MariaDB [portal_whmcs]> ALTER TABLE `tblaffiliates` ADD PRIMARY KEY (id);
MariaDB [portal_whmcs]> ALTER TABLE `mod_invoicedata` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbladminperms` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblconfiguration` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblknowledgebaselinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_access_token_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_authcode_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_client_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_user_authz_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblpaymentgateways` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblproductconfiglinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblservergroupsrel` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;

Ou, nous pouvons traduire les déclarations répétées ci-dessus en utilisant une boucle dans un script bash :

#!/bin/bash

db_user='portal_whmcs'
db_pass='ghU51CnPzI9z'
db_whmcs='portal_whmcs'
tables=$(mysql -u${db_user} "-p${db_pass}"  information_schema -A -Bse "SELECT TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;")
mysql_exec="mysql -u${db_user} -p${db_pass} $db_whmcs -e"

for table in $tables
do
        if [ "${table}" = "tblaffiliates" ]
        then
                $mysql_exec "ALTER TABLE ${table} ADD PRIMARY KEY (id)";
        else
                $mysql_exec "ALTER TABLE ${table} ADD id INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST";
        fi
done

À ce stade, vous pouvez démarrer en toute sécurité les nœuds restants pour les synchroniser avec mariadb1. Commencez avec mariadb2 en allant dans Nœuds -> choisissez db2 -> Actions du nœud -> Démarrer le nœud . Surveillez la progression du travail et assurez-vous que mariadb2 est dans l'état Synchronisé et Principal (surveillez la page Présentation pour plus de détails) avant de démarrer mariadb3.

Enfin, modifiez la base de données pointant vers l'hôte ProxySQL sur le port 6033 dans le fichier de configuration WHMCS, comme dans notre cas, il se trouve dans /home/whmcsdata/public_html/configuration.php :

$ vim configuration.php
<?php
$license = 'WHMCS-XXXXXXXXXXXXXXXXXXXX';
$templates_compiledir = 'templates_c';
$mysql_charset = 'utf8';
$cc_encryption_hash = 'gLg4oxuOWsp4bMleNGJ--------30IGPnsCS49jzfrKjQpwaN';
$db_host = 192.168.55.50;
$db_port = '6033';
$db_username = 'portal_whmcs';
$db_password = 'ghU51CnPzI9z';
$db_name = 'portal_whmcs';

$customadminpath = 'admin2d27';

N'oubliez pas de désactiver le mode de maintenance WHMCS en allant dans WHMCS> Configuration> Paramètres généraux> Général> Mode de maintenance> décochez "Cocher pour activer - empêche l'accès à l'espace client lorsqu'il est activé" . Notre exercice de migration de base de données est maintenant terminé.

Test et réglage

Vous pouvez vérifier si en regardant les entrées de requête de ProxySQL sous Nœuds -> ProxySQL -> Top Requêtes :

Pour les requêtes en lecture seule les plus répétées (vous pouvez les trier par nombre d'étoiles), vous pouvez les mettre en cache pour améliorer le temps de réponse et réduire le nombre d'accès aux serveurs principaux. Passez simplement à n'importe quelle requête et cliquez sur Mettre en cache la requête, et la fenêtre contextuelle suivante apparaît :

Ce que vous devez faire est de choisir uniquement le groupe d'hôtes de destination et de cliquer sur "Ajouter une règle". Vous pouvez ensuite vérifier si la requête en cache a été touchée sous l'onglet "Règles" :

À partir de la règle de requête elle-même, nous pouvons dire que les lectures (tous les SELECT sauf SELECT .. FOR UPDATE) sont transmises au groupe d'hôtes 20 où les connexions sont distribuées à tous les nœuds tandis que les écritures (autres que SELECT) sont transmises au groupe d'hôtes 10, où les connexions sont transmises à un seul nœud Galera. Cette configuration minimise le risque de blocage pouvant être causé par une configuration multi-maître, ce qui améliore les performances de réplication dans son ensemble.

C'est tout pour le moment. Bon regroupement !