Streaming Replication je nová funkce, která byla představena ve verzi 4.0 Galera Cluster. Galera používá replikaci synchronně v celém clusteru, ale před tímto vydáním nebyly zápisové sady větší než 2 GB podporovány. Streaming Replication vám nyní umožňuje replikovat velké zápisové sady, což je ideální pro hromadné vkládání nebo načítání dat do vaší databáze.
V předchozím blogu jsme psali o zpracování velkých transakcí pomocí replikace streamování a MariaDB 10.4, ale v době psaní tohoto blogu Codership ještě nevydal svou verzi nového clusteru Galera. Percona však vydala svou experimentální binární verzi Percona XtraDB Cluster 8.0, která zdůrazňuje následující funkce...
-
Streamovací replikace podporující velké transakce
-
Funkce synchronizace umožňují koordinaci akcí (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Jemnější a vylepšené protokolování chyb. wsrep_debug je nyní vícehodnotová proměnná, která pomáhá při řízení protokolování a protokolování zpráv bylo výrazně vylepšeno.
-
Některé chyby DML a DDL na replikujícím se uzlu lze ignorovat nebo potlačit. Ke konfiguraci použijte proměnnou wsrep_ignore_apply_errors.
-
Vícenásobné systémové tabulky pomáhají zjistit více o stavu klastru.
-
Infrastruktura wsrep Galery 4 je robustnější než infrastruktura Galery 3. Vyznačuje se rychlejším prováděním kódu s lepším zpracováním stavu, vylepšenou předvídatelností a zpracováním chyb.
Co je nového v Galera Cluster 4.0?
Nová funkce replikace streamování
Díky Streaming Replication se transakce replikují postupně v malých fragmentech během zpracování transakce (tj. před skutečným potvrzením replikujeme řadu malých fragmentů). Replikované fragmenty se pak použijí v podřízených vláknech, přičemž se zachová stav transakce ve všech uzlech clusteru. Fragmenty drží zámky ve všech uzlech a nemohou být později konfliktní.
Galera SystemTables
Správci databáze a klienti s přístupem k databázi MySQL mohou tyto tabulky číst, ale nemohou je upravovat, protože potřebné úpravy provede samotná databáze. Pokud váš server tyto tabulky nemá, je možné, že váš server používá starší verzi Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Nové funkce synchronizace
Tato verze zavádí řadu funkcí SQL pro použití v operacích synchronizace wsrep. Můžete je použít k získání globálního ID transakce, které je založeno buď na posledním zápisu nebo na poslední zaznamenané transakci. Můžete také nastavit uzel tak, aby před zahájením další transakce počkal na replikaci a použití konkrétního GTID.
Inteligentní výběr dárců
Některé podhodnocené funkce, které jsou k dispozici od Galery 3.x, zahrnují inteligentní výběr dárců a obnovu po havárii clusteru. Ty byly původně plánovány pro Galera 4, ale dostaly se do dřívějších verzí z velké části kvůli požadavkům zákazníků. Pokud jde o výběr dárcovského uzlu v Galeře 3, dárce State Snapshot Transfer (SST) byl vybrán náhodně. S Galera 4 však získáte mnohem inteligentnější volbu, pokud jde o výběr dárce, protože upřednostní dárce, který může poskytnout přírůstkový státní převod (IST) nebo vybrat dárce ve stejném segmentu. Jako správce databáze to můžete vynutit nastavením wsrep_sst_donor.
Proč používat MySQL Galera Cluster Streaming Replication?
Dlouhotrvající transakce
Problémy a omezení Galery se vždy točily kolem toho, jak zpracovávala dlouhotrvající transakce a často způsobily zpomalení celého clusteru kvůli replikaci velkých zápisových sad. Jeho řízení toku je často vysoké, což způsobuje zpomalení zápisu nebo dokonce ukončení procesu, aby se cluster vrátil zpět do normálního stavu. Toto je docela běžný problém u předchozích verzí Galera Cluster.
Codership doporučuje používat pro vaše dlouhotrvající transakce streamovací replikaci ke zmírnění těchto situací. Jakmile uzel replikuje a certifikuje fragment, není již možné, aby jej jiné transakce přerušily.
Velké transakce
Toto je velmi užitečné při načítání dat do přehledu nebo analýzy. Do této kategorie může spadat vytváření hromadného vkládání, odstraňování, aktualizace nebo použití příkazu LOAD DATA k načtení velkého množství dat. I když to závisí na tom, jak spravujete svá data pro získávání nebo ukládání. Musíte vzít v úvahu, že replikace datových proudů má svá omezení, takže certifikační klíče jsou generovány ze zámků záznamů.
Bez Streaming Replication by aktualizace velkého počtu záznamů vedla ke konfliktu a celá transakce by musela být vrácena zpět. Podřízené jednotky, které také replikují velké transakce, podléhají řízení toku, jakmile dosáhne prahové hodnoty a začne zpomalovat celý cluster, aby zpracoval jakékoli zápisy, protože mají tendenci uvolňovat příjem příchozích transakcí ze synchronní replikace. Galera uvolní replikaci, dokud nebude zapisovací sada zvládnutelná, protože umožní znovu pokračovat v replikaci. Podívejte se na tento externí blog Percona, který vám pomůže porozumět více o řízení toku v Galera.
S replikací streamování začne uzel replikovat data s každým fragmentem transakce, místo aby čekal na potvrzení. To znamená, že neexistuje způsob, jak přerušit jakékoli konfliktní transakce probíhající v ostatních uzlech, protože to jednoduše potvrzuje, že klastr certifikoval sadu zápisu pro tento konkrétní fragment. Je zdarma aplikovat a zadávat další souběžné transakce bez blokování a zpracování velkých transakcí s minimálním dopadem na cluster.
Žhavé záznamy/Žhavá místa
Žhavé záznamy nebo řádky jsou řádky v tabulce, které se neustále aktualizují. Tato data mohou být nejnavštěvovanější a vysoce získávají návštěvnost celé vaší databáze (např. zpravodajské kanály, počítadlo, jako je počet návštěv nebo protokoly). Pomocí Streaming Replication můžete vynutit kritické aktualizace celého clusteru.
Jak poznamenal tým Galera v Codership
„Spuštění transakce tímto způsobem efektivně uzamkne horký záznam na všech uzlech a zabrání ostatním transakcím v úpravě řádku. Zvyšuje to také šance, že transakce bude úspěšně uzavřena a že klient na oplátku obdrží požadovaný výsledek.“
To přichází s omezeními, protože nemusí být trvalé a konzistentní, že budete mít úspěšné odevzdání. Bez použití Streaming Replication skončíte s vysokou pravděpodobností nebo vrácením zpět, což by mohlo zvýšit režii pro koncového uživatele, když dojde k tomuto problému z pohledu aplikace.
Co je třeba zvážit při používání replikace streamování
- Certifikační klíče jsou generovány ze zámků záznamů, proto nezakrývají zámky s mezerami ani zámky s dalšími klíči. Pokud se transakce zablokuje, je možné, že transakce, která je provedena na jiném uzlu, použije sadu zápisu, která narazí na protokol mezer a přeruší streamování transakce.
- Při povolení streamování replikace se protokoly zapisovací sady zapisují do tabulky wsrep_streaming_log nalezené v systémové databázi mysql, aby se zachovala perzistence v případě selhání, takže tato tabulka slouží při obnově. V případě nadměrného protokolování a zvýšené režie replikace způsobí streamingová replikace sníženou propustnost transakcí. To by mohlo být překážkou výkonu při dosažení vysokého špičkového zatížení. Proto se doporučuje povolit replikaci streamování pouze na úrovni relace a poté pouze pro transakce, které by bez ní nefungovaly správně.
- Nejlepším případem použití je použití streamingové replikace pro omezení velkých transakcí
- Nastavte velikost fragmentu na ~10 000 řádků
- Proměnné fragmentů jsou proměnné relace a lze je dynamicky nastavit
- Inteligentní aplikace může zapnout/vypnout replikaci streamování podle potřeby
Závěr
Děkujeme za přečtení, ve druhé části probereme, jak aktivovat Galera Cluster Streaming Replication a jak by mohly vypadat výsledky pro vaše nastavení.