V jednom z předchozích blogů jsme se zabývali novými funkcemi, které vycházejí v MariaDB 10.4. Zmínili jsme tam, že součástí této verze bude nové vydání Galera Cluster. V tomto příspěvku na blogu si projdeme funkce Galera Cluster 26.4.0 (nebo Galera 4), rychle se na ně podíváme a prozkoumáme, jak ovlivní vaše nastavení při práci s MariaDB Galera Cluster.
Streamování replikace
Galera Cluster v žádném případě nenahrazuje samostatný MySQL. Způsob, jakým funguje certifikace sady zápisů, přinesl několik omezení a okrajových případů, které mohou vážně omezit možnost migrace do Galera Cluster. Tři nejběžnější omezení jsou...
- Problémy s dlouhými transakcemi
- Problémy s velkými transakcemi
- Problémy s aktivními body v tabulkách
Je skvělé vidět, že Galera 4 zavádí replikaci streamování, která může pomoci snížit tato omezení. Pojďme se na současný stav podívat trochu podrobněji.
Dlouho běžící transakce
V tomto případě mluvíme o čase, který je v Galeře rozhodně problematický. Hlavní věc, kterou je třeba pochopit, je, že Galera replikuje transakce jako sady zápisů. Tyto sady zápisů jsou certifikovány na členech klastru, což zajišťuje, že všechny uzly mohou použít danou sadu zápisů. Problém je v tom, že zámky jsou vytvářeny na místním uzlu, nejsou replikovány v celém clusteru, takže pokud dokončení vaší transakce trvá několik minut a pokud zapisujete do více než jednoho uzlu Galera, je časem stále pravděpodobnější, že na jeden ze zbývajících uzlů některé transakce upraví některé řádky aktualizované ve vaší dlouhotrvající transakci. To způsobí selhání certifikace a dlouhotrvající transakce bude muset být vrácena zpět. Stručně řečeno, pokud odesíláte zápisy do více než jednoho uzlu v clusteru, čím delší je transakce, tím je pravděpodobnější, že certifikace kvůli nějakému konfliktu selže.
Hotspoty
Tím máme na mysli řádky, které jsou často aktualizovány. Obvykle se jedná o jakési počítadlo, které se znovu a znovu aktualizuje. Viník problému je stejný jako u dlouhých transakcí – řádky jsou uzamčeny pouze lokálně. Opět platí, že pokud odesíláte zápisy do více než jednoho uzlu, je pravděpodobné, že stejné počítadlo bude upraveno současně na více než jednom uzlu, což způsobí konflikty a způsobí selhání certifikace.
Pro oba tyto problémy existuje jedno řešení – můžete své zápisy posílat pouze do jednoho uzlu místo toho, abyste je distribuovali přes celý cluster. K tomu můžete použít proxy - ClusterControl nasazuje HAProxy a ProxySQL, obě lze nakonfigurovat tak, aby se zápisy posílaly pouze do jednoho uzlu. Pokud nemůžete posílat zápisy pouze do jednoho uzlu, musíte se smířit s tím, že čas od času zaznamenáte konflikty certifikace a vrácení zpět. Obecně platí, že aplikace musí umět zvládat návraty z databáze – to nelze obejít, ale ještě důležitější je, když aplikace pracuje s Galera Cluster.
Přesto odeslání provozu do jednoho uzlu nestačí k vyřešení třetího problému.
Velké transakce
Je důležité mít na paměti, že sada zápisů je odeslána k certifikaci až po dokončení transakce. Poté je sada zápisů odeslána všem uzlům a proběhne proces certifikace. To způsobuje omezení toho, jak velká může být jednotlivá transakce, protože Galera ji při přípravě zápisové sady ukládá do vyrovnávací paměti v paměti. Příliš velké transakce sníží výkon clusteru. Proto byly zavedeny dvě proměnné:wsrep_max_ws_rows, která omezuje počet řádků na transakci (ačkoli může být nastavena na 0 - neomezeně) a co je důležitější:wsrep_max_ws_size, kterou lze nastavit až na 2 GB. Největší transakce, kterou můžete s Galera Cluster provést, má tedy velikost až 2 GB. Také musíte mít na paměti, že certifikace a použití velké transakce také zabere čas, což způsobí „prodlevu“ – čtení po zápisu, který zasáhl uzel jiný, než kde jste transakci původně provedli, s největší pravděpodobností povede k nesprávným údajům, protože transakce se stále provádí.
Galera 4 přichází s replikací streamování, kterou lze použít ke zmírnění všech těchto problémů. Hlavním rozdílem bude, že sadu zápisů lze nyní rozdělit na části – již nebude nutné čekat na dokončení celé transakce, než budou data replikována. Možná vás napadne, jak v takovém případě vypadá certifikace? Stručně řečeno, certifikace je za běhu – každý fragment je certifikován a všechny zúčastněné řádky jsou uzamčeny na všech uzlech v clusteru. Toto je vážná změna v tom, jak Galera funguje – až dosud byly zámky vytvářeny lokálně, zámky streamované replikace budou vytvořeny na všech uzlech. To pomáhá v případech, které jsme probrali výše – zamykání řádků při příchodu fragmentů transakce pomáhá snížit pravděpodobnost, že transakce bude muset být vrácena zpět. Konfliktní transakce prováděné lokálně nebudou moci získat zámky, které potřebují, a budou muset počkat na dokončení replikující transakce a uvolnění zámků řádků.
V případě hotspotů je pomocí streamingové replikace možné získat zámky na všech uzlech při aktualizaci řádku. Ostatní dotazy, které chtějí aktualizovat stejný řádek, budou muset před provedením změn počkat na uvolnění zámku.
Velké transakce budou těžit ze streamingové replikace, protože již nebude nutné čekat na dokončení celé transakce ani nebudou omezeny velikostí transakce – velké transakce budou rozděleny na fragmenty. Pomáhá to také lépe využívat síť – namísto odesílání 2 GB dat najednou lze stejné 2 GB dat rozdělit na fragmenty a odesílat po delší časové období.
Existují dvě možnosti konfigurace pro streamingovou replikaci:wsrep_trx_fragment_size, která říká, jak velký by měl být fragment (ve výchozím nastavení je nastavena na 0, což znamená, že streamingová replikace je zakázána) a wsrep_trx_fragment_unit, která říká, jaký fragment skutečně je. Ve výchozím nastavení jsou to bajty, ale může to být také „příkazy“ nebo „řádky“. Tyto proměnné mohou (a měly by být) nastaveny na úrovni relace, což uživateli umožňuje rozhodnout, který konkrétní dotaz by měl být replikován pomocí streamingové replikace. Nastavení jednotky na ‚příkazy‘ a velikost na 1 umožňuje například použít streamovací replikaci pouze pro jeden dotaz, který například aktualizuje hotspot.
Samozřejmě existují nevýhody spouštění replikace datových proudů, zejména kvůli skutečnosti, že zámky jsou nyní přijímány na všech uzlech v clusteru. Pokud jste viděli, jak se velká transakce po věky vrací zpět, nyní se taková transakce bude muset vrátit zpět na všechny uzly. Je zřejmé, že osvědčeným postupem je co nejvíce zmenšit velikost transakce, aby se předešlo opakování, které trvá hodiny. Další nevýhodou je, že z důvodů obnovy po havárii jsou sady zápisů vytvořené z každého fragmentu uloženy v tabulce wsrep_schema.SR na všech uzlech, což svým způsobem implementuje vyrovnávací paměť pro dvojitý zápis, což zvyšuje zatížení clusteru. Proto byste se měli pečlivě rozhodnout, která transakce by měla být replikována pomocí streamingové replikace, a pokud je to možné, měli byste se stále držet osvědčených postupů malých, krátkých transakcí nebo rozdělení velkých transakcí do menších dávek.
Zálohovací zámky
A konečně, uživatelé MariaDB budou moci těžit ze záložních zámků pro SST. Myšlenka SST prováděná pomocí (pro MariaDB) mariabackup spočívá v tom, že celá datová sada musí být přenesena za běhu, přičemž se na pozadí shromažďují nové protokoly. Poté je třeba získat globální zámek, který zajistí, že nedojde k žádnému zápisu, je třeba shromáždit a uložit konečnou polohu redo logu. Historicky se pro MariaDB uzamykací část prováděla pomocí FLUSH TABLES WITH READ LOCK, které splnily svou práci, ale při velkém zatížení bylo docela těžké je získat. Je to také docela těžké - nejen transakce musí čekat na uvolnění zámku, ale také musí být data vyprázdněna na disk. Nyní s MariaDB 10.4 bude možné používat méně rušivý BACKUP LOCK, který nebude vyžadovat vyprázdnění dat, pouze budou po dobu uzamčení zablokovány commity. To by mělo znamenat méně rušivé operace SST, což je rozhodně skvělé slyšet. Každý, kdo musel spouštět svůj Galera Cluster v nouzovém režimu na jednom uzlu a držel palce, aby SST neovlivnil provoz clusteru, by měl být o tomto vylepšení více než šťastný.
Kauzální čtení z aplikace
Galera 4 představila tři nové funkce, které mají pomoci přidat podporu pro kauzální čtení v aplikacích - WSREP_LAST_WRITTEN_GTID(), která vrací GTID posledního zápisu provedeného klientem, WSREP_LAST_SEEN_GTID(), která vrací GTID poslední pozorované transakce zápisu. klientem a WSREP_SYNC_WAIT_UPTO_GTID(), která zablokuje klienta, dokud nebude GTID předané funkci potvrzeno na uzlu. Jistě, kauzální čtení můžete v Galeře vynutit i nyní, ale s využitím těchto funkcí bude možné implementovat bezpečné čtení po zápisu v těch částech aplikace, kde je to potřeba, aniž byste museli provádět změny v konfiguraci Galery.
Upgrade na MariaDB Galera 10.4
Pokud byste chtěli vyzkoušet Galera 4, je k dispozici v nejnovějším kandidátovi na vydání pro MariaDB 10.4. Podle dokumentace MariaDB v tuto chvíli neexistuje způsob, jak provést živý upgrade z 10.3 Galera na 10.4. Musíte zastavit celý cluster 10.3, upgradovat jej na 10.4 a poté jej znovu spustit. Toto je vážný blokátor a doufáme, že toto omezení bude v jedné z příštích verzí odstraněno. Je nanejvýš důležité mít možnost živého upgradu, a proto budou muset MariaDB 10.3 a MariaDB 10.4 koexistovat ve stejném clusteru Galera. Další možností, která může být také vhodná, je nastavení asynchronní replikace mezi starým a novým Galera Clusterem.
Opravdu doufáme, že se vám tato krátká recenze funkcí MariaDB 10.4 Galera Cluster líbila, těšíme se na replikaci streamování ve skutečných živých produkčních prostředích. Doufáme také, že tyto změny pomohou ještě více zvýšit adopci Galery. Koneckonců, streamingová replikace řeší mnoho problémů, které mohou lidem bránit v migraci do Galery.