MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

So migrieren Sie die WHMCS-Datenbank in den MariaDB Galera-Cluster

WHMCS ist eine All-in-One-Client-Management-, Abrechnungs- und Support-Lösung für Webhosting-Unternehmen. Es ist eines der führenden Unternehmen in der Welt der Hosting-Automatisierung, das neben dem Hosting-Control-Panel selbst verwendet wird. WHMCS läuft auf einem LAMP-Stack mit MySQL/MariaDB als Datenbankanbieter. Üblicherweise wird WHMCS als eigenständige Instanz (Anwendung und Datenbank) unabhängig installiert, indem man der WHMCS-Installationsanleitung folgt oder über Software-Installer-Tools wie cPanel Site Software oder Softaculous. Die Datenbank kann hochverfügbar gemacht werden, indem auf ein Galera-Cluster mit 3 Knoten migriert wird.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie die WHMCS-Datenbank von einem eigenständigen MySQL-Server (vom WHM/cPanel-Server selbst bereitgestellt) auf einen externen MariaDB Galera-Cluster mit drei Knoten migrieren, um die Datenbankverfügbarkeit zu verbessern. Die WHMCS-Anwendung selbst wird auf demselben cPanel-Server ausgeführt. Wir geben Ihnen auch einige Tuning-Tipps, um die Leistung zu optimieren.

Bereitstellen des Datenbank-Clusters

  1. ClusterControl installieren:
    $ whoami
root
$ wget https://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc
    Befolgen Sie die Anweisungen entsprechend, bis die Installation abgeschlossen ist. Gehen Sie dann zu http://192.168.55.50/clustercontrol (192.168.55.50 ist die IP-Adresse des ClusterControl-Hosts) und registrieren Sie einen Super-Admin-Benutzer mit Passwort und anderen erforderlichen Details.
  2. Passwortloses SSH von ClusterControl zu allen Datenbankknoten einrichten:
    $ 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. Konfigurieren Sie die Datenbankbereitstellung für unseren 3-Knoten-MariaDB-Galera-Cluster. Wir werden die neueste unterstützte Version MariaDB 10.3 verwenden: Stellen Sie sicher, dass Sie alle grünen Häkchen erhalten, nachdem Sie beim Hinzufügen der Knotendetails die Eingabetaste gedrückt haben. Warten Sie, bis der Bereitstellungsjob abgeschlossen ist und Sie sehen sollten, dass der Datenbankcluster in ClusterControl aufgelistet ist.
  4. Stellen Sie einen ProxySQL-Knoten bereit (wir werden ihn zusammen mit dem ClusterControl-Knoten platzieren), indem Sie zu Verwalten -> Load Balancer -> ProxySQL -> ProxySQL bereitstellen gehen . Geben Sie die folgenden erforderlichen Details an: Unter "Datenbankbenutzer hinzufügen" können Sie ClusterControl bitten, während der Einrichtung einen neuen ProxySQL- und MySQL-Benutzer zu erstellen , also setzen wir den Benutzer als "portal_whmcs", zugewiesen mit ALLEN PRIVILEGIEN auf die Datenbank "portal_whmcs.*". Aktivieren Sie dann alle Kontrollkästchen für „Einschließen“ und wählen Sie schließlich „falsch“ für „Verwenden Sie implizite Transaktionen?“.

Sobald die Bereitstellung abgeschlossen ist, sollten Sie in der Topologieansicht so etwas sehen:

Verwandte Ressourcen Australiens führender Hosting-Anbieter nutzt ClusterControl, um seinen Benutzern ein erstklassiges Erlebnis zu bieten Datenbanklastenausgleich für MySQL und MariaDB mit ProxySQL – Tutorial Hochverfügbarkeits-MySQL auf cPanel mit Galera-Cluster

Unsere Datenbankbereitstellung ist jetzt abgeschlossen. Beachten Sie, dass wir die Redundanz der Lastausgleichsebene in diesem Blogbeitrag nicht behandeln. Sie können dies erreichen, indem Sie einen sekundären Load Balancer hinzufügen und ihn mit Keepalived aneinanderreihen. Um mehr darüber zu erfahren, lesen Sie die ProxySQL-Tutorials im Kapitel "4.2. Hochverfügbarkeit für ProxySQL".

WHMCS-Installation

Wenn Sie WHMCS bereits installiert haben und ausführen, können Sie diesen Schritt überspringen.

