V první části seriálu jsme vám ukázali, jak nasadit nastavení replikace MySQL s ProxySQL s WHM a cPanel. V této části ukážeme některé operace po nasazení pro údržbu, správu, převzetí služeb při selhání a také výhody oproti samostatnému nastavení.
Správa uživatelů MySQL
Pokud je tato integrace povolena, správa uživatelů MySQL bude muset být provedena z WHM nebo cPanel. Jinak by se ProxySQL tabulka mysql_users nesynchronizovala s tím, co je nakonfigurováno pro náš hlavní replikační server. Předpokládejme, že jsme již vytvořili uživatele s názvem fewn_user1 (uživatelské jméno MySQL má automaticky předponu cPanel, aby vyhovovalo omezením MySQL) a rádi bychom přiřadili databázi několikan_db1 jako níže:
Výše uvedené bude mít za následek následující výstup tabulky mysql_users v ProxySQL:
Pokud byste chtěli vytvořit zdroje MySQL mimo cPanel, můžete použít ClusterControl -> Spravovat -> Schémata a uživatelé a poté importujte uživatele databáze do ProxySQL tak, že přejdete na ClusterControl -> Nodes -> vyberte uzel ProxySQL -> Users -> Import Users .
Modul Proxysqlhook, který používáme k synchronizaci uživatelů ProxySQL, odesílá protokoly ladění do /usr/local/cpanel/logs/error_log. Použijte tento soubor ke kontrole a pochopení toho, co se děje v zákulisí. Pokud bychom nainstalovali webovou aplikaci s názvem Zikula pomocí Softaculous, v souboru protokolu cPanel by se objevily následující řádky:
[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 *****Uvidíte několik opakujících se řádků jako „Kontrola, zda {DB uživatel} existuje“, protože WHM vytváří více uživatelů/hostitelů MySQL pro každý požadavek uživatele na vytvoření databáze. V našem příkladu by WHM vytvořil tyto 3 uživatele:
ProxySQL potřebuje při přidávání uživatele pouze uživatelské jméno, heslo a výchozí informace o hostitelské skupině. Kontrolní řádky jsou zde proto, aby se zabránilo vícenásobnému vkládání přesně stejného uživatele.
Pokud byste chtěli modul upravit a provést v něm nějaká vylepšení, nezapomeňte modul znovu zaregistrovat spuštěním následujícího příkazu na serveru WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookMonitorování dotazů a ukládání do mezipaměti
S ProxySQL můžete sledovat všechny dotazy přicházející z aplikace, které prošly nebo přes ni procházejí. Standardní WHM neposkytuje tuto úroveň podrobností při monitorování dotazů MySQL. Níže jsou uvedeny všechny dotazy MySQL, které byly zachyceny ProxySQL:
S ClusterControl můžete snadno vyhledat nejčastěji se opakující dotazy a uložit je do mezipaměti pomocí funkce mezipaměti dotazů ProxySQL. Pomocí rozevíracího seznamu „Order By“ seřaďte dotazy podle „Count Star“, přejděte myší na dotaz, který chcete uložit do mezipaměti, a klikněte na tlačítko „Cache Query“ pod ním. Zobrazí se následující dialogové okno:
Výsledná sada dotazů uložených v mezipaměti bude uložena a obsluhována samotnou ProxySQL, čímž se sníží počet zásahů do backendu, které sníží zátěž vašeho replikačního clusteru MySQL jako celku. Implementace mezipaměti dotazů ProxySQL se zásadně liší od mezipaměti dotazů MySQL. Je to mezipaměť založená na čase a její platnost vyprší po uplynutí časového limitu zvaného „Cache TTL“. V této konfiguraci bychom chtěli uložit výše uvedený dotaz do mezipaměti po dobu 5 sekund (5000 ms) od zásahu do skupiny čteček, kde je cílová skupina hostitelů 20.
Rozdělení a vyvažování čtení/zápisu
Posloucháním výchozího portu MySQL 3306 se ProxySQL chová jako samotný server MySQL. Mluví s protokoly MySQL na frontendu i backendu. Pravidla dotazu definovaná ClusterControl při nastavování ProxySQL automaticky rozdělí všechna čtení (^SELECT .* v jazyce Regex) do hostitelské skupiny 20, což je skupina čtenářů, a zbytek bude předán hostitelské skupině pro zapisovače 10, jak je uvedeno v následující sekci pravidel dotazu:
S touto architekturou se nemusíte starat o rozdělení dotazů pro čtení/zápis, protože ProxySQL udělá práci za vás. Uživatelé mají minimální nebo žádné změny v kódu, což umožňuje uživatelům hostingu používat všechny aplikace a funkce poskytované WHM a cPanel nativně, podobně jako připojení k samostatnému nastavení MySQL.
Pokud jde o vyvažování připojení, pokud máte více než jeden aktivní uzel v určité hostitelské skupině (jako je v tomto příkladu čtenářská skupina 20), ProxySQL mezi ně automaticky rozloží zátěž na základě řady kritérií – váhy, zpoždění replikace, použitá připojení , celkové zatížení a latence. Je známo, že ProxySQL je velmi dobrý v prostředí s vysokou souběžností díky implementaci pokročilého mechanismu sdružování připojení. Citováno z příspěvku na blogu ProxySQL, ProxySQL neimplementuje pouze trvalé připojení, ale také multiplexování připojení. Ve skutečnosti může ProxySQL obsluhovat stovky tisíc klientů, a přesto přeposílat veškerý jejich provoz na několik připojení do backendu. ProxySQL tedy zvládne N klientských připojení a M backendových připojení, kde N> M (dokonce N tisíckrát větší než M).
Převzetí selhání a obnovení MySQL
Při správě replikačního clusteru ClusterControl se převzetí služeb při selhání provádí automaticky, pokud je povolena automatická obnova. V případě hlavního selhání:
- ClusterControl zjistí a ověří hlavní selhání prostřednictvím klienta MySQL, SSH a pingu.
- ClusterControl počká 3 sekundy, než zahájí proceduru převzetí služeb při selhání.
- ClusterControl povýší nejaktuálnějšího otroka, aby se stal dalším pánem.
- Pokud se stará předloha vrátí do režimu online, bude spuštěna pouze pro čtení, aniž by se účastnila aktivní replikace.
- Je na uživatelích, aby rozhodli, co se stane se starým vzorem. Mohl by být zaveden zpět do replikačního řetězce pomocí funkce "Rebuild Replication Slave" v ClusterControl.
- ClusterControl se pokusí provést hlavní převzetí služeb při selhání pouze jednou. Pokud selže, je nutný zásah uživatele.
Celý proces převzetí služeb při selhání můžete sledovat v části ClusterControl -> Aktivita -> Úlohy -> Převzetí při selhání do nového hlavního serveru jak je uvedeno níže:
Během převzetí služeb při selhání budou všechna připojení k databázovým serverům zařazena do fronty v ProxySQL. Budou ukončeny až po vypršení časového limitu, řízeného pomocí mysql-default_query_timeout proměnná, která je 86400000 milisekund nebo 24 hodin. Aplikace by v tomto okamžiku s největší pravděpodobností nezaznamenaly chyby nebo selhání databáze, ale kompromisem je zvýšená latence v rámci nastavitelné prahové hodnoty.
V tomto okamžiku ClusterControl představí topologii jako níže:
Pokud bychom chtěli povolit připojení starého hlavního serveru zpět do replikace poté, co bude k dispozici, museli bychom jej znovu sestavit jako slave tím, že půjdeme do ClusterControl -> Nodes -> vybrat starý hlavní server -> Rebuild Replication Slave -> vyberte nového hlavního serveru -> Pokračovat . Po dokončení přestavby byste měli získat následující topologii (upozornění 192.168.0.32 je nyní hlavní):
Konsolidace serverů a škálování databáze
S touto architekturou můžeme konsolidovat mnoho serverů MySQL, které jsou umístěny na každém serveru WHM, do jediného nastavení replikace. Můžete škálovat více databázových uzlů, jak rostete, nebo mít více replikačních clusterů pro podporu všech z nich a spravovaných jedním serverem ClusterControl. Následující schéma architektury ukazuje, zda máme dva servery WHM připojené k jednomu replikačnímu clusteru MySQL prostřednictvím souboru soketu ProxySQL:
Výše uvedené nám umožňuje oddělit dvě nejdůležitější vrstvy v našem hostingovém systému – aplikaci (front-end) a databázi (back-end). Jak možná víte, společné umístění MySQL na serveru WHM obvykle vede k vyčerpání zdrojů, protože MySQL potřebuje pro spuštění a dobrý výkon velkou předem přidělenou RAM (většinou v závislosti na innodb_buffer_pool_size proměnná). Vzhledem k tomu, že místo na disku je dostatečné, s výše uvedeným nastavením můžete mít na jednom serveru hostováno více hostingových účtů, kde všechny serverové prostředky mohou využívat aplikace front-endové vrstvy.
Škálování replikačního clusteru MySQL bude mnohem jednodušší díky architektuře samostatné vrstvy. Pokud řekněme, že master vyžaduje škálovatelnou údržbu (upgrade RAM, pevného disku, RAID, NIC), můžeme přepnout roli master na jiného slave (ClusterControl -> Nodes -> vybrat slave -> Promote Slave ) a poté proveďte úlohu údržby bez ovlivnění služby MySQL jako celku. Pro operaci škálování (přidání dalších podřízených jednotek) to můžete provést, aniž byste ovlivnili hlavní jednotku, a to provedením přípravy přímo z libovolné aktivní podřízené jednotky. Pomocí ClusterControl můžete dokonce vytvořit nového slave ze stávající zálohy MySQL (pouze kompatibilní s PITR):
Přestavba slave ze zálohy nepřinese nadřízenému další zátěž. ClusterControl zkopíruje vybraný záložní soubor ze serveru ClusterControl do cílového uzlu a tam provede obnovu. Po dokončení se uzel připojí k masteru a začne získávat všechny chybějící transakce od doby obnovení a dohánět master. Když je zpoždění, ProxySQL nezahrne uzel do sady pro vyrovnávání zátěže, dokud zpoždění replikace nebude kratší než 10 sekund (lze konfigurovat při přidávání tabulky mysql_servers přes administrátorské rozhraní ProxySQL).
Poslední myšlenky
ProxySQL rozšiřuje možnosti WHM cPanel při správě replikace MySQL. Díky ClusterControl spravujícímu váš replikační cluster jsou nyní všechny složité úkoly spojené se správou replikačního clusteru snazší než kdykoli předtím.