Hur man migrerar WHMCS-databas till MariaDB Galera Cluster

WHMCS är en allt-i-ett lösning för klienthantering, fakturering och support för webbhotellföretag. Det är en av de ledande inom värdautomatiseringsvärlden som ska användas tillsammans med själva värdkontrollpanelen. WHMCS körs på en LAMP-stack, med MySQL/MariaDB som databasleverantör. Vanligtvis installeras WHMCS som en fristående instans (applikation och databas) oberoende genom att följa WHMCS installationsguide eller genom programvaruinstallationsverktyg som cPanel Site Software eller Softaculous. Databasen kan göras mycket tillgänglig genom att migrera till ett Galera-kluster med 3 noder.

I det här blogginlägget kommer vi att visa dig hur du migrerar WHMCS-databasen från en fristående MySQL-server (som tillhandahålls av WHM/cPanel-servern själv) till ett externt MariaDB Galera-kluster med tre noder för att förbättra databasens tillgänglighet. Själva WHMCS-applikationen kommer att fortsätta köras på samma cPanel-server. Vi kommer också att ge dig några finjusteringstips för att optimera prestandan.

Distribuera databasklustret

1. Installera ClusterControl:

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

   Följ instruktionerna tills installationen är klar. Gå sedan till http://192.168.55.50/clustercontrol (192.168.55.50 är IP-adressen för ClusterControl-värden) och registrera en superadminanvändare med lösenord och andra nödvändiga detaljer.
2. Ställ in lösenordslös SSH från ClusterControl till alla databasnoder:

   $ 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. Konfigurera databasdistributionen för vårt 3-nods MariaDB Galera Cluster. Vi kommer att använda den senaste versionen MariaDB 10.3 som stöds: Se till att du får alla gröna bockar efter att ha tryckt på 'Enter' när du lägger till noddetaljerna. Vänta tills distributionsjobbet är klart och du bör se att databasklustret är listat i ClusterControl.
4. Distribuera en ProxySQL-nod (vi kommer att samlokalisera den med ClusterControl-noden) genom att gå till Hantera -> Load Balancer -> ProxySQL -> Deploy ProxySQL . Ange följande nödvändiga uppgifter: Under "Lägg till databasanvändare" kan du be ClusterControl att skapa en ny ProxySQL- och MySQL-användare när den ställs in , därför sätter vi användaren som "portal_whmcs", tilldelad med ALLA PRIVILEGIER på databasen "portal_whmcs.*". Markera sedan alla rutorna för "Inkludera" och välj slutligen "falskt" för "Använder du implicita transaktioner?".

När distributionen är klar bör du se något i stil med detta under Topologivy:

Vår databasinstallation är nu klar. Tänk på att vi inte täcker redundansen för lastbalanseringsnivån i det här blogginlägget. Du kan uppnå det genom att lägga till en sekundär lastbalanserare och sätta ihop dem med Keepalved. För att lära dig mer om detta, kolla in ProxySQL Tutorials under kapitel "4.2. Hög tillgänglighet för ProxySQL".

WHMCS-installation

Om du redan har WHMCS installerat och kört kan du hoppa över det här steget.

Observera att WHMCS kräver en giltig licens som du måste köpa i förväg för att kunna använda programvaran. De tillhandahåller ingen gratis testlicens, men de erbjuder en 30-dagars pengarna-tillbaka-garanti utan frågor, vilket innebär att du alltid kan avbryta prenumerationen innan erbjudandet löper ut utan att debiteras.

För att förenkla installationsprocessen kommer vi att använda cPanel Site Software (du kan välja WHMCS manuell installation) till en av våra underdomäner, selfportal.mytest.io. När du har skapat kontot i WHM, gå till cPanel> Programvara> Webbplatsprogramvara> WHMCS och installera webbapplikationen. Logga in som administratörsanvändare och aktivera licensen för att börja använda programmet.

Vid det här laget körs vår WHMCS-instans som en fristående installation och ansluter till den lokala MySQL-servern.

Migrera WHMCS-databasen till MariaDB Galera Cluster

Att köra WHMCS på en fristående MySQL-server utsätter applikationen för single-point-of-failure (SPOF) från databassynpunkt. MariaDB Galera Cluster ger redundans till datalagret med inbyggda klustringsfunktioner och stöd för multimasterarkitektur. Kombinera detta med en databaslastbalanserare, till exempel ProxySQL, så kan vi förbättra WHMCS-databasens tillgänglighet med mycket minimala ändringar av själva applikationen.

