přejít na obsah přejít na navigaci

Linux E X P R E S, Jak si ulehčit přechod do synchronního MariaDB clusteru?

Veeam

Jak si ulehčit přechod do synchronního MariaDB clusteru?

Mariadb_maxscale100.png

Ř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í. Pro zjednodušení části komplikací s přechodem do clusteru existuje nástroj zvaný MaxScale, na který se dnes podíváme. 


reklama

Využití Maxscale při přechodu ze single node mysql na 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ěžné 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ř. Read-only pro rychlé čtení informací, read-write-split 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 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šťuje komunikaci mezi klienty a MaxScale a zároveň 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í.

Blog_Post-Business_Scalability.png

Základní funkce MaxScale

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.

Č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ů.

Damir-Spoljaric.jpg

Damir Špoljarič

Autor článku je CEO a zakladatel společnosti VSHosting, která provozuje datacentrum ServerPark a má s provozem náročných databázových clusterů mnoho zkušeností. Na galera clusteru provozuje například Shoptet, což je platforma pro více než 10.000 eshopů.

Ilustrační obrázky jsou převzaty ze serverů mariadb.com a mariadb.org.





Nahoru

Odkazy

(Jako ve škole)
Průměr: 1,00 | Hodnotilo: 1
 

Top články z OpenOffice.cz

Příspěvky

Jak si ulehčit přechod do synchronního MariaDB clusteru?
NULL 5. 10. 2017, 12:08:23
Odpovědět  Odkaz 
Dobrý den,

díky za článek. Chtěl bych se zeptat, jak se dá takový MaxScale skloubit s třeba již existující rest API před MariaDb. Tedy jestli se to dá nějak vhodně zkombinovat, nebo zda lze přímo MaxScale rozšířit?

Děkuji

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

externí