MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Как да мигрираме WHMCS база данни към MariaDB Galera Cluster

WHMCS е универсално решение за управление на клиенти, фактуриране и поддръжка за уеб хостинг компании. Това е един от лидерите в света за автоматизация на хостинг, който се използва заедно със самия контролен панел на хостинг. WHMCS работи на LAMP стек, като MySQL/MariaDB е доставчик на база данни. Обикновено WHMCS се инсталира като самостоятелен екземпляр (приложение и база данни) независимо, като се следва ръководството за инсталиране на WHMCS или чрез инструменти за инсталиране на софтуер като cPanel Site Software или Softaculous. Базата данни може да стане високо достъпна чрез мигриране към клъстер Galera от 3 възела.

В тази публикация в блога ще ви покажем как да мигрирате WHMCS базата данни от самостоятелен MySQL сървър (осигурен от самия сървър на WHM/cPanel) към външен клъстер MariaDB Galera с три възела, за да подобрите наличността на базата данни. Самото приложение WHMCS ще продължи да работи на същия cPanel сървър. Ще ви дадем и някои съвети за настройка за оптимизиране на производителността.

Разгръщане на клъстер от база данни

  1. Инсталирайте ClusterControl:
    $ whoami
    root
    $ wget https://severalnines.com/downloads/cmon/install-cc
    $ chmod 755 install-cc
    $ ./install-cc
    Следвайте съответно инструкциите, докато инсталацията приключи. След това отидете на http://192.168.55.50/clustercontrol (192.168.55.50 е IP адресът на хоста на ClusterControl) и регистрирайте суперадминистраторски потребител с парола и други необходими подробности.
  2. Настройте SSH без парола от ClusterControl към всички възли на базата данни:
    $ 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. Конфигурирайте внедряването на базата данни за нашия клъстер MariaDB Galera с 3 възела. Ще използваме най-новата поддържана версия MariaDB 10.3: Уверете се, че получавате всички зелени отметки, след като натиснете „Enter“, когато добавяте подробностите за възела. Изчакайте, докато задачата за внедряване приключи и трябва да видите, че клъстерът на базата данни е посочен в ClusterControl.
  4. Разгръщане на ProxySQL възел (ще го локализираме заедно с възела ClusterControl), като отидете на Управление -> Балансиране на натоварването -> ProxySQL -> Внедряване на ProxySQL . Посочете следните необходими подробности: Под "Добавяне на потребител на база данни" можете да помолите ClusterControl да създаде нов потребител на ProxySQL и MySQL, докато се настройва , по този начин поставяме потребителя като "portal_whmcs", присвоен с ВСИЧКИ ПРИВИЛЕГИИ в базата данни "portal_whmcs.*". След това поставете отметка във всички квадратчета за „Включване“ и накрая изберете „false“ за „Използвате ли неявни транзакции?“.

След като разполагането приключи, трябва да видите нещо подобно под изглед на топология:

Свързани ресурси Най-добрият доставчик на хостинг в Австралия използва ClusterControl, за да предостави опит от световна класа за своите потребителски опити от световна класа и да предостави на своите потребители QL MariaDB с ProxySQL - Урок Висока достъпност MySQL на cPanel с Galera Cluster

Внедряването на нашата база данни вече е завършено. Имайте предвид, че в тази публикация в блога не обхващаме дублирането на ниво балансиране на натоварване. Можете да постигнете това, като добавите вторичен балансьор на натоварването и ги свържете заедно с Keepalived. За да научите повече за това, вижте уроци за ProxySQL в глава "4.2. Висока наличност за ProxySQL".

Инсталиране на WHMCS

Ако вече имате инсталиран и работещ WHMCS, можете да пропуснете тази стъпка.

Обърнете внимание, че WHMCS изисква валиден лиценз, който трябва да закупите предварително, за да използвате софтуера. Те не предоставят безплатен пробен лиценз, но предлагат 30-дневна гаранция за връщане на парите без въпроси, което означава, че винаги можете да анулирате абонамента преди изтичането на офертата, без да бъдете таксувани.

За да опростим процеса на инсталиране, ще използваме cPanel Site Software (можете да изберете ръчна инсталация на WHMCS) към един от нашите поддомейни, selfportal.mytest.io. След като създадете акаунта в WHM, отидете на cPanel> Софтуер> Софтуер на сайта> WHMCS и инсталирайте уеб приложението. Влезте като администратор и активирайте лиценза, за да започнете да използвате приложението.

В този момент нашият WHMCS екземпляр работи като самостоятелна настройка, свързвайки се с локалния MySQL сървър.

ClusterControlЕдинична конзола за цялата ви инфраструктура на базата данни Открийте какво още е новото в ClusterControlИнсталирайте ClusterControl БЕЗПЛАТНО

