Sådan migreres WHMCS-databasen til MariaDB Galera Cluster

WHMCS er en alt-i-en løsning til klientadministration, fakturering og support til webhostingfirmaer. Det er en af ​​de førende inden for hostingautomatiseringsverdenen, der skal bruges sammen med selve hostingkontrolpanelet. WHMCS kører på en LAMP-stack med MySQL/MariaDB som databaseudbyder. Almindeligvis installeres WHMCS som en selvstændig instans (applikation og database) uafhængigt ved at følge WHMCS installationsvejledningen eller gennem softwareinstallationsværktøjer som cPanel Site Software eller Softaculous. Databasen kan gøres meget tilgængelig ved at migrere til en Galera Cluster med 3 noder.

I dette blogindlæg vil vi vise dig, hvordan du migrerer WHMCS-databasen fra en selvstændig MySQL-server (leveret af WHM/cPanel-serveren selv) til en ekstern tre-node MariaDB Galera Cluster for at forbedre databasens tilgængelighed. Selve WHMCS-applikationen vil blive ved med at køre på den samme cPanel-server. Vi vil også give dig nogle tuning tips til at optimere ydeevnen.

Implementering af databaseklyngen

1. Installer ClusterControl:

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

   Følg instruktionerne i overensstemmelse hermed, indtil installationen er fuldført. Gå derefter til http://192.168.55.50/clustercontrol (192.168.55.50 er IP-adressen på ClusterControl-værten) og registrer en superadmin-bruger med adgangskode og andre nødvendige detaljer.
2. Opsæt adgangskodefri SSH fra ClusterControl til alle databasenoder:

   $ 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. Konfigurer databaseimplementeringen for vores 3-node MariaDB Galera Cluster. Vi vil bruge den seneste understøttede version MariaDB 10.3: Sørg for, at du får alle grønne markeringer efter at have trykket på 'Enter', når du tilføjer nodedetaljerne. Vent, indtil installationsjobbet er fuldført, og du bør se, at databaseklyngen er opført i ClusterControl.
4. Implementer en ProxySQL-node (vi vil samlokalisere den med ClusterControl-noden) ved at gå til Administrer -> Load Balancer -> ProxySQL -> Implementer ProxySQL . Angiv følgende nødvendige detaljer: Under "Tilføj databasebruger" kan du bede ClusterControl om at oprette en ny ProxySQL- og MySQL-bruger, efterhånden som den konfigureres , således sætter vi brugeren som "portal_whmcs", tildelt med ALLE PRIVILEGIER på databasen "portal_whmcs.*". Marker derefter alle felterne for "Inkluder" og vælg til sidst "falsk" for "Bruger du implicitte transaktioner?".

Når installationen er færdig, bør du se noget som dette under Topologivisning:

Vores databaseimplementering er nu færdig. Husk på, at vi ikke dækker redundansen i load balancer-niveauet i dette blogindlæg. Du kan opnå det ved at tilføje en sekundær load balancer og sætte dem sammen med Keepalved. For at lære mere om dette, tjek ProxySQL Tutorials under kapitel "4.2. Høj tilgængelighed for ProxySQL".

WHMCS-installation

Hvis du allerede har WHMCS installeret og kører, kan du springe dette trin over.

Vær opmærksom på, at WHMCS kræver en gyldig licens, som du skal købe på forhånd for at bruge softwaren. De giver ikke en gratis prøvelicens, men de tilbyder en 30-dages pengene-tilbage-garanti uden spørgsmål, hvilket betyder, at du altid kan annullere abonnementet, før tilbuddet udløber, uden at blive opkrævet.

For at forenkle installationsprocessen vil vi bruge cPanel Site Software (du kan vælge WHMCS manuel installation) til et af vores underdomæner, selfportal.mytest.io. Når du har oprettet kontoen i WHM, skal du gå til cPanel> Software> Site Software> WHMCS og installer webapplikationen. Log på som admin-bruger og aktiver licensen for at begynde at bruge applikationen.

På dette tidspunkt kører vores WHMCS-instans som en selvstændig opsætning, der forbinder til den lokale MySQL-server.

Migrering af WHMCS-databasen til MariaDB Galera Cluster

Kørsel af WHMCS på en selvstændig MySQL-server udsætter applikationen for single-point-of-failure (SPOF) fra databasesynspunkt. MariaDB Galera Cluster giver redundans til datalaget med indbyggede klyngefunktioner og understøttelse af multi-master-arkitektur. Kombiner dette med en database-load balancer, for eksempel ProxySQL, og vi kan forbedre WHMCS-databasens tilgængelighed med meget minimale ændringer af selve applikationen.

