vshosting~

Databázové servery jsou kritickou částí infrastruktury každého webového projektu a se vzrůstající velikostí roste také jejich význam. Dříve či později se ale dostaneme do stavu, kdy výkonové požadavky na databázi nebude možné řešit pouze přidáváním další paměti a vylepšováním procesorů. Navyšování zdrojů jednoho serveru má své technické limity a časem skončíme u nutnosti rozložit zátěž do více serverů. 

Před realizací takového kroku je více než vhodné si ujasnit, čeho chceme dosáhnout. Některé modely distribuce zátěže nám pouze pomohou zvládnout vyšší množství požadavků, některé nám vyřeší i problém případné nedostupnosti jednoho ze strojů.

Škálování, vysoká dostupnost a další pojmy

Nejdříve se pojďme podívat na základní pojmy, se kterými budeme dnes operovat. Není jich mnoho, ale bez jejich znalosti se nehneme dál. Zkušení škálovači mohou tuto část s klidným svědomím přeskočit.

Škálovatelnost (scalability)

Schopnost systému (v našem případě databázového prostředí) reagovat na zvýšenou nebo sníženou potřebu zdrojů. V praxi rozeznáváme dva základní druhy škálování a to škálování vertikální a horizontální.

Při vertikálním škálování zvyšujeme prostředky, které má daná databáze k dispozici. Typicky se jedná o přidávání dostupné paměti serveru a zvyšování počtu jader. Vertikálně lze škálovat prakticky libovolnou aplikaci, dříve či později ale narazíme na hardwarové limity platformy.

Proti tomu stojí horizontální škálování, kdy výkon aplikace zvyšujeme přidáváním dalších serverů. Tímto způsobem můžeme zvyšovat výkon prakticky neomezeně, aplikace musí ale s tímto způsobem distribuce počítat.

Vysoká dostupnost (high availability)

Schopnost systému reagovat na výpadek části systému. Předpokladem pro vysokou dostupnost je schopnost provozovat aplikaci ve více instancích.

Další instance mohou být plnohodnotně zastupitelné a zpracovávat požadavky paralelně (active-active setup) nebo mohou být v režimu stand-by, kdy na sebe pouze zrcadlí data, ale nejsou schopny odbavovat provoz (active-passive setup). V případě problému je vybrána jedna z instancí v passive režimu a je převedena do active.

Master node

Řídící komponenta systému. V případě databází se jedná o instanci v režimu čtení i zápisu. Pokud máme více plnohodnotných master nodů, mluvíme o tzv. multi-master setupu.

Slave node

Záložní kopie dat. V klidovém stavu na sebe zrcadlí data a funguje v režimu pouze pro čtení. Pokud dojde k výpadku master nodu, je jeden ze slave nodů vybrán a převeden do master režimu. Po opravě původního master nodu se buď nový master vráti do stavu slave, nebo zůstává masterem a původní master je připojen jako slave node.

Asynchronní replikace

Po zápisu dat na master nodu je tento zápis potvrzen klientovi a zapsán do transakčního logu. Později v čase je tato změna replikována na slave nody. Dokud nedojde k replikaci, jsou nová nebo změněná data dostupná pouze na master nodu a v případě jeho výpadku jsou nedostupná. Asynchronní replikace je typická pro MySQL.

Synchronní replikace

Klientovi je zápis potvrzen až poté, co jsou data zapsaná na všechny nody v clusteru. Odpadá zde riziko výpadku nových dat (data jsou změněna všude nebo nikde), je ale výrazně náchylnější k problémům na síti mezi nody.

V případě síťového výpadku je výkon clusteru dočasně degradován, nebo je dokonce dočasně zastaven příjem nových požadavků na změnu dat. Tento způsob replikace se využívá v případě multi-master setupů v kombinaci s pluginem Galera.

Master – Slave replikace

Master – slave je základní podoba replikace databázového clusteru. V tomto návrhu máme jeden řídící master node, který přijímá všechny typy dotazů. Slave node (případně více nodů) na sebe zrcadlí změny pomocí asynchronní replikace. Slave nody tedy nemusí mít k dispozici nejnovější kopii dat.

Pokud dojde k výpadku master nodu, je vybrán slave s nejnovější kopií dat a ten je prohlášen za nový master. Každý slave node si ověřuje, o kolik je zpožděn oproti master nodu. Tuto hodnotu můžeme zjistit v proměnné Seconds_behind_master a je velmi důležité ji monitorovat. Vzrůstající hodnota ukazuje na problém v replikaci změn na master nodu.

Slave node funguje v režimu read-only, dokáže tedy odbavovat dotazy typu select. V tom případě mluvíme o tzv. read/write splitu, o kterém se zmíníme dále.

Master – Master replikace