Мигриране на базата данни WHMCS към MariaDB Galera Cluster

Изпълнението на WHMCS на самостоятелен MySQL сървър излага приложението на единична точка на неизправност (SPOF) от гледна точка на базата данни. MariaDB Galera Cluster осигурява резервиране на слоя данни с вградени функции за клъстериране и поддръжка за многоглавна архитектура. Комбинирайте това с балансьор на натоварване на базата данни, например ProxySQL, и можем да подобрим наличността на база данни на WHMCS с много минимални промени в самото приложение.

Въпреки това, има редица най-добри практики, които WHMCS (или други приложения) трябва да следват, за да работят ефективно върху Galera Cluster, особено:

  • Всички таблици трябва да работят на InnoDB/XtraDB машина за съхранение.
  • Всички таблици трябва да имат дефиниран първичен ключ (поддържа се първичен ключ от няколко колони, уникалният ключ не се брои).

В зависимост от инсталираната версия, в инсталацията на нашата тестова среда (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 чрез софтуера на сайта), горните две точки не отговарят на изискването. Конфигурацията на cPanel/WHM MySQL по подразбиране идва със следния ред вътре в /etc/my.cnf:

default-storage-engine=MyISAM

Горното ще доведе до създаване на допълнителни таблици, управлявани от модулите на WHMCS Addon, във формат MyISAM на механизма за съхранение, ако тези модули са активирани. Ето изхода на механизма за съхранение, след като сме активирали 2 модула (нови TLD и табло за известия на персонала):

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 е експериментална в Galera, което означава, че не трябва да я стартирате в производство. В някои по-лоши случаи това може да компрометира последователността на данните и да причини неуспехи при репликация на набора за запис поради своя нетранзакционен характер.

Друг важен момент е, че всяка таблица трябва да има дефиниран първичен ключ. В зависимост от инсталационната процедура на WHMCS, която сте изпълнили (както за нас, ние използвахме cPanel Site Software за инсталиране на WHMCS), някои от таблиците, създадени от инсталатора, не идват с дефиниран първичен ключ, както е показано в следния изход:

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

Като странична бележка, Galera все пак ще позволи съществуването на таблици без първичен ключ. Въпреки това, операциите DELETE не се поддържат в тези таблици, плюс това би ви изложило на много по-големи проблеми като срив на възел, влошаване на производителността на сертифициране за запис или редове може да се появят в различен ред на различни възли.

За да преодолеем това, нашият план за миграция трябва да включва допълнителната стъпка за коригиране на механизма за съхранение и структурата на схемата, както е показано в следващия раздел.

План за миграция

Поради ограниченията, обяснени в предишната глава, нашият план за миграция трябва да бъде нещо подобно:

  1. Активиране на режима за поддръжка на WHMCS
  2. Направете резервни копия на базата данни whmcs, като използвате логическо архивиране
  3. Променете дъмп файловете, за да отговарят на изискването на Galera (конвертиране на хранилище)
  4. Изведете един от възлите на Galera и оставете останалите възли да се изключат
  5. Възстановете до избрания възел на Galera
  6. Коригирайте структурата на схемата, за да отговаря на изискването на Galera (липсващи първични ключове)
  7. Стартирайте клъстера от избрания възел на Galera
  8. Стартирайте втория възел и го оставете да се синхронизира
  9. Стартирайте третия възел и го оставете да се синхронизира
  10. Променете базата данни, сочеща към подходящата крайна точка
  11. Деактивирайте режима на поддръжка на WHMCS

Новата архитектура може да бъде илюстрирана, както следва:

Името на нашата WHMCS база данни на cPanel сървъра е "whmcsdata_whmcs" и ние ще мигрираме тази база данни към външен клъстер MariaDB Galera с три възела, разгърнат от ClusterControl. Върху сървъра на базата данни имаме ProxySQL (съвместно локализиране с ClusterControl), работещ, за да действа като балансьор на натоварване на MariaDB, осигурявайки единичната крайна точка на нашия WHMCS екземпляр. Вместо това името на базата данни в клъстера ще бъде променено на "portal_whmcs", за да можем лесно да го различим.

Първо, активирайте режима на поддръжка за целия сайт, като отидете на WHMCS> Настройка> Общи настройки> Общи> Режим на поддръжка> Поставете отметка за активиране - предотвратява достъпа до клиентската зона, когато е активиран . Това ще гарантира, че няма да има активност от крайния потребител по време на операцията за архивиране на базата данни.

Тъй като трябва да направим леки модификации на структурата на схемата, за да се впише добре в Galera, е добра идея да създадете два отделни файла за изхвърляне. Един само със схемата и друг само за данни. На сървъра на WHM изпълнете следната команда като root:

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

След това трябва да заменим всички случаи на MyISAM в дъмп файла на схемата с 'InnoDB':

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

