В първата част от поредицата ви показахме как да разположите настройка за репликация на MySQL с ProxySQL с WHM и cPanel. В тази част ще покажем някои операции след внедряването за поддръжка, управление, преодоляване на срив, както и предимства пред самостоятелната настройка.
Управление на потребителите на MySQL
С активирана тази интеграция, MySQL управлението на потребителите ще трябва да се извършва от WHM или cPanel. В противен случай таблицата на ProxySQL mysql_users няма да се синхронизира с това, което е конфигурирано за нашия главен код за репликация. Да предположим, че вече сме създали потребител, наречен multiplen_user1 (потребителското име на MySQL е автоматично префиксирано от cPanel, за да се съобразим с ограничението на MySQL) и бихме искали да присвоим към базата данни fewn_db1, както е по-долу:
Горното ще доведе до следния изход на таблица mysql_users в ProxySQL:
Ако искате да създадете MySQL ресурси извън cPanel, можете да използвате ClusterControl -> Manage -> Schemas and Users функция и след това импортирайте потребителя на базата данни в ProxySQL, като отидете на ClusterControl -> Nodes -> изберете възела ProxySQL -> Потребители -> Импортиране на потребители .
Модулът Proxysqlhook, който използваме за синхронизиране на потребителите на ProxySQL, изпраща регистрационните файлове за отстраняване на грешки в /usr/local/cpanel/logs/error_log. Използвайте този файл, за да проверите и разберете какво се случва зад кулисите. Следните редове ще се появят в регистрационния файл на cPanel, ако инсталираме уеб приложение, наречено Zikula, използвайки Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Ще видите някои повтарящи се редове като "Проверка дали {DB user} съществува", защото WHM създава множество потребители/хост на MySQL за всяка потребителска заявка за създаване на база данни. В нашия пример WHM ще създаде тези 3 потребители:
ProxySQL се нуждае само от потребителско име, парола и информация за групата по подразбиране при добавяне на потребител. Следователно линиите за проверка са налице, за да се избегнат множество вмъквания на един и същ потребител.
Ако искате да модифицирате модула и да направите някои подобрения в него, не забравяйте да го регистрирате отново, като изпълните следната команда на WHM сървъра:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookНаблюдение и кеширане на заявки
С ProxySQL можете да наблюдавате всички заявки, идващи от приложението, които са преминали или преминават през него. Стандартният WHM не предоставя това ниво на детайлност при наблюдението на MySQL заявки. Следното показва всички MySQL заявки, които са били заснети от ProxySQL:
С ClusterControl можете лесно да търсите най-повтарящите се заявки и да ги кеширате чрез функцията за кеширане на заявки ProxySQL. Използвайте падащото меню „Поръчай по“, за да сортирате заявките по „Звезда за броене“, преместете с мишката до заявката, която искате да кеширате, и щракнете върху бутона „Кеширане на заявка“ под нея. Ще се появи следният диалогов прозорец:
Резултатът от кеширани заявки ще се съхранява и обслужва от самия ProxySQL, намалявайки броя на посещенията към бекенда, което ще разтовари вашия MySQL репликационен клъстер като цяло. Реализацията на кеша на заявките на ProxySQL е коренно различна от кеша на заявките на MySQL. Това е кеш, базиран на времето и ще изтече след изтичане на времето, наречено "Cache TTL". В тази конфигурация бихме искали да кешираме горната заявка за 5 секунди (5000 ms) от удрянето на групата четец, където целевата хост група е 20.
Разделяне и балансиране на четене/запис
Като слуша MySQL порт по подразбиране 3306, ProxySQL действа като самия MySQL сървър. Той говори MySQL протоколи както на фронтенда, така и на бекенда. Правилата за заявка, дефинирани от ClusterControl при настройката на ProxySQL, автоматично ще разделят всички четения (^SELECT .* на език Regex) на хостгрупа 20, която е групата за четене, а останалите ще бъдат препратени към групата за записване 10, както е показано в следната секция с правила за заявка:
С тази архитектура не е нужно да се притеснявате за разделяне на заявки за четене/запис, тъй като ProxySQL ще свърши работата вместо вас. Потребителите имат минимални или никакви промени в кода, което позволява на потребителите на хостинг да използват всички приложения и функции, предоставени от WHM и cPanel, подобно на свързването към самостоятелна настройка на MySQL.
По отношение на балансирането на връзките, ако имате повече от един активен възел в конкретна хост група (като четец хост група 20 в този пример), ProxySQL автоматично ще разпредели натоварването между тях въз основа на редица критерии - тегла, забавяне на репликацията, използвани връзки , общо натоварване и латентност. Известно е, че ProxySQL е много добър в среда с висок паралелизъм чрез внедряване на усъвършенстван механизъм за обединяване на връзки. Цитирано от публикация в блога на ProxySQL, ProxySQL не само прилага постоянна връзка, но и мултиплексиране на връзки. Всъщност ProxySQL може да се справи със стотици хиляди клиенти, но препраща целия им трафик към няколко връзки към бекенда. Така ProxySQL може да обработва N клиентски връзки и M бекенд връзки, където N> M (дори N хиляди пъти по-голямо от M).
Отказ и възстановяване на MySQL
С ClusterControl, управляващ клъстера за репликация, преминаването при отказ се извършва автоматично, ако автоматичното възстановяване е активирано. В случай на повреда на главната:
- ClusterControl ще открие и провери главната грешка чрез MySQL клиент, SSH и ping.
- ClusterControl ще изчака 3 секунди, преди да започне процедура за преодоляване на отказ.
- ClusterControl ще насърчава най-актуалния подчинен да стане следващият главен.
- Ако старият главен код се върне онлайн, той ще бъде стартиран като само за четене, без да участва в активното репликация.
- Потребителите трябва да решат какво ще се случи със стария господар. Тя може да бъде въведена обратно във веригата на репликация чрез използване на функционалността „Rebuild Replication Slave“ в ClusterControl.
- ClusterControl ще се опита само веднъж да извърши основното преминаване при отказ. Ако не успее, е необходима намеса на потребителя.
Можете да наблюдавате целия процес на отказване под ClusterControl -> Activity -> Jobs -> Failover to a new master както е показано по-долу:
По време на отказ, всички връзки към сървърите на базата данни ще бъдат поставени на опашка в ProxySQL. Те няма да бъдат прекратени до изчакване, контролирано от mysql-default_query_timeout променлива, която е 86400000 милисекунди или 24 часа. Приложенията най-вероятно няма да видят грешки или повреди в базата данни в този момент, но компромисът е увеличената латентност в рамките на конфигурируем праг.
В този момент ClusterControl ще представи топологията, както следва:
Ако искаме да позволим на стария главен елемент да се присъедини обратно към репликацията, след като е готов и наличен, ще трябва да го изградим отново като подчинен, като отидем на ClusterControl -> Nodes -> изберете стария главен -> Повторно изграждане на репликация Подчинен -> изберете новия главен -> Напред . След като възстановяването приключи, трябва да получите следната топология (забележете, че 192.168.0.32 е главната сега):
Консолидация на сървъра и мащабиране на базата данни
С тази архитектура можем да консолидираме много MySQL сървъри, които се намират на всеки WHM сървър в една единствена настройка за репликация. Можете да мащабирате повече възли на базата данни, докато растете, или да имате множество клъстери за репликация, за да поддържате всички тях и да се управляват от един сървър ClusterControl. Следната архитектурна диаграма илюстрира дали имаме два WHM сървъра, свързани към един единствен MySQL репликационен клъстер чрез ProxySQL сокет файл:
Горното ни позволява да разделим двете най-важни нива в нашата хостинг система – приложение (front-end) и база данни (back-end). Както може би знаете, съвместното локализиране на MySQL в сървъра WHM обикновено води до изчерпване на ресурсите, тъй като MySQL се нуждае от огромно предварително разпределение на RAM, за да стартира и да работи добре (най-вече в зависимост от innodb_buffer_pool_size променлива). Като се има предвид, че дисковото пространство е достатъчно, с горната настройка можете да имате повече хостинг акаунти, хоствани на сървър, където всички сървърни ресурси могат да се използват от приложенията на предния край.
Увеличаването на клъстера за репликация на MySQL ще бъде много по-лесно с отделна архитектура на ниво. Ако да кажем, че главният изисква поддръжка на мащабиране (надграждане на RAM, твърд диск, RAID, NIC), можем да превключим главната роля на друг подчинен (ClusterControl -> Nodes -> изберете подчинен -> Promote Slave ) и след това изпълни задачата за поддръжка, без да засяга услугата MySQL като цяло. За операция за мащабиране (добавяне на повече подчинени устройства), можете да извършите това, без дори да засягате главния, като извършите стадия директно от който и да е активен подчинен. С ClusterControl можете дори да създадете нов подчинен от съществуващ MySQL архив (само съвместим с PITR):
Възстановяването на подчинен от резервно копие няма да донесе допълнителна тежест за главния. ClusterControl ще копира избрания архивен файл от сървъра на ClusterControl в целевия възел и ще извърши възстановяването там. След като приключи, възелът ще се свърже с главната и ще започне да извлича всички липсващи транзакции от времето за възстановяване и ще настигне главната. Когато изостава, ProxySQL няма да включи възела в набора за балансиране на натоварването, докато забавянето на репликацията не е по-малко от 10 секунди (конфигурира се при добавяне на таблица mysql_servers чрез администраторски интерфейс на ProxySQL).
Последни мисли
ProxySQL разширява възможностите на WHM cPanel при управлението на MySQL репликация. С ClusterControl, управляващ вашия клъстер за репликация, всички сложни задачи, свързани с управлението на клъстера за репликация, вече са по-лесни от всякога.