Master – master setup je takový, kde máme právě dva master nody. Oba dva jsou schopni odbavovat všechny typy dotazů, mezi nimi ale probíhá asynchronní replikace. To přináší nevýhodu v případě, kdy data zapsaná na první node nemusí být okamžitě dostupná na druhém nodu. V praxi toto nastavujeme tak, že každý node je zároveň slave nodem druhého.

Tento setup se hodí v okamžiku, kdy před MySQL servery postavíme loadbalancer, který na každý stroj směřuje polovinu spojení. Každý node je ale samostatným masterem, neví nic o tom, že druhý node je taky v master režimu a je tedy nutné nastavit krok auto incrementu na 2. Pokud toto neprovedeme, bude docházet ke kolizím primárních klíčů, které využívají auto increment.

Každý z master nodů může mít u sebe další slave nody, které lze použít pro čtení dat (read/write split) a jako zálohu.

Multi – Master replikace

O multi-master setupu mluvíme v okamžiku, kdy máme v clusteru více než dva master nody. Tento setup nelze postavit v základní MySQL, ale musíme použít implementaci protokolu wsrep, např. plugin Galera.

Wsrep implementuje synchronní replikaci a tedy je velmi náchylný na problém na straně sítě a vyžaduje také časovou synchronizaci všech nodů. Umožňuje ale zasílat všechny typy dotazů na všechny nody v clusteru, takže je velmi vhodný pro řešení loadbalancingu. Nevýhodou je fakt, že všechny replikované tabulky musí používat engine innodb, tabulky využívající jiný engine nebudou replikovány.

Shardování

Shardování je dělení dat na logické segmenty. V MySQL se pro tento způsob ukládání dat používá název partitioning a prakticky znamená, že data jedné tabulky jsou rozkládány na různé servery, různé tabulky nebo různé datové soubory v rámci jednoho serveru. 

Shardování dat je vhodné v situaci, kdy máme data, která tvoří oddělené skupiny. Typickou ukázkou jsou např. historické záznamy (shardujeme podle času) nebo data uživatelů (shardy vytváříme podle ID uživatele). Díky rozkladu dat do samostatných skupin můžeme efektivně kombinovat různé druhy storage, kdy aktuální data máme na rychlých SSD discích a starší data, u kterých nepředpokládáme časté využití, ukládáme na levnější rotační disky.

Shardování se velmi často používá v NoSQL databázích, napřiklad ElasticSearch.

Read – Write splitting

V režimu Master-Slave replikace máme k dispozici výkon slave nodů, který ale nemůžeme použít pro zápisové operace. Pokud ale máme aplikaci, kde tvoří většinu dotazů pouze selecty (typicky webové projekty), můžeme jejich výkon využít pro čtení. V tomto případě tedy aplikace směřuje zápisové operace (insert, delete, update) na master node, ale selecty posílá na skupinu slave nodů.

Díky tomu, že jeden master node může mít mnoho slave nodů, pomůže nám read/write splitting se zvýšením odezvy celé aplikace pomocí rozkládání čtecích operací.

Toho chování není potřeba na straně databázového serveru nijak konfigurovat, je ale potřeba jej řešit na straně aplikace. Nejjednodušší variantou je v aplikaci udržovat dvě spojení, jedno pro zápis a druhé pro čtení. Aplikace se pak podle typu dotazu rozhoduje, jaké spojení pro daný dotaz použije.

Druhou variantou, vhodnou pro případ, kdy nejsme schopni implementovat read/write split na úrovni aplikace, je využití aplikační proxy, která rozumí dotazům a je schopna je automaticky předávat na odpovídající nody. Aplikace si drží pouze jedno spojení na proxy a nestará se o druhy dotazů. Typickým představitelem takové proxy je řešení od Maxscale. Bohužel se jedná o komerční produkt, nabízí ale verzi zdarma s omezením na tři databázové nody.

Škálujeme za vás

Nemáte kapacitu či chuť na to, spravovat si a škálovat databáze sami? Uděláme to za vás.

Postaráme se i o velmi složitý provoz a vyladění široké škály databází. Zajistíme jejich maximální stabilitu, dostupnost a škálovatelnost. Náš tým adminů spravuje desítky tisíc databázových serverů a clusterů, takže budete v rukou opravdových expertů.


Damir Špoljarič

Ř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í ;-).


Během 16 let jsme provedli úspěšnou migrací stovky klientů. Pomůžeme i vám.

  1. Domluvte se na konzultaci

    Stačí nám zanechat kontakt. Obratem se vám ozveme.

  2. Bezplatný návrh řešení

    Nezávazně probereme, jak vám můžeme pomoct. Navrhneme řešení na míru.

  3. Profesionální realizace

    Připravíme vám prostředí pro bezproblémovou migraci dle společného návrhu.

Zanechte nám svůj e-mail nebo telefon

Nebo nás kontaktujte napřímo

