Jak si ulehčit přechod do synchronního MariaDB clusteru (Galera)

Řada velkých projektů, které využívají MySQL/MariaDB se již setkala s tím, že jim jednoduše nestačí provozovat jeden server či “hloupou” asynchronní master-slave repliku a že pro nutnost pohodlného horizontálního škálování musí připravit svoji aplikaci pro provoz databáze v MariaDB galera clusteru. To bohužel přináší poměrně zásadní předělání architektury aplikace, aby se vše přizpůsobilo vlastnostem clusteru, eliminovalo se riziko vzniku dead-locků a jiných komplikací.

vshosting~, jakožto největší Managed Services provider ve Střední Evropě, má s provozem náročných databázových clusterů mnoho zkušeností. Provozujeme v managed režimu na Galera clusteru například Shoptet, což je platformě pro více než 10.000 eshopů.

Pro zjednodušení části komplikací s přechodem do clusteru existuje nástroj zvaný MaxScale, na který se dnes podíváme.

Využití MaxScale při přechodu ze single node MySQL na MariaDB (Galera) cluster

Při přechodu z jednoinstanční mysql na cluster je obvykle nutné provádět aplikační změny, protože bězné balancování provozu přes tcp toho mnoho neumožňuje. Při takovém typu nasazení se pak obvykle stává, že se provádí transakční zápisové operace na více nodech nebo se čtou data z nodů, kam se ještě nestačila synchronizovat.

Potom je nutné vytvářet různé připojovací konektory do clusteru podle typu prováděné operace, případně upravit vlastnosti clusteru tak, aby na sebe nody vzájemně čekaly. To pak výkon clusteru snižuje. Při nasazení MaxScale se sloučí výhody tcp balancingu s přidanou logikou. Nejsou tedy nutné úpravy aplikace a provoz se směruje na jeden db konektor.

Pokud je cílem maximálně využít cluster, co se týká výpočetní kapacity a nenechat ho jen ve stavu vysoké dostupnosti, je možné vytvořit několik db konektorů podle typu použití např. Readonly pro rychlé čtení informací, readwritesplit pro automatické směrování zápisových operací a query caching pro dotazy, které se často opakují. To všechno pro dosažení maximálního výkonu clusteru.

Základní popis MariaDB MaxScale

MariaDB MaxScale je databázový proxy server, který rozšiřuje vysokou dostupnost, škálovatelnost a bezpečnost serveru MariaDB a současně zjednodušuje vývoj aplikací tím, že jej oddělí od základní databázové infrastruktury.

Zjednodušeně řečeno je to databázová proxy, která předává query do databáze na jeden nebo více databázových serverů.

MaxScale je navržen s rozšiřitelnou architekturou, která podporuje pluginy a rozšiřuje svou funkci nad transparentní vyvažování zátěže, aby se stala například databázovým firewallem. S vestavěnými pluginy pro více směrovačů, filtrů a protokolů může být služba MaxScale konfigurována tak, aby předala žádosti o databázi a upravovala odezvy databáze na základě předem definovaných požadavků – například k maskování citlivých dat apod.

Přesměrování se provádí pomocí pravidel, založených na sémantickém pochopení databázových query a rolích serverů v rámci clusteru databází.

MaxScale využívá rozsáhlé možnosti asynchronního I/O operačního systému Linux v kombinaci s pevným počtem pracovních podprocesů. Epoll se používá k zajištění události řízeného rámce pro vstup a výstup přes sockety.

Služby poskytované MaxScale jsou implementovány jako externí, sdílené, objektové moduly načítané za běhu. Běžně používané typy modulů jsou protokol, směrovač a filtr. Modul protokolu zajištuje komunikaci mezi klienty a MaxScale a zároven mezi MaxScale a backendy. Směrovač kontroluje dotazy od klientů a rozhoduje o cílovém backendu. Rozhodnutí jsou obvykle založena na pravidlech směrování a na stavu backendů. Filtry poté pracují s daty, které přes MaxScale procházejí.

