MariaDB
 sql >> Database >  >> RDS >> MariaDB

Come migrare il database WHMCS nel cluster MariaDB Galera

WHMCS è una soluzione all-in-one per la gestione dei clienti, la fatturazione e il supporto per le società di web hosting. È uno dei leader nel mondo dell'automazione dell'hosting da utilizzare insieme al pannello di controllo dell'hosting stesso. WHMCS viene eseguito su uno stack LAMP, con MySQL/MariaDB come provider di database. Comunemente, WHMCS viene installato come istanza standalone (applicazione e database) in modo indipendente seguendo la guida all'installazione di WHMCS o tramite strumenti di installazione software come cPanel Site Software o Softaculous. Il database può essere reso altamente disponibile migrando su un Cluster Galera di 3 nodi.

In questo post del blog, ti mostreremo come migrare il database WHMCS da un server MySQL autonomo (fornito dal server WHM/cPanel stesso) a un cluster MariaDB Galera esterno a tre nodi per migliorare la disponibilità del database. L'applicazione WHMCS stessa verrà mantenuta in esecuzione sullo stesso server cPanel. Ti forniremo anche alcuni suggerimenti per l'ottimizzazione per ottimizzare le prestazioni.

Distribuzione del cluster di database

  1. Installa ClusterControl:
    $ whoami
root
$ wget https://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc
    Seguire le istruzioni di conseguenza fino al completamento dell'installazione. Quindi, vai su http://192.168.55.50/clustercontrol (192.168.55.50 è l'indirizzo IP dell'host ClusterControl) e registra un utente super amministratore con password e altri dettagli richiesti.
  2. Imposta SSH senza password da ClusterControl a tutti i nodi del database:
    $ 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. Configura la distribuzione del database per il nostro cluster MariaDB Galera a 3 nodi. Utilizzeremo l'ultima versione supportata MariaDB 10.3: Assicurati di avere tutti i segni di spunta verdi dopo aver premuto "Invio" quando aggiungi i dettagli del nodo. Attendi fino al completamento del processo di distribuzione e dovresti vedere che il cluster di database è elencato in ClusterControl.
  4. Distribuire un nodo ProxySQL (lo collocheremo insieme al nodo ClusterControl) andando su Gestisci -> Load Balancer -> ProxySQL -> Distribuisci ProxySQL . Specificare i seguenti dettagli obbligatori: In "Aggiungi utente database", puoi chiedere a ClusterControl di creare un nuovo utente ProxySQL e MySQL durante la configurazione , quindi mettiamo l'utente come "portal_whmcs", assegnato con TUTTI I PRIVILEGI sul database "portal_whmcs.*". Quindi, seleziona tutte le caselle per "Includi" e infine scegli "falso" per "Stai utilizzando transazioni implicite?".

Una volta terminata la distribuzione, dovresti vedere qualcosa di simile in Visualizzazione topologia:

Risorse correlate Il principale provider di hosting australiano sfrutta ClusterControl per offrire un'esperienza di prim'ordine ai propri utenti Bilanciamento del carico del database per MySQL e MariaDB con ProxySQL - Tutorial High Availability MySQL su cPanel con Galera Cluster

La nostra distribuzione del database è ora completa. Tieni presente che in questo post del blog non trattiamo la ridondanza del livello del sistema di bilanciamento del carico. Puoi ottenerlo aggiungendo un sistema di bilanciamento del carico secondario e unendoli insieme a Keepalived. Per saperne di più, dai un'occhiata ai tutorial di ProxySQL nel capitolo "4.2. Alta disponibilità per ProxySQL".

Installazione WHMCS

Se hai già installato e funzionante WHMCS, puoi saltare questo passaggio.

Tieni presente che WHMCS richiede una licenza valida che devi acquistare in anticipo per utilizzare il software. Non forniscono una licenza di prova gratuita, ma offrono una garanzia di rimborso di 30 giorni senza fare domande, il che significa che puoi sempre annullare l'abbonamento prima della scadenza dell'offerta senza essere addebitato.