Уверете се, че вече нямаме MyISAM редове в дъмп файла (той не трябва да връща нищо):

$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Прехвърлете дъмп файловете от сървъра WHM към mariadb1 (192.168.55.51):

$ scp whmcsdata_whmcs_* 192.168.55.51:~

Създайте MySQL база данни. От ClusterControl отидете на Управление -> Схеми и потребители -> Създаване на база данни и посочете името на базата данни. Тук използваме различно име на база данни, наречено "portal_whmcs". В противен случай можете ръчно да създадете базата данни със следната команда:

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

Създайте MySQL потребител за тази база данни с неговите привилегии. От ClusterControl отидете на Управление -> Схеми и потребители -> Потребители -> Създаване на нов потребител и посочете следното:

В случай, че решите да създадете потребителя на MySQL ръчно, изпълнете следните оператори:

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

Обърнете внимание, че създаденият потребител на база данни трябва да бъде импортиран в ProxySQL, за да позволи на приложението WHMCS да се удостовери спрямо балансира на натоварването. Отидете на Възли -> изберете възела ProxySQL -> Потребители -> Импортиране на потребители и изберете "portal_whmcs"@"%", както е показано на следната екранна снимка:

В следващия прозорец (Потребителски настройки) посочете Hostgroup 10 като хост група по подразбиране:

Сега подготвителният етап за възстановяване е завършен.

В Galera възстановяването на голяма база данни чрез mysqldump в клъстер с един възел е по-ефективно и това значително подобрява времето за възстановяване. В противен случай всеки възел в клъстера ще трябва да сертифицира всяко изявление от входа mysqldump, което ще отнеме повече време за завършване.

Тъй като вече имаме работещ MariaDB Galera Cluster с три възела, нека спрем услугата MySQL на mariadb2 и mariadb3, един възел в даден момент за грациозно намаляване на мащаба. За да изключите възлите на базата данни, от ClusterControl, просто отидете на Възли -> Действия на възел -> Стоп възел -> Напред . Ето какво ще видите от таблото за управление на ClusterControl, където размерът на клъстера е 1 и състоянието на db1 е синхронизирано и основно:

След това, на 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

След като импортираме, трябва да коригираме структурата на таблицата, за да добавим необходимата колона "id" (с изключение на таблицата "tblaffiliates"), както и да добавим първичния ключ към всички таблици, на които липсват каквито и да било:

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

Или можем да преведем горните повтарящи се изрази с помощта на цикъл в 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

В този момент е безопасно да стартирате останалите възли, за да се синхронизират с mariadb1. Започнете с mariadb2, като отидете на Nodes -> изберете db2 -> Node Actions -> Start Node . Наблюдавайте напредъка на заданието и се уверете, че mariadb2 е в синхронизирано и основно състояние (наблюдавайте страницата Преглед за подробности), преди да стартирате mariadb3.

И накрая, променете базата данни, сочеща към хоста ProxySQL на порт 6033 в конфигурационния файл на WHMCS, тъй като в нашия случай тя се намира на /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';

Не забравяйте да деактивирате режима на поддръжка на WHMCS, като отидете на WHMCS> Настройка> Общи настройки> Общи> Режим на поддръжка> премахнете отметката от „Отметка за активиране – предотвратява достъпа до клиентската зона, когато е активиран“ . Нашето упражнение за миграция на база данни вече е завършено.

Тестване и настройка

Можете да проверите дали, като разгледате записите на заявката на ProxySQL под Възли -> ProxySQL -> Топ заявки :

За най-повтарящите се заявки само за четене (можете да ги сортирате по Count Star) можете да ги кеширате, за да подобрите времето за реакция и да намалите броя на посещенията към сървърите на бекенда. Просто превъртете към която и да е заявка и щракнете върху Кеш заявка и ще се появи следният изскачащ прозорец:

Това, което трябва да направите, е само да изберете целевата хост група и да кликнете върху „Добавяне на правило“. След това можете да проверите дали кешираната заявка е била ударена в раздела „Правила“:

От самото правило за заявка можем да разберем, че четенията (всички SELECT с изключение на SELECT .. FOR UPDATE) се препращат към хост група 20, където връзките се разпределят до всички възли, докато записите (различни от SELECT) се препращат към хост група 10, където връзките се препращат само към един възел на Galera. Тази конфигурация свежда до минимум риска от блокиране, което може да бъде причинено от настройка с няколко главни, което подобрява производителността на репликацията като цяло.

Това е всичко за сега. Приятно групиране!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как ATAN() работи в MariaDB

  2. Как работи FROM_BASE64() в MariaDB

  3. Аварийно възстановяване за Galera Cluster, разположено в хибриден облак

  4. Как ELT() работи в MariaDB

  5. Как работи МАЧ СРЕЩУ в MariaDB