Beachten Sie, dass WHMCS eine gültige Lizenz erfordert, die Sie zuvor erwerben müssen, um die Software verwenden zu können. Sie bieten keine kostenlose Testlizenz, aber sie bieten eine 30-tägige Geld-zurück-Garantie, ohne dass Fragen gestellt werden, was bedeutet, dass Sie das Abonnement jederzeit kündigen können, bevor das Angebot abläuft, ohne dass Ihnen Kosten in Rechnung gestellt werden.

Um den Installationsprozess zu vereinfachen, verwenden wir die cPanel-Site-Software (Sie können sich für die manuelle WHMCS-Installation entscheiden) für eine unserer Subdomains, selfportal.mytest.io. Nachdem Sie das Konto in WHM erstellt haben, gehen Sie zu cPanel> Software> Site Software> WHMCS und installieren Sie die Webanwendung. Melden Sie sich als Administrator an und aktivieren Sie die Lizenz, um die Anwendung zu verwenden.

Zu diesem Zeitpunkt läuft unsere WHMCS-Instanz als eigenständiges Setup und verbindet sich mit dem lokalen MySQL-Server.

ClusterControlEine Konsole für Ihre gesamte DatenbankinfrastrukturErfahren Sie, was es sonst noch Neues in ClusterControl gibt. Installieren Sie ClusterControl KOSTENLOS

Migration der WHMCS-Datenbank zum MariaDB Galera-Cluster

Die Ausführung von WHMCS auf einem eigenständigen MySQL-Server setzt die Anwendung aus Datenbanksicht einem Single-Point-of-Failure (SPOF) aus. MariaDB Galera Cluster bietet Redundanz für die Datenschicht mit integrierten Clustering-Funktionen und Unterstützung für Multi-Master-Architektur. Kombinieren Sie dies mit einem Datenbank-Load-Balancer, z. B. ProxySQL, und wir können die Verfügbarkeit der WHMCS-Datenbank mit sehr minimalen Änderungen an der Anwendung selbst verbessern.

Es gibt jedoch eine Reihe von Best Practices, die WHMCS (oder andere Anwendungen) befolgen müssen, um effizient mit Galera Cluster zu arbeiten, insbesondere:

  • Alle Tabellen müssen auf der InnoDB/XtraDB-Speicher-Engine ausgeführt werden.
  • Für alle Tabellen sollte ein Primärschlüssel definiert sein (mehrspaltige Primärschlüssel werden unterstützt, eindeutige Schlüssel zählen nicht).

Abhängig von der installierten Version erfüllten in unserer Testumgebungsinstallation (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 über Site Software) die beiden oben genannten Punkte die Anforderung nicht. Die standardmäßige cPanel/WHM-MySQL-Konfiguration enthält die folgende Zeile in /etc/my.cnf:

default-storage-engine=MyISAM

Das Obige würde dazu führen, dass zusätzliche Tabellen, die von WHMCS-Addon-Modulen verwaltet werden, im MyISAM-Speicher-Engine-Format erstellt werden, wenn diese Module aktiviert sind. Hier ist die Ausgabe der Speicher-Engine, nachdem wir 2 Module aktiviert haben (Neue TLDs und Staff Noticeboard):

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

Die MyISAM-Unterstützung in Galera ist experimentell, was bedeutet, dass Sie sie nicht in der Produktion ausführen sollten. In einigen schlimmeren Fällen könnte es aufgrund seiner nicht transaktionalen Natur die Datenkonsistenz gefährden und Writeset-Replikationsfehler verursachen.

Ein weiterer wichtiger Punkt ist, dass für jede Tabelle ein Primärschlüssel definiert sein muss. Abhängig von dem WHMCS-Installationsverfahren, das Sie durchgeführt haben (wir haben cPanel Site Software verwendet, um WHMCS zu installieren), sind einige der vom Installationsprogramm erstellten Tabellen nicht mit einem definierten Primärschlüssel versehen, wie in der folgenden Ausgabe gezeigt:

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

Als Randnotiz würde Galera weiterhin Tabellen ohne Primärschlüssel zulassen. Allerdings werden DELETE-Operationen auf diesen Tabellen nicht unterstützt, außerdem würden Sie dadurch viel größeren Problemen ausgesetzt, wie z

Um dies zu umgehen, muss unser Migrationsplan den zusätzlichen Schritt zum Korrigieren der Speicher-Engine und der Schemastruktur enthalten, wie im nächsten Abschnitt gezeigt.