Der er dog en række bedste praksis, som WHMCS (eller andre applikationer) skal følge for at arbejde effektivt på Galera Cluster, især:

• Alle tabeller skal køre på InnoDB/XtraDB storage engine.
• Alle tabeller skal have en primærnøgle defineret (primærnøgle med flere kolonner er understøttet, unik nøgle tæller ikke).

Afhængigt af den installerede version, i vores testmiljøinstallation (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 via Site Software), opfyldte de to ovenstående punkter ikke kravet. Standard cPanel/WHM MySQL-konfigurationen kommer med følgende linje inde i /etc/my.cnf:

default-storage-engine=MyISAM

Ovenstående vil medføre, at yderligere tabeller, der administreres af WHMCS Addon-moduler, bliver oprettet i MyISAM-lagringsmotorformat, hvis disse moduler er aktiveret. Her er output fra lagermotoren, efter at vi har aktiveret 2 moduler (nye TLD'er og personaleopslagstavle):

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-understøttelse er eksperimentel i Galera, hvilket betyder, at du ikke bør køre den i produktion. I nogle værre tilfælde kan det kompromittere datakonsistensen og forårsage skrivesætreplikeringsfejl på grund af dets ikke-transaktionelle karakter.

Et andet vigtigt punkt er, at hver tabel skal have en primær nøgle defineret. Afhængigt af den WHMCS-installationsprocedure, du udførte (som for os, brugte vi cPanel Site Software til at installere WHMCS), kommer nogle af tabellerne oprettet af installationsprogrammet ikke med primærnøgle defineret, som vist i følgende output:

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

Som en sidebemærkning ville Galera stadig tillade tabeller uden primærnøgle at eksistere. DELETE-handlinger understøttes dog ikke på disse tabeller, plus det ville udsætte dig for meget større problemer som knudenedbrud, forringelse af skrivesæt-certificeringens ydeevne eller rækker kan vises i en anden rækkefølge på forskellige noder.

For at overvinde dette skal vores migreringsplan indeholde det ekstra trin til at rette op på lagermotoren og skemastrukturen, som vist i næste afsnit.

Migrationsplan

På grund af begrænsninger forklaret i det foregående kapitel, skal vores migreringsplan være sådan her:

1. Aktiver WHMCS-vedligeholdelsestilstand
2. Tag sikkerhedskopier af whmcs-databasen ved hjælp af logisk backup
3. Rediger dumpfilerne, så de opfylder Galera-kravet (konverter lagringsmotor)
4. Få en af ​​Galera-knuderne frem, og lad de resterende knudepunkter lukke ned
5. Gendan til den valgte Galera-knude
6. Ret skemastrukturen for at opfylde Galera-kravet (manglende primære nøgler)
7. Bootstrap klyngen fra den valgte Galera-knude
8. Start den anden node, og lad den synkronisere
9. Start den tredje node, og lad den synkronisere
10. Skift databasen, der peger på det relevante slutpunkt
11. Deaktiver WHMCS-vedligeholdelsestilstand

Den nye arkitektur kan illustreres som nedenfor:

Vores WHMCS-databasenavn på cPanel-serveren er "whmcsdata_whmcs", og vi vil migrere denne database til en ekstern tre-node MariaDB Galera Cluster implementeret af ClusterControl. Oven på databaseserveren har vi en ProxySQL (co-locate with ClusterControl), der kører for at fungere som MariaDB load balancer, der leverer det enkelte endepunkt til vores WHMCS-instans. Databasenavnet på klyngen vil i stedet blive ændret til "portal_whmcs", så vi nemt kan skelne det.

Aktiver først den hele webstedsvedligeholdelsestilstand ved at gå til WHMCS> Opsætning> Generelle indstillinger> Generelt> Vedligeholdelsestilstand> Marker for at aktivere - forhindrer adgang til klientområdet, når den er aktiveret . Dette vil sikre, at der ikke vil være nogen aktivitet fra slutbrugeren under sikkerhedskopieringen af ​​databasen.

Da vi er nødt til at lave små ændringer i skemastrukturen for at passe godt ind i Galera, er det en god idé at oprette to separate dumpfiler. En med kun skemaet og en anden kun for data. På WHM-serveren skal du køre følgende kommando som root:

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

Derefter skal vi erstatte alle MyISAM-forekomster i skemadumpfilen med 'InnoDB':

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

Bekræft, at vi ikke længere har MyISAM-linjer i dump-filen (den burde ikke returnere noget):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Overfør dumpfilerne fra WHM-serveren til mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Opret MySQL-databasen. Fra ClusterControl skal du gå til Administrer -> Skemaer og brugere -> Opret database og angiv databasenavnet. Her bruger vi et andet databasenavn kaldet "portal_whmcs". Ellers kan du manuelt oprette databasen med følgende kommando:

$ mysql -uroot -p 

MariaDB> CREATE DATABASE 'portal_whmcs';

Opret en MySQL-bruger til denne database med dens privilegier. Fra ClusterControl skal du gå til Administrer -> Skemaer og brugere -> Brugere -> Opret ny bruger og angiv følgende:

Hvis du vælger at oprette MySQL-brugeren manuelt, skal du køre følgende sætninger:

$ mysql -uroot -p 

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

Bemærk, at den oprettede databasebruger skal importeres til ProxySQL for at tillade WHMCS-applikationen at godkende mod belastningsbalanceren. Gå til Noder -> vælg ProxySQL-noden -> Brugere -> Importer brugere og vælg "portal_whmcs"@"%", som vist på følgende skærmbillede:

I det næste vindue (Brugerindstillinger) skal du angive værtsgruppe 10 som standard værtsgruppe:

Nu er forberedelsesfasen for restaurering afsluttet.

I Galera er gendannelse af en stor database via mysqldump på en enkelt-node klynge mere effektiv, og dette forbedrer gendannelsestiden betydeligt. Ellers ville hver node i klyngen skulle certificere hver erklæring fra mysqldump-inputtet, hvilket ville tage længere tid at fuldføre.

Da vi allerede har en tre-node MariaDB Galera Cluster kørende, lad os stoppe MySQL-tjenesten på mariadb2 og mariadb3, en node ad gangen for en yndefuld nedskalering. For at lukke databasenoderne fra ClusterControl skal du blot gå til Noder -> Node Actions -> Stop Node -> Fortsæt . Her er, hvad du vil se fra ClusterControl-dashboardet, hvor klyngestørrelsen er 1, og status for db1 er Synkroniseret og Primær:

Gendan derefter skemaet og dataene på mariadb1 (192.168.55.51):

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

Når den først er importeret, skal vi rette tabelstrukturen for at tilføje den nødvendige "id"-kolonne (undtagen tabel "tblaffiliates") samt tilføje primærnøglen på alle tabeller, der har manglet nogen:

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

Eller vi kan oversætte ovenstående gentagne udsagn ved hjælp af en loop i et 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

På dette tidspunkt er det sikkert at starte de resterende noder for at synkronisere med mariadb1. Start med mariadb2 ved at gå til Noder -> vælg db2 -> Nodehandlinger -> Start node . Overvåg jobbets fremskridt, og sørg for, at mariadb2 er i synkroniseret og primær tilstand (overvåg oversigtssiden for detaljer), før du starter mariadb3.

Til sidst skal du ændre databasen, der peger på ProxySQL-værten på port 6033 inde i WHMCS-konfigurationsfilen, da den i vores tilfælde er placeret på /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';

Glem ikke at deaktivere WHMCS-vedligeholdelsestilstanden ved at gå til WHMCS> Opsætning> Generelle indstillinger> Generelt> Vedligeholdelsestilstand> fjern markeringen af ​​"Marker for at aktivere - forhindrer adgang til klientområdet, når den er aktiveret" . Vores databasemigreringsøvelse er nu afsluttet.

Test og tuning

Du kan kontrollere, om det er ved at se på ProxySQL's forespørgselsposter under Noder -> ProxySQL -> Topforespørgsler :

For de mest gentagne skrivebeskyttede forespørgsler (du kan sortere dem efter Count Star), kan du cache dem for at forbedre responstiden og reducere antallet af hits til backend-serverne. Du skal blot rulle over til en hvilken som helst forespørgsel og klikke på Cache-forespørgsel, og følgende pop op-vindue vises:

Det du skal gøre er kun at vælge destinationsværtsgruppen og klikke på "Tilføj regel". Du kan derefter kontrollere, om den cachelagrede forespørgsel blev ramt under fanen "Regler":

Fra selve forespørgselsreglen kan vi se, at læsninger (alle SELECT undtagen SELECT .. FOR UPDATE) videresendes til værtsgruppe 20, hvor forbindelserne distribueres til alle noder, mens skrivninger (bortset fra SELECT) videresendes til værtsgruppe 10, hvor forbindelserne videresendes kun til én Galera-node. Denne konfiguration minimerer risikoen for deadlocks, der kan være forårsaget af en multi-master opsætning, hvilket forbedrer replikeringsydelsen som helhed.

Det var det for nu. Glædelig klyngedannelse!