Det finns dock ett antal bästa praxis som WHMCS (eller andra applikationer) måste följa för att arbeta effektivt på Galera Cluster, särskilt:

• Alla tabeller måste köras på InnoDB/XtraDB-lagringsmotorn.
• Alla tabeller bör ha en primärnyckel definierad (primärnyckel med flera kolumner stöds, unik nyckel räknas inte).

Beroende på vilken version som är installerad, i vår testmiljöinstallation (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 via Site Software), uppfyllde inte ovanstående två punkter kravet. Standardkonfigurationen för cPanel/WHM MySQL kommer med följande rad inuti /etc/my.cnf:

default-storage-engine=MyISAM

Ovanstående skulle göra att ytterligare tabeller som hanteras av WHMCS Addon-moduler skapas i MyISAM-lagringsmotorformat om dessa moduler är aktiverade. Här är utdata från lagringsmotorn efter att vi har aktiverat 2 moduler (nya toppdomäner och personalanslagstavla):

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-stödet är experimentellt i Galera, vilket betyder att du inte ska köra det i produktion. I vissa värre fall kan det äventyra datakonsistensen och orsaka skrivuppsättningsreplikeringsfel på grund av dess icke-transaktionella karaktär.

En annan viktig punkt är att varje tabell måste ha en primärnyckel definierad. Beroende på WHMCS-installationsproceduren som du utförde (som för oss använde vi cPanel Site Software för att installera WHMCS), kommer vissa av tabellerna som skapats av installationsprogrammet inte med primärnyckeln definierad, som visas i följande utdata:

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 sidoanteckning skulle Galera fortfarande tillåta tabeller utan primärnyckel att existera. DELETE-operationer stöds dock inte i dessa tabeller och det skulle utsätta dig för mycket större problem som nodkrasch, försämring av prestanda för skrivuppsättningscertifiering eller rader kan visas i en annan ordning på olika noder.

För att övervinna detta måste vår migreringsplan inkludera det ytterligare steget att fixa lagringsmotorn och schemastrukturen, som visas i nästa avsnitt.

Migreringsplan

På grund av begränsningar som förklaras i föregående kapitel måste vår migreringsplan vara ungefär så här:

1. Aktivera WHMCS-underhållsläge
2. Ta säkerhetskopior av whmcs-databasen med logisk säkerhetskopia
3. Ändra dumpfilerna för att uppfylla Galera-kraven (konvertera lagringsmotor)
4. Ta fram en av Galera-noderna och låt de återstående noderna stängas av
5. Återställ till den valda Galera-noden
6. Åtgärda schemastrukturen för att uppfylla Galera-kraven (saknade primärnycklar)
7. Bootstrap klustret från den valda Galera-noden
8. Starta den andra noden och låt den synkroniseras
9. Starta den tredje noden och låt den synkroniseras
10. Ändra databasen som pekar till lämplig slutpunkt
11. Inaktivera WHMCS-underhållsläge

Den nya arkitekturen kan illustreras enligt nedan:

Vårt WHMCS-databasnamn på cPanel-servern är "whmcsdata_whmcs" och vi kommer att migrera denna databas till ett externt MariaDB Galera Cluster med tre noder som distribueras av ClusterControl. Ovanpå databasservern har vi en ProxySQL (samlokalisera med ClusterControl) som körs för att fungera som MariaDB-lastbalanseraren och tillhandahåller den enda slutpunkten till vår WHMCS-instans. Databasnamnet på klustret kommer att ändras till "portal_whmcs" istället, så att vi enkelt kan skilja det åt.

Aktivera först det hela webbplatsens underhållsläge genom att gå till WHMCS> Inställningar> Allmänna inställningar> Allmänt> Underhållsläge> Markera för att aktivera - förhindrar åtkomst till klientområdet när det är aktiverat . Detta säkerställer att det inte blir någon aktivitet från slutanvändaren under säkerhetskopieringen av databasen.

Eftersom vi måste göra små modifieringar av schemastrukturen för att passa väl in i Galera, är det en bra idé att skapa två separata dumpfiler. En med endast schemat och en annan endast för data. På WHM-servern, kör följande kommando som root:

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

Sedan måste vi ersätta alla MyISAM-förekomster i schemadumpfilen med 'InnoDB':

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

