ProxySQL je vyhrazený nástroj pro vyrovnávání zatížení pro MySQL, který přichází s řadou funkcí, včetně, ale bez omezení, přesměrování dotazů, ukládání dotazů do mezipaměti nebo tvarování provozu. Lze jej použít ke snadnému nastavení rozdělení čtení a zápisu a přesměrování dotazů do samostatných backendových uzlů. V důsledku toho poskytuje mnoho přesvědčivých důvodů k použití. Na druhou stranu, HAProxy je skvělý nástroj pro vyrovnávání zátěže, ale není určen pro databáze a i když jej lze použít, nelze jej ve skutečnosti srovnávat s ProxySQL. To může být důvod, proč se prostředí, která stále spoléhají na HAProxy, snaží migrovat na ProxySQL.
V tomto krátkém příspěvku na blogu se podělíme o několik návrhů týkajících se procesu migrace.
Plánování upgradu
To je do značné míry zřejmé a mělo by to být bez otázek, přesto bychom to rádi měli písemně. Naplánujte si upgrade. Ujistěte se, že jste obeznámeni s procesem, že jste vše důkladně otestovali. Nastavte testovací prostředí, ve kterém můžete ověřit různé přístupy k upgradu a rozhodnout se, který by pro vás fungoval nejlépe.
Pokud uvažujete o jeho použití, otestujte rozdělení čtení/zápisu v ProxySQL
V závislosti na vašich požadavcích můžete zvážit použití rozdělení pro čtení/zápis v ProxySQL. To je pravděpodobně jeden z nejpřesvědčivějších důvodů pro upgrade. Místo toho, abyste to implementovali na straně aplikace (nebo to neimplementovali vůbec, pokud to nemůžete provést v aplikaci), můžete se spolehnout na to, že ProxySQL provede rozdělení čtení/zápisu za vás. Nastavení je velmi snadné, zvláště pokud nasadíte ProxySQL pomocí ClusterControl – děje se to v podstatě automaticky.
Pokud nepoužíváte implicitní transakce, ClusterControl nastaví rozdělení pro čtení/zápis za vás pomocí sady pravidel dotazu:
I když je implementace rozdělení čtení/zápisu velmi jednoduchá, měli byste buďte opatrní, když to plánujete. Aplikace se mohou spoléhat na některé funkce, které v ProxySQL opravdu nefungují. Ve většině případů vám další konfigurace umožní těžit z této funkce, ale během testovací fáze je velmi důležité zjistit, zda vaše aplikace bude fungovat, nebo zda potřebujete přidat nějakou vlastní konfiguraci. Obzvláště ošemetné části jsou problémy se čtením po zápisu – v takovém případě možná budete muset překonfigurovat ProxySQL, abyste zakázali multiplexování připojení pro některé dotazy.
Zapomeňte na konfigurační soubor v ProxySQL
Toto je jedna z věcí, která je pro nové uživatele ProxySQL překvapením. Ve skutečnosti nepoužívá konfigurační soubory. Jeden existuje, ano, ale v podstatě funguje jako způsob, jak zavést ProxySQL během prvního spuštění. ProxySQL používá databázi SQLite, která obsahuje její konfiguraci a správný způsob provádění jakýchkoli změn konfigurace je prostřednictvím klienta MySQL připojeného k administrativnímu portu ProxySQL. Odtud můžete provádět změny konfigurace za běhu, v podstatě bez nutnosti restartovat ProxySQL.
Rozhraní ClusterControl UI samozřejmě také umožňuje překonfigurovat ProxySQL:
Vzory nasazení ProxySQL
Existují dva hlavní způsoby, jak chcete nasadit ProxySQL. K nasazení ProxySQL na:
můžete buď použít dedikované servery
Nebo můžete ProxySQL spojit s aplikačními servery:
To umožňuje vaší aplikaci připojit se k místní instanci ProxySQL pomocí Unixového soketu, který je z hlediska výkonu lepší než použití vzdáleného připojení TCP. Také to zjednodušuje nastavení – není potřeba implementovat Keepalived nebo jiného poskytovatele virtuální IP adresy pro vyvážení zátěže napříč instancemi ProxySQL. Aplikace se připojuje pouze k místnímu ProxySQL a to je skoro vše.
Použití clusterů ProxySQL pro větší nasazení
Ujistit se, že vaše instance ProxySQL obsahují stále stejnou konfiguraci, může být náročné, zvláště pokud je jejich počet velký. Existuje mnoho způsobů, jak se s takovými výzvami vypořádat – Ansible/Chef/Puppet, shell skripty a tak dále. Doporučujeme spolehnout se na vestavěné řešení - ProxySQL Cluster. Pomocí několika změn konfigurace můžete nakonfigurovat uzly ProxySQL tak, aby vytvořily cluster, kde se změna konfigurace na jednom z uzlů rozšíří mezi všechny členy clusteru.
Tinker s SO_REUSEPORT pro elegantní přepínání zátěže
Jednou z náročnějších částí může být zajištění toho, že přepnete provoz z HAProxy na ProxySQL způsobem, který minimalizuje dopad na aplikaci. Obvykle byste museli změnit alespoň jedno nastavení – název hostitele nebo port, ke kterému se má aplikace připojit. V závislosti na vašem prostředí to nemusí být ideální, zvláště pokud je konfigurace připojení k databázi zabudována v aplikaci. Do značné míry by to vyžadovalo provést změnu v základně kódu a vložit do výroby nový kód. Není to největší nabídka, ale můžete to udělat lépe.
Zajímavou částí je, že jak ProxySQL, tak nejnovější verze HAProxy (od 1.8) jsou schopny využívat SO_REUSEPORT. Tato možnost soketu je dostupná v Linuxu počínaje jádrem 3.9 a umožňuje více procesům sdílet stejný port. ProxySQL jej může použít pro elegantní upgrady mezi verzemi ProxySQL, HAProxy jej používá k opětovnému načtení konfigurace bez jakéhokoli dopadu na aplikaci. Zajímavé je, že je možné nakonfigurovat ProxySQL tak, aby sdílel port s HAProxy pro bezproblémovou migraci mezi těmito dvěma nástroji pro vyrovnávání zatížení.
Při pokusu o to musíte vzít v úvahu několik věcí - za prvé, ProxySQL tuto možnost ve výchozím nastavení nepoužívá, musíte do ProxySQL při spuštění přidat příznak -r. Můžete to udělat úpravou souboru ProxySQL systemd unit:
[email protected]:~# systemctl edit proxysql --fulla změnou direktivy ExecStart na:
ExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rDalším omezením, kterého byste si měli být vědomi v Linuxu, je to, že port mohou sdílet pouze procesy spuštěné stejným ID uživatele. To bude znamenat, že budete muset překonfigurovat ProxySQL, aby se spouštěl jako „haproxy“ uživatel.
Jako obvykle můžete chtít spustit testy, než se pokusíte provést tuto operaci v produkčním prostředí. Tento výkon je určitě možné provést, ale měli byste být opatrní a zkontrolovat, zda to nebude mít dopad na vaši produkci kvůli nějaké nestandardní konfiguraci související s vaším prostředím.
Doufáme, že tento krátký blog vám poskytne nějaký pohled na proces migrace z HAProxy na ProxySQL. Pro backendy databáze bude tato změna velmi přínosná, i když přípravná část může být časově náročná. Pokud projdete řádným testováním, konečná migrace by měla být poměrně jednoduchá a bezpečná.