Jak przeprowadzić migrację bazy danych WHMCS do klastra MariaDB Galera

Instalacja WHMCS

Jeśli masz już zainstalowany i uruchomiony WHMCS, możesz pominąć ten krok.

Zwróć uwagę, że WHMCS wymaga ważnej licencji, którą musisz zakupić wcześniej, aby korzystać z oprogramowania. Nie zapewniają bezpłatnej licencji próbnej, ale oferują 30-dniową gwarancję zwrotu pieniędzy bez zadawania pytań, co oznacza, że ​​zawsze możesz anulować subskrypcję przed wygaśnięciem oferty bez opłat.

Aby uprościć proces instalacji, użyjemy oprogramowania cPanel Site Software (możesz zdecydować się na ręczną instalację WHMCS) w jednej z naszych subdomen, selfportal.mytest.io. Po utworzeniu konta w WHM przejdź do cPanel> Oprogramowanie> Oprogramowanie strony> WHMCS i zainstaluj aplikację internetową. Zaloguj się jako administrator i aktywuj licencję, aby rozpocząć korzystanie z aplikacji.

W tym momencie nasza instancja WHMCS działa jako samodzielna konfiguracja, łącząc się z lokalnym serwerem MySQL.

Migracja bazy danych WHMCS do klastra MariaDB Galera

Uruchamianie WHMCS na samodzielnym serwerze MySQL naraża aplikację na działanie pojedynczego punktu awarii (SPOF) z punktu widzenia bazy danych. Klaster MariaDB Galera zapewnia nadmiarowość w warstwie danych dzięki wbudowanym funkcjom klastrowania i obsłudze architektury multi-master. Połącz to z systemem równoważenia obciążenia bazy danych, na przykład ProxySQL, a możemy poprawić dostępność bazy danych WHMCS przy bardzo minimalnych zmianach w samej aplikacji.

Istnieje jednak wiele najlepszych praktyk, które WHMCS (lub inne aplikacje) muszą przestrzegać, aby wydajnie pracować w Galera Cluster, w szczególności:

• Wszystkie tabele muszą działać na silniku pamięci masowej InnoDB/XtraDB.
• Wszystkie tabele powinny mieć zdefiniowany klucz podstawowy (wielokolumnowy klucz podstawowy jest obsługiwany, unikalny klucz się nie liczy).

W zależności od zainstalowanej wersji, w naszej instalacji środowiska testowego (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 poprzez Site Software) powyższe dwa punkty nie spełniały wymagania. Domyślna konfiguracja cPanel/WHM MySQL zawiera następującą linię w /etc/my.cnf:

default-storage-engine=MyISAM

Powyższe spowoduje, że dodatkowe tabele zarządzane przez moduły dodatkowe WHMCS zostaną utworzone w formacie silnika pamięci masowej MyISAM, jeśli te moduły są włączone. Oto dane wyjściowe silnika pamięci masowej po włączeniu 2 modułów (nowe domeny TLD i tablica ogłoszeń personelu):

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

Obsługa MyISAM jest w Galerze eksperymentalna, co oznacza, że ​​nie należy jej uruchamiać w środowisku produkcyjnym. W niektórych gorszych przypadkach może to naruszyć spójność danych i spowodować błędy replikacji zbioru zapisu ze względu na jego nietransakcyjny charakter.

Innym ważnym punktem jest to, że każda tabela musi mieć zdefiniowany klucz podstawowy. W zależności od procedury instalacji WHMCS, którą wykonałeś (jak dla nas, użyliśmy oprogramowania cPanel Site do zainstalowania WHMCS), niektóre tabele utworzone przez instalatora nie mają zdefiniowanego klucza podstawowego, jak pokazano w następującym wyniku:

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

Na marginesie, Galera nadal zezwala na istnienie tabel bez klucza podstawowego. Jednak operacje DELETE nie są obsługiwane na tych tabelach, co naraziłoby Cię na znacznie większe problemy, takie jak awaria węzła, pogorszenie wydajności certyfikacji zestawu zapisu lub wiersze mogą pojawiać się w innej kolejności na różnych węzłach.