Migrationsplan

Aufgrund der im vorherigen Kapitel erläuterten Einschränkungen muss unser Migrationsplan in etwa so aussehen:

  1. WHMCS-Wartungsmodus aktivieren
  2. Erstellen Sie Backups der whmcs-Datenbank mit logischem Backup
  3. Modifizieren Sie die Dump-Dateien, um die Anforderungen von Galera zu erfüllen (Speicher-Engine konvertieren)
  4. Fahren Sie einen der Galera-Knoten hoch und lassen Sie die restlichen Knoten herunterfahren
  5. Auf dem ausgewählten Galera-Knoten wiederherstellen
  6. Korrigieren Sie die Schemastruktur, um die Anforderungen von Galera zu erfüllen (fehlende Primärschlüssel)
  7. Booten Sie den Cluster vom ausgewählten Galera-Knoten
  8. Starten Sie den zweiten Knoten und lassen Sie ihn synchronisieren
  9. Starten Sie den dritten Knoten und lassen Sie ihn synchronisieren
  10. Ändern Sie die Datenbank, die auf den entsprechenden Endpunkt verweist
  11. Deaktivieren Sie den WHMCS-Wartungsmodus

Die neue Architektur kann wie folgt dargestellt werden:

Der Name unserer WHMCS-Datenbank auf dem cPanel-Server lautet „whmcsdata_whmcs“, und wir werden diese Datenbank auf einen externen MariaDB Galera-Cluster mit drei Knoten migrieren, der von ClusterControl bereitgestellt wird. Auf dem Datenbankserver läuft ein ProxySQL (zusammen mit ClusterControl), das als MariaDB-Load-Balancer fungiert und den einzelnen Endpunkt für unsere WHMCS-Instanz bereitstellt. Der Datenbankname auf dem Cluster wird stattdessen in „portal_whmcs“ geändert, damit wir ihn leicht unterscheiden können.

Aktivieren Sie zunächst den standortweiten Wartungsmodus, indem Sie zu WHMCS> Setup> Allgemeine Einstellungen> Allgemein> Wartungsmodus> Zum Aktivieren markieren – verhindert den Zugriff auf den Clientbereich, wenn aktiviert gehen . Dadurch wird sichergestellt, dass der Endbenutzer während des Datenbanksicherungsvorgangs keine Aktivitäten ausführt.

Da wir geringfügige Änderungen an der Schemastruktur vornehmen müssen, um gut in Galera zu passen, ist es eine gute Idee, zwei separate Dump-Dateien zu erstellen. Eine nur mit dem Schema und eine andere nur für Daten. Führen Sie auf dem WHM-Server den folgenden Befehl als Root aus:

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

Dann müssen wir alle MyISAM-Vorkommen in der Schema-Dump-Datei durch „InnoDB“ ersetzen:

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

Stellen Sie sicher, dass wir keine MyISAM-Zeilen mehr in der Dump-Datei haben (es sollte nichts zurückgeben):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Übertragen Sie die Dump-Dateien vom WHM-Server nach mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Erstellen Sie die MySQL-Datenbank. Gehen Sie in ClusterControl zu Verwalten -> Schemas und Benutzer -> Datenbank erstellen und geben Sie den Datenbanknamen an. Hier verwenden wir einen anderen Datenbanknamen namens "portal_whmcs". Andernfalls können Sie die Datenbank mit dem folgenden Befehl manuell erstellen:

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

Erstellen Sie einen MySQL-Benutzer für diese Datenbank mit seinen Berechtigungen. Gehen Sie in ClusterControl zu Verwalten -> Schemata und Benutzer -> Benutzer -> Neuen Benutzer erstellen und geben Sie Folgendes an:

Falls Sie den MySQL-Benutzer manuell erstellen möchten, führen Sie die folgenden Anweisungen aus:

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

Beachten Sie, dass der erstellte Datenbankbenutzer in ProxySQL importiert werden muss, damit sich die WHMCS-Anwendung beim Load Balancer authentifizieren kann. Gehen Sie zu Knoten -> wählen Sie den ProxySQL-Knoten -> Benutzer -> Benutzer importieren und wählen Sie "portal_whmcs"@"%", wie im folgenden Screenshot gezeigt:

Geben Sie im nächsten Fenster (Benutzereinstellungen) die Hostgruppe 10 als Standard-Hostgruppe an:

Jetzt ist die Vorbereitungsphase für die Restaurierung abgeschlossen.

In Galera ist die Wiederherstellung einer großen Datenbank über mysqldump auf einem Single-Node-Cluster effizienter, was die Wiederherstellungszeit erheblich verkürzt. Andernfalls müsste jeder Knoten im Cluster jede Anweisung aus der mysqldump-Eingabe zertifizieren, was mehr Zeit in Anspruch nehmen würde.

Da wir bereits einen MariaDB-Galera-Cluster mit drei Knoten ausführen, stoppen wir den MySQL-Dienst auf mariadb2 und mariadb3, einen Knoten nach dem anderen, um eine elegante Herunterskalierung zu ermöglichen. Um die Datenbankknoten herunterzufahren, gehen Sie von ClusterControl einfach zu Knoten -> Knotenaktionen -> Knoten stoppen -> Fortfahren . Hier ist, was Sie vom ClusterControl-Dashboard sehen würden, wo die Clustergröße 1 ist und der Status von db1 Synced and Primary ist:

Stellen Sie dann auf mariadb1 (192.168.55.51) das Schema und die Daten entsprechend wieder her:

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

Nach dem Import müssen wir die Tabellenstruktur korrigieren, um die erforderliche „id“-Spalte (mit Ausnahme der Tabelle „tblaffiliates“) sowie den Primärschlüssel für alle fehlenden Tabellen hinzuzufügen:

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

Oder wir können die obigen wiederholten Anweisungen mit einer Schleife in einem Bash-Skript übersetzen:

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

An diesem Punkt ist es sicher, die verbleibenden Knoten zu starten, um sie mit mariadb1 zu synchronisieren. Beginnen Sie mit mariadb2, indem Sie zu Nodes -> pick db2 -> Node Actions -> Start Node gehen . Überwachen Sie den Jobfortschritt und stellen Sie sicher, dass sich mariadb2 im Status „Synced“ und „Primary“ befindet (beachten Sie die Übersichtsseite für Details), bevor Sie mariadb3 starten.

Ändern Sie schließlich die Datenbank, die auf den ProxySQL-Host auf Port 6033 in der WHMCS-Konfigurationsdatei verweist, da sie sich in unserem Fall unter /home/whmcsdata/public_html/configuration.php befindet:

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

Vergessen Sie nicht, den WHMCS-Wartungsmodus zu deaktivieren, indem Sie zu WHMCS> Setup> Allgemeine Einstellungen> Allgemein> Wartungsmodus gehen> das Kontrollkästchen „Zum Aktivieren aktivieren – verhindert den Zugriff auf den Clientbereich, wenn aktiviert“ deaktivieren . Unsere Übung zur Datenbankmigration ist nun abgeschlossen.

Testen und Tunen

Sie können dies überprüfen, indem Sie sich die Abfrageeinträge von ProxySQL unter Knoten -> ProxySQL -> Top-Abfragen ansehen :

Für die am häufigsten wiederholten schreibgeschützten Abfragen (Sie können sie nach Anzahl der Sterne sortieren) können Sie sie zwischenspeichern, um die Antwortzeit zu verbessern und die Anzahl der Zugriffe auf die Back-End-Server zu reduzieren. Fahren Sie einfach mit der Maus zu einer beliebigen Abfrage und klicken Sie auf Cache-Abfrage, und das folgende Popup-Fenster wird angezeigt:

Sie müssen lediglich die Ziel-Hostgruppe auswählen und auf „Regel hinzufügen“ klicken. Sie können dann auf der Registerkarte "Regeln" überprüfen, ob die zwischengespeicherte Abfrage getroffen wurde:

Aus der Abfrageregel selbst können wir erkennen, dass Lesevorgänge (alle SELECT außer SELECT .. FOR UPDATE) an Hostgruppe 20 weitergeleitet werden, wo die Verbindungen an alle Knoten verteilt werden, während Schreibvorgänge (außer SELECT) an Hostgruppe 10 weitergeleitet werden, wo die Verbindungen werden nur an einen Galera-Knoten weitergeleitet. Diese Konfiguration minimiert das Risiko von Deadlocks, die durch ein Multi-Master-Setup verursacht werden können, wodurch die Replikationsleistung insgesamt verbessert wird.

Das war es fürs Erste. Viel Spaß beim Clustern!