+420 246 035 835 V provozu 24/7
konzultace@vshosting.cz
Zkopírovat
Obratem se vám ozveme
Pouze do konce června!
PRVNÍ MĚSÍC ZDARMA JEN DO 30.6.
Nechte si na e-mail poslat slevu na Windows hosting.
Pouze do konce června!
PRVNÍ MĚSÍC ZDARMA JEN DO 30.6.
Nechte si na e-mail poslat slevu na Windows hosting se správou.
PŘIDEJTE SE K ÚSPĚŠNÝM FIRMÁM
Ušetřete si čas a napište si o nezávazný audit vašeho technického řešení zdarma.
Ušetřete si čas a napište si o nezávazný audit vašeho technického řešení zdarma.
PŘIDEJTE SE K ÚSPĚŠNÝM FIRMÁM
NÁVRH INFRASTRUKTURY ZDARMA
Nechte si od našich expertů ZCELA ZDARMA A NEZÁVAZNĚ navrhnout serverovou infrastrukturu s kompletní správou. Stačí zanechat svůj e-mail.
Nechte si od našich expertů ZCELA ZDARMA A NEZÁVAZNĚ navrhnout serverovou infrastrukturu s kompletní správou. Stačí zanechat svůj e-mail.
NÁVRH INFRASTRUKTURY ZDARMA
AKCE NA HOSTING JEN DO KONCE MĚSÍCE
Managed server na míru a o 20 % levněji! Zanechte NEZÁVAZNĚ e-mail a nepropásněte šanci na slevu.
Managed server na míru a o 20 % levněji! Zanechte NEZÁVAZNĚ e-mail a nepropásněte šanci na slevu.
AKCE NA HOSTING JEN DO KONCE MĚSÍCE
BEZPLATNÁ KONZULTACE a návrh infrastruktury
Nepropásněte šanci na konzultaci i návrh infrastruktury ZDARMA. Stačí zanechat e-mail.
Nepropásněte šanci na konzultaci i návrh infrastruktury ZDARMA. Stačí zanechat e-mail.
BEZPLATNÁ KONZULTACE a návrh infrastruktury
FREE CONSULTATION and infrastructure design
Don’t miss out on getting a consultation and infrastructure design for FREE. Just leave your email below.
Don’t miss out on getting a consultation and infrastructure design for FREE. Just leave your email below.
FREE CONSULTATION and infrastructure design
Pouze do konce června!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat slevu na Windows řešení.
Pouze do konce června!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat slevu na Windows řešení.
TENTO WEBINÁŘ JIŽ PROBĚHL

Chcete dostat zprávu o další webináři? 

Zanechte svůj e-mail.

TENTO WEBINÁŘ JIŽ PROBĚHL
AKCE NA HOSTING JEN DO KONCE MĚSÍCE
Managed server na míru a o 20 % levněji! Zanechte NEZÁVAZNĚ e-mail a nepropásněte šanci na slevu.
Managed server na míru a o 20 % levněji! Zanechte NEZÁVAZNĚ e-mail a nepropásněte šanci na slevu.
AKCE NA HOSTING JEN DO KONCE MĚSÍCE
Pouze do konce měsíce!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat slevu na Windows řešení.
Pouze do konce měsíce!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat slevu na Windows řešení.
Pouze do konce měsíce!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat poukaz na návrh Kubernetes řešení na míru.
Pouze do konce měsíce!
NENECHTE SI UTÉCT MIMOŘÁDNOU AKCI
Nechte si zcela nezávazně poslat poukaz na návrh Kubernetes řešení na míru.
Dozvěděli jste se vše, co vás zajímalo?
Pojďme se pobavit o privátním cloudu na hardwaru HPE. Stačí nám na sebe zanechat kontakt.
Zajímá Vás VMware privátní cloud na špičkovém hardwaru HPE?
Zanechte nám kontakt a můžeme se o něm pobavit více.
JAK PŘIPRAVIT E-SHOP NA VÁNOČNÍ SEZÓNU

Zveme vás na online webinář
Jak připravit e-shop na vánoční sezónu s Ondřejem Flídrem, seniorním infrastrukturním administrátorem vshostingu.

Kdy: 28. 7. 2022 v 11 hodin
Kde: Online
Za kolik: Zdarma

WEBINÁŘ
JAK PŘIPRAVIT E-SHOP NA VÁNOČNÍ SEZÓNU
WEBINÁŘ
Máme 16 let unikátního know-how. Náš tým zkušených administrátorů vám ušije řešení přesně na míru.
Windows řešení od top expertů na spravovaný hosting
Máme 16 let unikátního know-how. Náš tým zkušených administrátorů vám ušije řešení přesně na míru.
Windows řešení od top expertů na spravovaný hosting
Jsme největší experti na managed služby na trhu
Ušetřete si čas, napište si o nezávazný audit vašeho technického řešení zdarma nebo se jen s námi pobavte o možnostech.
Ušetřete si čas, napište si o nezávazný audit vašeho technického řešení zdarma nebo se jen s námi pobavte o možnostech.
Jsme největší experti na managed služby na trhu