Hoe de WHMCS-database naar MariaDB Galera Cluster te migreren

WHMCS is een alles-in-één oplossing voor klantbeheer, facturering en ondersteuning voor webhostingbedrijven. Het is een van de leiders in de wereld van hostingautomatisering die naast het hostingconfiguratiescherm zelf kan worden gebruikt. WHMCS draait op een LAMP-stack, met MySQL/MariaDB als databaseprovider. Gewoonlijk wordt WHMCS onafhankelijk geïnstalleerd als een zelfstandige instantie (applicatie en database) door de WHMCS-installatiegids te volgen, of via software-installatieprogramma's zoals cPanel Site Software of Softaculous. De database kan zeer beschikbaar worden gemaakt door te migreren naar een Galera-cluster van 3 nodes.

In deze blogpost laten we u zien hoe u de WHMCS-database kunt migreren van een zelfstandige MySQL-server (geleverd door de WHM/cPanel-server zelf) naar een externe MariaDB Galera-cluster met drie knooppunten om de beschikbaarheid van de database te verbeteren. De WHMCS-applicatie zelf blijft draaien op dezelfde cPanel-server. We geven je ook enkele afstemmingstips om de prestaties te optimaliseren.

Het databasecluster implementeren

1. Installeer ClusterControl:

   $ whoami
   root
   $ wget https://severalnines.com/downloads/cmon/install-cc
   $ chmod 755 install-cc
   $ ./install-cc

   Volg de instructies dienovereenkomstig totdat de installatie is voltooid. Ga dan naar de http://192.168.55.50/clustercontrol (192.168.55.50 is het IP-adres van de ClusterControl-host) en registreer een superbeheerder met wachtwoord en andere vereiste details.
2. Stel wachtwoordloze SSH van ClusterControl in op alle databaseknooppunten:

   $ 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. Configureer de database-implementatie voor ons MariaDB Galera-cluster met 3 knooppunten. We gaan de nieuwste ondersteunde versie MariaDB 10.3 gebruiken: Zorg ervoor dat je alle groene vinkjes krijgt nadat je op 'Enter' hebt gedrukt bij het toevoegen van de knooppuntdetails. Wacht tot de implementatietaak is voltooid en u zou moeten zien dat het databasecluster wordt vermeld in ClusterControl.
4. Implementeer een ProxySQL-knooppunt (we gaan het samen met het ClusterControl-knooppunt plaatsen) door naar Beheren -> Load Balancer -> ProxySQL -> ProxySQL implementeren te gaan . Geef de volgende vereiste details op: Onder "Add Database User" kunt u ClusterControl vragen om een ​​nieuwe ProxySQL- en MySQL-gebruiker aan te maken tijdens het instellen , dus plaatsen we de gebruiker als "portal_whmcs", toegewezen met ALLE PRIVILEGES op database "portal_whmcs.*". Vink vervolgens alle vakjes voor "Opnemen" aan en kies ten slotte "false" voor "Gebruikt u impliciete transacties?".

Zodra de implementatie is voltooid, zou u zoiets als dit moeten zien onder de weergave Topologie:

Onze database-implementatie is nu voltooid. Houd er rekening mee dat we de redundantie van de load balancer-laag niet behandelen in deze blogpost. U kunt dat bereiken door een secundaire load balancer toe te voegen en deze samen te voegen met Keepalive. Bekijk voor meer informatie hierover ProxySQL-zelfstudies onder hoofdstuk "4.2. Hoge beschikbaarheid voor ProxySQL".

WHMCS-installatie

Als u WHMCS al geïnstalleerd en actief heeft, kunt u deze stap overslaan.

Houd er rekening mee dat WHMCS een geldige licentie vereist die u vooraf moet aanschaffen om de software te gebruiken. Ze bieden geen gratis proeflicentie, maar ze bieden wel een 30 dagen niet-goed-geld-terug-garantie, wat betekent dat je het abonnement altijd kunt annuleren voordat de aanbieding verloopt zonder dat er kosten in rekening worden gebracht.

Om het installatieproces te vereenvoudigen, gaan we cPanel Site Software gebruiken (u kunt kiezen voor handmatige WHMCS-installatie) op een van onze subdomeinen, selfportal.mytest.io. Ga na het aanmaken van het account in WHM naar cPanel> Software> Site Software> WHMCS en installeer de webapplicatie. Log in als de admin-gebruiker en activeer de licentie om de applicatie te gaan gebruiken.

Op dit moment draait onze WHMCS-instantie als een zelfstandige installatie en maakt verbinding met de lokale MySQL-server.

De WHMCS-database migreren naar MariaDB Galera Cluster

Het uitvoeren van WHMCS op een zelfstandige MySQL-server stelt de toepassing bloot aan single-point-of-failure (SPOF) vanuit databasestandpunt. MariaDB Galera Cluster biedt redundantie aan de gegevenslaag met ingebouwde clusteringfuncties en ondersteuning voor multi-masterarchitectuur. Combineer dit met een database load balancer, bijvoorbeeld ProxySQL, en we kunnen de beschikbaarheid van de WHMCS database verbeteren met zeer minimale wijzigingen aan de applicatie zelf.