Per semplificare il processo di installazione, utilizzeremo il software del sito cPanel (puoi optare per l'installazione manuale WHMCS) in uno dei nostri sottodomini, selfportal.mytest.io. Dopo aver creato l'account in WHM, vai su cPanel> Software> Site Software> WHMCS e installare l'applicazione web. Accedi come utente amministratore e attiva la licenza per iniziare a utilizzare l'applicazione.

A questo punto, la nostra istanza WHMCS è in esecuzione come configurazione autonoma, connettendosi al server MySQL locale.

ClusterControlSingle Console per l'intera infrastruttura di databaseScopri cos'altro c'è di nuovo in ClusterControlInstalla ClusterControl GRATIS

Migrazione del database WHMCS al cluster MariaDB Galera

L'esecuzione di WHMCS su un server MySQL autonomo espone l'applicazione a un singolo punto di errore (SPOF) dal punto di vista del database. MariaDB Galera Cluster fornisce ridondanza al livello dati con funzionalità di clustering integrate e supporto per l'architettura multi-master. Combina questo con un sistema di bilanciamento del carico del database, ad esempio ProxySQL, e possiamo migliorare la disponibilità del database WHMCS con modifiche minime all'applicazione stessa.

Tuttavia, ci sono una serie di best practice che WHMCS (o altre applicazioni) devono seguire per lavorare in modo efficiente su Galera Cluster, in particolare:

  • Tutte le tabelle devono essere eseguite sul motore di archiviazione InnoDB/XtraDB.
  • Tutte le tabelle devono avere una chiave primaria definita (la chiave primaria a più colonne è supportata, la chiave univoca non conta).

A seconda della versione installata, nell'installazione del nostro ambiente di test (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 tramite Site Software), i due punti precedenti non soddisfacevano il requisito. La configurazione predefinita di cPanel/WHM MySQL viene fornita con la seguente riga all'interno di /etc/my.cnf:

default-storage-engine=MyISAM

Quanto sopra comporterebbe la creazione di tabelle aggiuntive gestite dai moduli aggiuntivi WHMCS nel formato del motore di archiviazione MyISAM se tali moduli sono abilitati. Ecco l'output del motore di archiviazione dopo aver abilitato 2 moduli (Nuovi TLD e Bacheca del personale):

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

Il supporto MyISAM è sperimentale in Galera, il che significa che non dovresti eseguirlo in produzione. In alcuni casi peggiori, potrebbe compromettere la coerenza dei dati e causare errori di replica del writeset a causa della sua natura non transazionale.

Un altro punto importante è che ogni tabella deve avere una chiave primaria definita. A seconda della procedura di installazione di WHMCS che hai eseguito (come per noi, abbiamo utilizzato cPanel Site Software per installare WHMCS), alcune delle tabelle create dall'installatore non vengono fornite con la chiave primaria definita, come mostrato nel seguente 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                 |
+-----------------+------------------------------------+

Come nota a margine, Galera consentirebbe comunque l'esistenza di tabelle senza chiave primaria. Tuttavia, le operazioni DELETE non sono supportate su quelle tabelle, inoltre ti esporrebbero a problemi molto più grandi come l'arresto anomalo del nodo, il degrado delle prestazioni della certificazione del set di scrittura o le righe potrebbero apparire in un ordine diverso su nodi diversi.

Per ovviare a questo problema, il nostro piano di migrazione deve includere il passaggio aggiuntivo per correggere il motore di archiviazione e la struttura dello schema, come mostrato nella sezione successiva.

Piano di migrazione

A causa delle restrizioni spiegate nel capitolo precedente, il nostro piano di migrazione deve essere qualcosa del genere:

  1. Abilita la modalità di manutenzione WHMCS
  2. Esegui backup del database whmcs utilizzando il backup logico
  3. Modifica i file di dump per soddisfare i requisiti Galera (convert storage engine)
  4. Apri uno dei nodi Galera e lascia che i nodi rimanenti si spengano
  5. Ripristina nel nodo Galera scelto
  6. Correggi la struttura dello schema per soddisfare i requisiti di Galera (chiavi primarie mancanti)
  7. Bootstrap del cluster dal nodo Galera scelto
  8. Avvia il secondo nodo e fallo sincronizzare
  9. Avvia il terzo nodo e fallo sincronizzare
  10. Cambia il database che punta all'endpoint appropriato
  11. Disabilita la modalità di manutenzione WHMCS

La nuova architettura può essere illustrata come segue:

Il nome del nostro database WHMCS sul server cPanel è "whmcsdata_whmcs" e migreremo questo database su un cluster MariaDB Galera esterno a tre nodi distribuito da ClusterControl. Sulla parte superiore del server di database, abbiamo un ProxySQL (co-localizzare con ClusterControl) in esecuzione per fungere da bilanciatore del carico MariaDB, fornendo l'endpoint singolo alla nostra istanza WHMCS. Il nome del database sul cluster verrà invece cambiato in "portal_whmcs", in modo da poterlo distinguere facilmente.

Innanzitutto, abilita la modalità di manutenzione a livello di sito andando su WHMCS> Configurazione> Impostazioni generali> Generali> Modalità di manutenzione> Spunta per abilitare - impedisce l'accesso all'area client quando abilitato . Ciò garantirà che non ci sarà alcuna attività da parte dell'utente finale durante l'operazione di backup del database.

Dal momento che dobbiamo apportare lievi modifiche alla struttura dello schema per adattarla bene a Galera, è una buona idea creare due file di dump separati. Uno solo con lo schema e un altro solo per i dati. Sul server WHM, esegui il seguente comando come root:

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

Quindi, dobbiamo sostituire tutte le occorrenze MyISAM nel file di dump dello schema con 'InnoDB':

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

Verifica di non avere più righe MyISAM nel file di dump (non dovrebbe restituire nulla):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Trasferisci i file di dump dal server WHM a mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Crea il database MySQL. Da ClusterControl, vai su Gestisci -> Schemi e utenti -> Crea database e specificare il nome del database. Qui usiamo un nome di database diverso chiamato "portal_whmcs". Altrimenti, puoi creare manualmente il database con il seguente comando:

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

Crea un utente MySQL per questo database con i suoi privilegi. Da ClusterControl, vai su Gestisci -> Schemi e utenti -> Utenti -> Crea nuovo utente e specificare quanto segue:

Se scegli di creare manualmente l'utente MySQL, esegui le seguenti istruzioni:

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

Tieni presente che l'utente del database creato deve essere importato in ProxySQL, per consentire all'applicazione WHMCS di autenticarsi rispetto al servizio di bilanciamento del carico. Vai a Nodi -> seleziona il nodo ProxySQL -> Utenti -> Importa utenti e seleziona "portal_whmcs"@"%", come mostrato nella schermata seguente:

Nella finestra successiva (Impostazioni utente), specifica Hostgroup 10 come hostgroup predefinito:

Ora la fase di preparazione del restauro è completa.

In Galera, il ripristino di un grande database tramite mysqldump su un cluster a nodo singolo è più efficiente e questo migliora notevolmente i tempi di ripristino. In caso contrario, ogni nodo del cluster dovrebbe certificare ogni istruzione dall'input mysqldump, il che richiederebbe più tempo per essere completato.

Dato che abbiamo già un cluster MariaDB Galera a tre nodi in esecuzione, interrompiamo il servizio MySQL su mariadb2 e mariadb3, un nodo alla volta per una scalabilità graduale. Per chiudere i nodi del database, da ClusterControl, vai su Nodi -> Azioni nodo -> Arresta nodo -> Procedi . Ecco cosa vedresti dalla dashboard ClusterControl, dove la dimensione del cluster è 1 e lo stato del db1 è sincronizzato e primario:

Quindi, su mariadb1 (192.168.55.51), ripristina lo schema e i dati di conseguenza:

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

Una volta importata, dobbiamo correggere la struttura della tabella per aggiungere la colonna "id" necessaria (ad eccezione della tabella "tblaffiliates") e aggiungere la chiave primaria su tutte le tabelle che ne sono mancate:

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

Oppure, possiamo tradurre le affermazioni ripetute di cui sopra usando un ciclo in uno 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

A questo punto, è possibile avviare i nodi rimanenti per sincronizzarsi con mariadb1. Inizia con mariadb2 andando su Nodi -> scegli db2 -> Azioni nodo -> Avvia nodo . Monitora l'avanzamento del lavoro e assicurati che mariadb2 sia nello stato Sincronizzato e Primario (controlla la pagina Panoramica per i dettagli) prima di avviare mariadb3.

Infine, cambia il database che punta all'host ProxySQL sulla porta 6033 all'interno del file di configurazione WHMCS, poiché nel nostro caso si trova in /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';

Non dimenticare di disabilitare la modalità di manutenzione WHMCS andando su WHMCS> Configurazione> Impostazioni generali> Generali> Modalità manutenzione> deseleziona "Seleziona per abilitare - impedisce l'accesso all'area client quando abilitato" . Il nostro esercizio di migrazione del database è ora completo.

Test e ottimizzazione

Puoi verificarlo guardando le voci della query di ProxySQL in Nodi -> ProxySQL -> Query principali :

Per le query di sola lettura più ripetute (puoi ordinarle per numero di stelle), puoi memorizzarle nella cache per migliorare il tempo di risposta e ridurre il numero di accessi ai server di backend. Passa semplicemente a qualsiasi query e fai clic su Query cache e verrà visualizzato il seguente popup:

Quello che devi fare è scegliere solo il gruppo host di destinazione e fare clic su "Aggiungi regola". Puoi quindi verificare se la query memorizzata nella cache è stata soddisfatta nella scheda "Regole":

Dalla regola di query stessa, possiamo dire che le letture (tutte SELECT tranne SELECT .. FOR UPDATE) vengono inoltrate al gruppo host 20 dove le connessioni vengono distribuite a tutti i nodi mentre le scritture (diverse da SELECT) vengono inoltrate al gruppo host 10, dove le connessioni vengono inoltrati a un solo nodo Galera. Questa configurazione riduce al minimo il rischio di deadlock che potrebbero essere causati da una configurazione multi-master, migliorando le prestazioni di replica nel loro insieme.

Per ora è tutto. Buon raggruppamento!