Aby rozwiązać ten problem, nasz plan migracji musi zawierać dodatkowy krok w celu naprawy silnika pamięci masowej i struktury schematu, jak pokazano w następnej sekcji.

Plan migracji

Ze względu na ograniczenia wyjaśnione w poprzednim rozdziale, nasz plan migracji musi wyglądać mniej więcej tak:

1. Włącz tryb konserwacji WHMCS
2. Tworzenie kopii zapasowych bazy danych whmcs za pomocą logicznej kopii zapasowej
3. Zmodyfikuj pliki zrzutu, aby spełniały wymagania Galera (silnik konwersji)
4. Podnieś jeden z węzłów Galera i pozwól pozostałym się zamknąć
5. Przywróć do wybranego węzła Galera
6. Napraw strukturę schematu, aby spełniała wymagania Galera (brak kluczy podstawowych)
7. Bootstrap klastra z wybranego węzła Galera
8. Uruchom drugi węzeł i pozwól mu się zsynchronizować
9. Uruchom trzeci węzeł i pozwól mu się zsynchronizować
10. Zmień bazę danych wskazującą na odpowiedni punkt końcowy
11. Wyłącz tryb konserwacji WHMCS

Nową architekturę można zilustrować poniżej:

Nazwa naszej bazy danych WHMCS na serwerze cPanel to „whmcsdata_whmcs” i zamierzamy przeprowadzić migrację tej bazy danych do zewnętrznego trzywęzłowego klastra MariaDB Galera wdrożonego przez ClusterControl. Na górze serwera bazy danych mamy uruchomiony ProxySQL (zlokalizowany razem z ClusterControl), który działa jako moduł równoważenia obciążenia MariaDB, zapewniając pojedynczy punkt końcowy naszej instancji WHMCS. Nazwa bazy danych w klastrze zostanie zmieniona na „portal_whmcs”, dzięki czemu będziemy mogli ją łatwo odróżnić.

Po pierwsze, włącz tryb konserwacji dla całej witryny, przechodząc do WHMCS> Konfiguracja> Ustawienia ogólne> Ogólne> Tryb konserwacji> Zaznacz, aby włączyć - uniemożliwia dostęp do obszaru klienta po włączeniu . Zapewni to brak aktywności ze strony użytkownika końcowego podczas operacji tworzenia kopii zapasowej bazy danych.

Ponieważ musimy wprowadzić drobne modyfikacje w strukturze schematu, aby dobrze pasowały do ​​Galery, dobrym pomysłem jest utworzenie dwóch oddzielnych plików zrzutu. Jeden tylko ze schematem, a drugi tylko dla danych. Na serwerze WHM uruchom następujące polecenie jako root:

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

Następnie musimy zastąpić wszystkie wystąpienia MyISAM w pliku zrzutu schematu na „InnoDB”:

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

Sprawdź, czy w pliku zrzutu nie ma już wierszy MyISAM (powinien nic nie zwracać):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Przenieś pliki zrzutu z serwera WHM do mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Utwórz bazę danych MySQL. W ClusterControl przejdź do Zarządzaj -> Schematy i użytkownicy -> Utwórz bazę danych i określ nazwę bazy danych. Tutaj używamy innej nazwy bazy danych o nazwie „portal_whmcs”. W przeciwnym razie możesz ręcznie utworzyć bazę danych za pomocą następującego polecenia:

$ mysql -uroot -p 

MariaDB> CREATE DATABASE 'portal_whmcs';

Utwórz użytkownika MySQL dla tej bazy danych z jego uprawnieniami. W ClusterControl przejdź do Zarządzaj -> Schematy i użytkownicy -> Użytkownicy -> Utwórz nowego użytkownika i podaj następujące informacje:

Jeśli zdecydujesz się ręcznie utworzyć użytkownika MySQL, uruchom następujące instrukcje:

$ mysql -uroot -p 

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

Zwróć uwagę, że utworzony użytkownik bazy danych musi zostać zaimportowany do ProxySQL, aby umożliwić aplikacji WHMCS uwierzytelnienie względem modułu równoważenia obciążenia. Przejdź do Węzły -> wybierz węzeł ProxySQL -> Użytkownicy -> Importuj użytkowników i wybierz "portal_whmcs"@"%", jak pokazano na poniższym zrzucie ekranu:

W następnym oknie (Ustawienia użytkownika) określ Hostgroup 10 jako domyślną grupę hostów:

Teraz etap przygotowania renowacji jest zakończony.

W Galera przywracanie dużej bazy danych za pośrednictwem mysqldump w klastrze z jednym węzłem jest bardziej wydajne, co znacznie skraca czas przywracania. W przeciwnym razie każdy węzeł w klastrze musiałby certyfikować każdą instrukcję z danych wejściowych mysqldump, co zajęłoby więcej czasu.

Ponieważ mamy już działający trzywęzłowy klaster MariaDB Galera, zatrzymajmy usługę MySQL na mariadb2 i mariadb3, po jednym węźle na raz, aby uzyskać łagodne skalowanie w dół. Aby zamknąć węzły bazy danych, z ClusterControl, po prostu przejdź do Węzły -> Akcje węzłów -> Zatrzymaj węzeł -> Kontynuuj . Oto, co można zobaczyć na pulpicie nawigacyjnym ClusterControl, gdzie rozmiar klastra wynosi 1, a stan bazy danych db1 to Zsynchronizowany i Podstawowy:

Następnie na mariadb1 (192.168.55.51) przywróć odpowiednio schemat i dane:

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

Po zaimportowaniu musimy poprawić strukturę tabeli, aby dodać niezbędną kolumnę „id” (z wyjątkiem tabeli „tblaffiliates”), a także dodać klucz podstawowy do wszystkich tabel, w których ich brakowało:

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

Lub możemy przetłumaczyć powyższe powtórzone instrukcje za pomocą pętli w skrypcie basha:

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

W tym momencie można bezpiecznie uruchomić pozostałe węzły do ​​synchronizacji z mariadb1. Zacznij od mariadb2 przechodząc do Węzły -> wybierz db2 -> Akcje węzła -> Uruchom węzeł . Monitoruj postęp zadania i upewnij się, że mariadb2 jest w stanie zsynchronizowanym i podstawowym (aby uzyskać szczegółowe informacje, monitoruj stronę Przegląd) przed uruchomieniem mariadb3.

Na koniec zmień bazę danych wskazującą hosta ProxySQL na porcie 6033 w pliku konfiguracyjnym WHMCS, tak jak w naszym przypadku znajduje się ona w /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';

Nie zapomnij wyłączyć trybu konserwacji WHMCS, przechodząc do WHMCS> Konfiguracja> Ustawienia ogólne> Ogólne> Tryb konserwacji> odznacz „Zaznacz, aby włączyć – uniemożliwia dostęp do obszaru klienta po włączeniu” . Nasze ćwiczenie dotyczące migracji bazy danych zostało zakończone.

Testowanie i dostrajanie

Możesz to sprawdzić, przeglądając wpisy zapytań ProxySQL w sekcji Węzły -> ProxySQL -> Najpopularniejsze zapytania :

W przypadku najczęściej powtarzających się zapytań tylko do odczytu (możesz je posortować według Gwiazdki) możesz je buforować, aby skrócić czas odpowiedzi i zmniejszyć liczbę trafień na serwery zaplecza. Po prostu najedź na dowolne zapytanie i kliknij Zapytanie w pamięci podręcznej, a pojawi się następujące wyskakujące okienko:

Musisz tylko wybrać docelową grupę hostów i kliknąć „Dodaj regułę”. Następnie możesz sprawdzić, czy zapytanie w pamięci podręcznej zostało trafione w zakładce „Reguły”:

Z samej reguły zapytania możemy powiedzieć, że odczyty (wszystkie SELECT z wyjątkiem SELECT .. FOR UPDATE) są przekazywane do grupy hostów 20, gdzie połączenia są dystrybuowane do wszystkich węzłów, podczas gdy zapisy (inne niż SELECT) są przekazywane do grupy hostów 10, gdzie połączenia są są przekazywane tylko do jednego węzła Galera. Taka konfiguracja minimalizuje ryzyko zakleszczeń, które mogą być spowodowane przez konfigurację z wieloma wzorcami, co poprawia ogólną wydajność replikacji.

Na razie to wszystko. Miłego klastrowania!