Er zijn echter een aantal best-practices die WHMCS (of andere applicaties) moeten volgen om efficiënt te kunnen werken aan Galera Cluster, met name:

• Alle tabellen moeten draaien op de InnoDB/XtraDB-opslagengine.
• Alle tabellen moeten een primaire sleutel hebben gedefinieerd (primaire sleutel met meerdere kolommen wordt ondersteund, unieke sleutel telt niet).

Afhankelijk van de geïnstalleerde versie, in onze testomgeving installatie (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 via Site Software), voldeden de bovenstaande twee punten niet aan de vereiste. De standaard cPanel/WHM MySQL-configuratie wordt geleverd met de volgende regel in /etc/my.cnf:

default-storage-engine=MyISAM

Het bovenstaande zou ertoe leiden dat extra tabellen die worden beheerd door WHMCS-add-onmodules worden gemaakt in MyISAM-opslagengine-indeling als die modules zijn ingeschakeld. Hier is de uitvoer van de opslagengine nadat we 2 modules hebben ingeschakeld (nieuwe TLD's en mededelingenbord voor medewerkers):

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 |
+-----------------+----------------------+--------+

MyISAM-ondersteuning is experimenteel in Galera, wat betekent dat u het niet in productie moet draaien. In sommige ergere gevallen kan het de gegevensconsistentie in gevaar brengen en fouten in de schrijfsetreplicatie veroorzaken vanwege het niet-transactionele karakter.

Een ander belangrijk punt is dat elke tabel een gedefinieerde primaire sleutel moet hebben. Afhankelijk van de WHMCS-installatieprocedure die je hebt uitgevoerd (wat ons betreft, we gebruikten cPanel-sitesoftware om WHMCS te installeren), hebben sommige tabellen die door het installatieprogramma zijn gemaakt geen primaire sleutel gedefinieerd, zoals weergegeven in de volgende uitvoer:

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                 |
+-----------------+------------------------------------+

Even terzijde:Galera zou nog steeds tabellen zonder primaire sleutel toestaan. DELETE-bewerkingen worden echter niet ondersteund in die tabellen, en het zou u blootstellen aan veel grotere problemen, zoals knooppuntcrashes, verslechtering van de schrijfsetcertificering of rijen kunnen in een andere volgorde op verschillende knooppunten verschijnen.

Om dit te verhelpen, moet ons migratieplan de extra stap bevatten om de opslagengine en de schemastructuur te repareren, zoals weergegeven in de volgende sectie.

Migratieplan

Vanwege beperkingen die in het vorige hoofdstuk zijn uitgelegd, moet ons migratieplan er ongeveer zo uit zien:

1. WHMCS-onderhoudsmodus inschakelen
2. Maak back-ups van de whmcs-database met behulp van logische back-up
3. Wijzig de dumpbestanden om te voldoen aan de Galera-vereiste (converteer opslagengine)
4. Breng een van de Galera-knooppunten naar voren en laat de overige knooppunten afsluiten
5. Herstellen naar het gekozen Galera-knooppunt
6. Repareer de schemastructuur om te voldoen aan de Galera-vereiste (ontbrekende primaire sleutels)
7. Bootstrap het cluster van het gekozen Galera-knooppunt
8. Start het tweede knooppunt en laat het synchroniseren
9. Start het derde knooppunt en laat het synchroniseren
10. Verander de database die naar het juiste eindpunt verwijst
11. WHMCS-onderhoudsmodus uitschakelen

De nieuwe architectuur kan als volgt worden geïllustreerd:

Onze WHMCS-databasenaam op de cPanel-server is "whmcsdata_whmcs" en we gaan deze database migreren naar een externe MariaDB Galera-cluster met drie knooppunten die wordt geïmplementeerd door ClusterControl. Bovenop de databaseserver hebben we een ProxySQL (co-locate met ClusterControl) die fungeert als de MariaDB-load balancer en het enige eindpunt levert aan onze WHMCS-instantie. De databasenaam op het cluster wordt in plaats daarvan gewijzigd in "portal_whmcs", zodat we deze gemakkelijk kunnen onderscheiden.

Schakel eerst de onderhoudsmodus voor de hele site in door naar WHMCS> Instellingen> Algemene instellingen> Algemeen> Onderhoudsmodus> Vink om in te schakelen - voorkomt toegang tot clientgebied wanneer ingeschakeld . Dit zorgt ervoor dat er geen activiteit is van de eindgebruiker tijdens het back-uppen van de database.

Aangezien we kleine wijzigingen moeten aanbrengen in de schemastructuur om goed in Galera te passen, is het een goed idee om twee afzonderlijke dumpbestanden te maken. Een met alleen het schema en een andere alleen voor gegevens. Voer op de WHM-server het volgende commando uit als root:

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

Vervolgens moeten we alle MyISAM-exemplaren in het schemadumpbestand vervangen door 'InnoDB':

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

Controleer of we geen MyISAM-regels meer hebben in het dumpbestand (het zou niets moeten retourneren):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Breng de dumpbestanden over van de WHM-server naar mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Maak de MySQL-database. Ga vanuit ClusterControl naar Beheren -> Schema's en gebruikers -> Database maken en geef de databasenaam op. Hier gebruiken we een andere databasenaam genaamd "portal_whmcs". Anders kunt u de database handmatig maken met het volgende commando:

$ mysql -uroot -p 

MariaDB> CREATE DATABASE 'portal_whmcs';

Maak een MySQL-gebruiker voor deze database met de bijbehorende privileges. Ga vanuit ClusterControl naar Beheren -> Schema's en gebruikers -> Gebruikers -> Nieuwe gebruiker maken en specificeer het volgende:

Als u ervoor kiest om de MySQL-gebruiker handmatig aan te maken, voert u de volgende instructies uit:

$ mysql -uroot -p 

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

Houd er rekening mee dat de aangemaakte databasegebruiker moet worden geïmporteerd in ProxySQL, zodat de WHMCS-toepassing zich kan verifiëren tegen de load balancer. Ga naar Knooppunten -> kies het ProxySQL-knooppunt -> Gebruikers -> Gebruikers importeren en selecteer "portal_whmcs"@"%", zoals weergegeven in de volgende schermafbeelding:

Geef in het volgende venster (Gebruikersinstellingen) Hostgroep 10 op als de standaard hostgroep:

Nu is de voorbereidingsfase van de restauratie voltooid.

In Galera is het herstellen van een grote database via mysqldump op een cluster met één knooppunt efficiënter, en dit verbetert de hersteltijd aanzienlijk. Anders zou elk knooppunt in het cluster elke verklaring van de mysqldump-invoer moeten certificeren, wat meer tijd zou vergen om te voltooien.

Aangezien we al een MariaDB Galera-cluster met drie knooppunten hebben, laten we de MySQL-service op mariadb2 en mariadb3 stoppen, één knooppunt tegelijk voor een sierlijke schaalvermindering. Om de databaseknooppunten af ​​te sluiten, gaat u vanuit ClusterControl naar Knooppunten -> Knooppuntacties -> Knooppunt stoppen -> Doorgaan . Dit is wat u zou zien op het ClusterControl-dashboard, waar de clustergrootte 1 is en de status van de db1 is gesynchroniseerd en primair:

Herstel vervolgens op mariadb1 (192.168.55.51), het schema en de gegevens dienovereenkomstig:

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

Eenmaal geïmporteerd, moeten we de tabelstructuur repareren om de noodzakelijke "id"-kolom toe te voegen (behalve voor tabel "tblaffiliates") en de primaire sleutel toe te voegen aan alle tabellen die er een missen:

$ 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;

Of we kunnen de bovenstaande herhaalde uitspraken vertalen met een lus in een bash-script:

#!/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

Op dit moment is het veilig om de resterende knooppunten te starten om te synchroniseren met mariadb1. Begin met mariadb2 door naar Nodes -> pick db2 -> Node Actions -> Start Node te gaan . Houd de voortgang van de taak in de gaten en zorg ervoor dat mariadb2 de status Gesynchroniseerd en Primair heeft (bekijk de overzichtspagina voor details) voordat u mariadb3 opstart.

Wijzig ten slotte de database die verwijst naar de ProxySQL-host op poort 6033 in het WHMCS-configuratiebestand, zoals in ons geval op /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';

Vergeet niet de WHMCS-onderhoudsmodus uit te schakelen door naar WHMCS> Instellingen> Algemene instellingen> Algemeen> Onderhoudsmodus> het vinkje bij "Vink om in te schakelen - voorkomt toegang tot clientgebied indien ingeschakeld" uit te schakelen . Onze databasemigratie is nu voltooid.

Testen en afstemmen

U kunt controleren of door te kijken naar de query-items van de ProxySQL onder Nodes -> ProxySQL -> Top Queries :

Voor de meest herhaalde alleen-lezen-query's (u kunt ze sorteren op Count Star), kunt u ze in de cache plaatsen om de responstijd te verbeteren en het aantal hits naar de backend-servers te verminderen. Ga gewoon naar een willekeurige query en klik op Cache Query, en de volgende pop-up zal verschijnen:

Wat u hoeft te doen is alleen de bestemmingshostgroep te kiezen en op "Regel toevoegen" te klikken. U kunt dan controleren of de zoekopdracht in de cache is geraakt op het tabblad "Regels":

Uit de queryregel zelf kunnen we afleiden dat reads (allemaal SELECT behalve SELECT .. FOR UPDATE) worden doorgestuurd naar hostgroep 20 waar de verbindingen worden gedistribueerd naar alle knooppunten, terwijl schrijfbewerkingen (anders dan SELECT) worden doorgestuurd naar hostgroep 10, waar de verbindingen worden doorgestuurd naar slechts één Galera-knooppunt. Deze configuratie minimaliseert het risico op deadlocks die kunnen worden veroorzaakt door een multi-master setup, wat de replicatieprestaties als geheel verbetert.

Dat is het voor nu. Veel plezier met clusteren!