Základní funkce

Firewall

MaxScale obsahuje filtr brány firewall pro blokování dotazů na základě pravidel nakonfigurovaných například na základě typu příkazu, použitých funkcí, vybraných sloupců nebo frekvence dotazů. MariaDB MaxScale 2.1 rozšiřuje filtrování na připravené příkazy.

Denial of service protection

MaxScale používá plugin omezující sadu výsledků query, aby se zabránilo dotazům, předpřipraveným příkazům a uloženým procedurám způsobit výpadek služby, vrácením příliš velkého množství dat. Maximální velikost sady výsledků query lze nakonfigurovat v řádcích nebo bajtech.

Read-Write Split

MaxScale obsahuje směrovač, který rozděluje čtení a zápis, když je sql server nakonfigurován jako multi-master (galera cluster) nebo master/slave (replika). Zápisy jsou poté prováděny jediným hlavním uzlem a čtení jsou prováděna na všech slavech – a to lze provést bez úpravy aplikace.

Change-data-capture

MariaDB MaxScale obsahuje protokol pro změnu dat, který v kombinaci s routerem Avro čte události binárního logu a přenáší je do klientů, kde mohou být data interpretována jako objekty Avro nebo JSON dokumenty.

Data masking

MaxScale používá filtr na maskování dat, který chrání citlivá data kontrolou výsledků dotazu a zmatením dat v určitých sloupcích na základě nakonfigurovaných pravidel. Při kombinaci s filtrem brány firewall databáze lze omezit přístup k citlivým datům.

Bulk insert streaming

MaxScale používá filtr pro hromadné vkládání insertů a přeměňuje všechny inserty v rámci explicitní transakce na jeden datový tok CSV pro přímé načítání s větší účinností, zlepšení výkonu a snížení síťového provozu.

Schema-based sharding

MaxScale obsahuje směrovač schémat pro podporu vícenásobného prostředí, kde každé spojení má vlastní schéma a schémata mohou být v různých databázích nebo vytvořit jednotnou logickou databázi z více fyzických databází – vše transparentní pro aplikaci.

Query caching

MaxScale používá filtr pro ukládání dotazů do mezipaměti, který zlepšuje výkon opakovaných dotazů a zároveň snižuje pracovní zatížení na podkladové databázi v závislosti na nastavených pravidlech – doba trvání, maximální počet řádků / velikost souborů, maximální počet záznamů apod.

Známá omezení / limity

Syntaktický analyzátor MaxScale správně analyzuje příkazy WITH, ale nedokáže shromáždit sloupce, funkce a tabulky používané v SELECTu definující klauzuli WITH.
V důsledku toho databázový firewall neblokuje příkazy WITH, kde SELECT klauzule WITH odkazuje na zakázané sloupce.

Transakce XA nejsou zjištěny jako transakce MaxScale. To znamená, že všechny příkazy XA budou považovány za neznámé příkazy a budou považovány za operace, které potenciálně změní databázi (v případě readwritesplit jsou příkazy směrovány do masteru).

MaxScale nebude sledovat stav transakce XA, což znamená, že všechny dotazy SELECT prováděné uvnitř transakce XA mohou být směrovány na servery, které nejsou součástí transakce XA.
Tomuto omezení lze na straně klienta zabránit vypnutím automatického vypnutí před provedením všech transakcí XA.

U filtrů není zaručeno, že obdrží kompletní pakety MySQL, pokud jsou použity s readconnroute směrovačem. To lze opravit pouze pomocí směrovače readwritesplit.

ReadWriteSplit

Čtení dotazů je směrováno na hlavní server I v následujících situacích:

* dotaz je spuštěn uvnitř otevřené transakce
* dotaz je připravené prohlášení
* příkaz obsahuje uloženou proceduru nebo volání UDF
* pokud je uvnitř jednoho dotazu několik příkazů.

Věříme, že se vám náš dnešní článek líbil a chystáme pro vás řadu dalších odborných zajímavostí ;-).