Kontrollera att vi inte längre har MyISAM-rader i dumpfilen (den ska inte returnera något):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Överför dumpfilerna från WHM-servern till mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Skapa MySQL-databasen. Från ClusterControl, gå till Hantera -> Schema och användare -> Skapa databas och ange databasnamnet. Här använder vi ett annat databasnamn som heter "portal_whmcs". Annars kan du skapa databasen manuellt med följande kommando:

$ mysql -uroot -p 

MariaDB> CREATE DATABASE 'portal_whmcs';

Skapa en MySQL-användare för denna databas med dess privilegier. Från ClusterControl, gå till Hantera -> Schema och användare -> Användare -> Skapa ny användare och ange följande:

Om du väljer att skapa MySQL-användaren manuellt, kör följande satser:

$ mysql -uroot -p 

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

Notera att den skapade databasanvändaren måste importeras till ProxySQL för att WHMCS-applikationen ska kunna autentisera mot lastbalanseraren. Gå till Noder -> välj ProxySQL-noden -> Användare -> Importera användare och välj "portal_whmcs"@"%", som visas i följande skärmdump:

I nästa fönster (Användarinställningar), ange Hostgroup 10 som standardvärdgrupp:

Nu är förberedelsestadiet för restaurering klar.

I Galera är det mer effektivt att återställa en stor databas via mysqldump på ett kluster med en nod, och detta förbättrar återställningstiden avsevärt. Annars skulle varje nod i klustret behöva certifiera varje påstående från mysqldump-inmatningen, vilket skulle ta längre tid att slutföra.

Eftersom vi redan har ett MariaDB Galera Cluster med tre noder igång, låt oss stoppa MySQL-tjänsten på mariadb2 och mariadb3, en nod i taget för en graciös nedskalning. För att stänga av databasnoderna, från ClusterControl, gå helt enkelt till Noder -> Nodåtgärder -> Stoppa nod -> Fortsätt . Det här är vad du skulle se från ClusterControl-instrumentpanelen, där klusterstorleken är 1 och statusen för db1 är Synkroniserad och Primär:

Återställ sedan schemat och data 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 väl har importerats måste vi fixa tabellstrukturen för att lägga till den nödvändiga "id"-kolumnen (förutom tabellen "tblaffiliates") samt lägga till primärnyckeln på alla tabeller som har saknat någon:

$ 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 så kan vi översätta ovanstående upprepade uttalanden med en loop i ett bash-skript:

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

Vid det här laget är det säkert att starta de återstående noderna för att synkronisera med mariadb1. Börja med mariadb2 genom att gå till Noder -> välj db2 -> Nodåtgärder -> Startnod . Övervaka jobbets framsteg och se till att mariadb2 är i synkroniserat och primärt läge (övervaka översiktssidan för detaljer) innan du startar mariadb3.

Ändra slutligen databasen som pekar mot ProxySQL-värden på port 6033 i WHMCS-konfigurationsfilen, eftersom den i vårt fall finns 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';

Glöm inte att inaktivera WHMCS-underhållsläget genom att gå till WHMCS> Inställningar> Allmänna inställningar> Allmänt> Underhållsläge> avmarkera "Bocka för att aktivera - förhindrar åtkomst till klientområdet när det är aktiverat" . Vår databasmigreringsövning är nu klar.

Testa och trimma

Du kan kontrollera om genom att titta på ProxySQL:s frågeposter under Noder -> ProxySQL -> Top Queries :

För de mest upprepade skrivskyddade frågorna (du kan sortera dem efter Count Star), kan du cachelagra dem för att förbättra svarstiden och minska antalet träffar på backend-servrarna. Bläddra helt enkelt över till valfri fråga och klicka på Cache-fråga, så visas följande popup-fönster:

Vad du behöver göra är att bara välja destinationsvärdgruppen och klicka på "Lägg till regel". Du kan sedan verifiera om den cachade frågan träffades under fliken "Regler":

Från själva frågeregeln kan vi se att läsningar (alla SELECT utom SELECT .. FÖR UPPDATERING) vidarebefordras till värdgrupp 20 där anslutningarna distribueras till alla noder medan skrivningar (andra än SELECT) vidarebefordras till värdgrupp 10, där anslutningarna vidarebefordras endast till en Galera-nod. Den här konfigurationen minimerar risken för dödlägen som kan orsakas av en multimasterinstallation, vilket förbättrar replikeringsprestandan som helhet.

Det var allt för nu. Lycka till med klustringen!