Dříve jsme blogovali o Co je nového v MySQL Galera Cluster 4.0, Zvládání velkých transakcí pomocí Streaming Replication a MariaDB 10.4 a představili jsme několik průvodců o používání nové funkce Streaming Replication v 1. a 2. díle.
Přesun vaší databázové technologie z replikace MySQL na MySQL Galera Cluster vyžaduje, abyste měli správné dovednosti a rozuměli tomu, co děláte, abyste byli úspěšní. V tomto blogu se podělíme o několik tipů pro migraci z nastavení replikace MySQL na MySQL Galera Cluster 4.0.
Rozdíly mezi replikací MySQL a Galera Cluster
Pokud ještě neznáte Galera, doporučujeme vám projít si náš výukový program Galera Cluster for MySQL. Galera Cluster používá zcela jinou úroveň replikace založenou na synchronní replikaci, na rozdíl od replikace MySQL, která používá asynchronní replikaci (ale mohla by být konfigurována také pro dosažení semisynchronní replikace).
Galera Cluster také podporuje multi-master replikaci. Je schopen neomezeného paralelního použití (tj. „paralelní replikace“), multicastové replikace a automatického zřizování uzlů.
Hlavním zaměřením Galera Cluster je konzistence dat, zatímco s replikací MySQL je náchylná k nekonzistentnosti dat (které lze předejít pomocí osvědčených postupů a správné konfigurace, jako je vynucení pouze pro čtení na podřízených zařízeních nechtěné zápisy v rámci otroků).
Přestože transakce přijaté Galerou jsou buď aplikovány na každý uzel, nebo vůbec, každý z těchto uzlů certifikuje replikovanou sadu zápisu ve frontě aplikace (potvrzení transakce), která také obsahuje informace o všech zámky, které držela databáze během transakce. Jakmile nejsou identifikovány žádné konfliktní zámky, jsou použity tyto zapisovací sady. Až do tohoto bodu jsou transakce považovány za potvrzené a nadále je aplikují na tabulkový prostor. Na rozdíl od asynchronní replikace se tento přístup také nazývá virtuálně synchronní replikace, protože zápisy a potvrzení probíhají v logickém synchronním režimu, ale vlastní zápis a potvrzení do tabulkového prostoru probíhá nezávisle a probíhá asynchronně na každém uzlu.
Na rozdíl od replikace MySQL je Galera Cluster skutečným multimasterem, vícevláknovým slavem, čistě hot-standby, bez potřeby master-failover nebo dělení pro čtení a zápis. Migrace na Galera Cluster však neznamená automatickou odpověď na vaše problémy. Galera Cluster podporuje pouze InnoDB, takže pokud používáte úložiště MyISAM nebo Memory, může dojít k úpravám návrhu.
Převod tabulek bez InnoDB na InnoDB
Galera Cluster vám umožňuje používat MyISAM, ale není to to, pro co byl Galera Cluster navržen. Galera Cluster je navržen tak, aby striktně implementoval konzistenci dat ve všech uzlech v rámci Clusteru, což vyžaduje silný databázový stroj kompatibilní s ACID. InnoDB je engine, který má v této oblasti tak silné schopnosti a doporučuje se používat InnoDB; zejména při řešení transakcí.
Pokud používáte ClusterControl, můžete snadno určit instance databáze pro jakékoli tabulky MyISAM, které poskytuje Performance Advisors. Najdete to na kartě Výkon → Poradci. Například,
Pokud potřebujete tabulky MyISAM a MEMORY, můžete je stále používat, ale vytvořit mít svá data, která není třeba replikovat. Svá uložená data můžete používat pouze pro čtení a kdykoli je to vhodné, použijte „ZAČÍT TRANSAKCI POUZE PRO ČTENÍ“.
Přidání primárních klíčů do vašich tabulek InnoDB
Protože Galera Cluster podporuje pouze InnoDB, je velmi důležité, aby všechny vaše tabulky měly seskupený index (nazývaný také primární klíč nebo jedinečný klíč). Chcete-li získat nejlepší výkon z dotazů, vkládání a dalších databázových operací, je velmi důležité, abyste každou tabulku nadefinovali jedinečným klíčem (klíči), protože InnoDB používá seskupený index k optimalizaci nejběžnějších operací vyhledávání a DML pro každou tabulku. . To pomáhá vyhnout se dlouhým dotazům v clusteru a může to zpomalit operace zápisu/čtení v clusteru.
V ClusterControl existují poradci, kteří vás na to mohou upozornit. Například ve vašem hlavním/podřízeném clusteru replikace MySQL se spustí alarm ze seznamu poradců nebo ze seznamu. Níže uvedený ukázkový snímek obrazovky ukazuje, že nemáte žádné tabulky, které nemají primární klíč:
Identifikujte uzel hlavního (nebo aktivního zapisovatele)
Galera Cluster je čistě skutečná multimaster replikace. Neznamená to však, že máte možnost napsat libovolný uzel, na který byste chtěli cílit. Jedna věc, kterou je třeba identifikovat, je, že když zapisujete na jiný uzel a bude detekována konfliktní transakce, dostanete se do zablokování, jak je uvedeno níže:
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;Problém se zápisem více uzlů bez identifikace aktuálního uzlu s aktivním zápisem, skončíte s těmito problémy, které jsou velmi častými problémy, se kterými jsem se setkal při používání Galera Cluster při psaní na více uzlech na stejný čas. Abyste se tomu vyhnuli, můžete použít přístup s jedním hlavním nastavením:
Z dokumentace
K uvolnění ovládání toku můžete použít níže uvedená nastavení:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Výše uvedené vyžaduje restart serveru, protože fc_master_slave není dynamický.
Povolit režim ladění pro konflikty protokolování nebo zablokování
Problémy s laděním nebo sledováním vašeho Galera Clusteru jsou velmi důležité. Zámky v Galeře jsou implementovány odlišně ve srovnání s replikací MySQL. Při řešení transakcí v celém clusteru používá optimistické zamykání. Na rozdíl od replikace MySQL má pouze pesimistické zamykání, které neví, zda je taková stejná nebo konfliktní transakce prováděna v co-master na multi-master nastavení. Galera stále používá pesimistické zamykání, ale na místním uzlu, protože je spravováno InnoDB, což je podporovaný modul úložiště. Galera používá optimistické zamykání, když jde do jiných uzlů. To znamená, že při dosažení lokálních zámků nejsou prováděny žádné kontroly s jinými uzly v clusteru (pesimistické zamykání). Galera předpokládá, že jakmile transakce projde fází potvrzení v rámci úložiště a ostatní uzly budou informovány, bude vše v pořádku a nevzniknou žádné konflikty.
V praxi je nejlepší povolit wsrep_logs_conflicts. Tím se zaprotokolují podrobnosti konfliktních zámků MDL a InnoDB v clusteru. Povolení této proměnné lze nastavit dynamicky, ale jakmile je povoleno, upozorněte. Podrobně vyplní váš soubor protokolu chyb a může zaplnit váš disk, jakmile bude soubor protokolu chyb příliš velký.
Buďte opatrní při svých dotazech DDL
Na rozdíl od replikace MySQL může spuštění příkazu ALTER ovlivnit pouze příchozí připojení, která vyžadují přístup nebo odkaz na tabulku, na kterou je váš příkaz ALTER zacílen. Může také ovlivnit slave, pokud je stůl velký a může přinést slave lag. Zápisy do vašeho masteru však nebudou blokovány, pokud vaše dotazy nebudou v konfliktu s aktuálním ALTER. To však zcela neplatí při spouštění vašich příkazů DDL, jako je ALTER s Galera Cluster. Příkazy ALTER mohou způsobit problémy, jako je zaseknutí clusteru Galera kvůli uzamčení celého clusteru nebo řízení toku začne uvolňovat replikaci, zatímco se některé uzly zotavují z velkých zápisů.
V některých situacích může dojít k výpadku vašeho Galera Cluster, pokud je tato tabulka příliš velká a je primární a životně důležitou tabulkou vaší aplikace. Lze toho však dosáhnout bez prostojů. Jak Rick James poukázal na svém blogu, můžete se řídit následujícími doporučeními:
RSU vs TOI
- Upgrade postupného schématu =ručně provádějte vždy jeden uzel (offline)
- Total Order Isolation =Galera se synchronizuje tak, že se to provádí ve stejnou dobu (v sekvenci replikace) na všech uzlech. RSU a TOI
Upozornění:Protože neexistuje způsob, jak synchronizovat klienty s DDL, musíte se ujistit, že klienti jsou spokojeni se starým i novým schématem. V opačném případě budete pravděpodobně muset odstranit celý cluster a současně přepnout schéma i kód klienta.
„Rychlý“ DDL lze také provést prostřednictvím TOI. Toto je předběžný seznam takových:
- VYTVOŘIT/PUSTIT/PŘEJMENOVAT DATABÁZI/TABULU
- ALTER pro změnu VÝCHOZÍ
- ALTER pro změnu definice ENUM nebo SET (viz upozornění v příručce)
- Některé změny PARTITION ALTER, které jsou rychlé.
- DROP INDEX (jiný než PRIMÁRNÍ KLÍČ)
- PŘIDAT INDEX?
- Další ALTER na „malých“ stolech.
- Vzhledem k tomu, že verze 5.6 a zejména 5.7 má mnoho případů ALTER ALGORITHM=INPLACE, zkontrolujte, které ALTER by se měly provádět a jakým způsobem.
V opačném případě použijte RSU. Pro každý uzel proveďte samostatně následující:
SET GLOBAL wsrep_OSU_method='RSU';To také odstraní uzel z clusteru.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Vrátí zpět, což vede k opětovné synchronizaci (doufejme, že rychlý IST, ne pomalý SST)
Zachovejte konzistenci svého clusteru
Galera Cluster nepodporuje replikační filtry, jako je binlog_do_db nebo binlog_ignore_db, protože Galera nespoléhá na binární protokolování. Spoléhá se na soubor ring-buffer nazývaný také GCache, který ukládá sady zápisu, které jsou replikovány podél clusteru. Nemůžete použít žádné nekonzistentní chování nebo stav takových uzlů databáze.
Galera na druhou stranu striktně implementuje konzistenci dat v rámci clusteru. Stále je možné, že tam, kde nelze najít řádky nebo záznamy, může dojít k nekonzistenci. Například nastavení proměnné wsrep_OSU_method buď RSU nebo TOI pro vaše příkazy DDL ALTER může způsobit nekonzistentní chování. Podívejte se na tento externí blog od Percona, který diskutuje o nesouladu s Galera s TOI vs RSU.
Nastavení wsrep_on=OFF a následné spouštění dotazů DML nebo DDL může být pro váš cluster nebezpečné. Musíte také zkontrolovat své uložené procedury, spouštěče, funkce, události nebo pohledy, pokud výsledky nezávisí na stavu uzlu nebo prostředí. Když může být určitý uzel (uzly) nekonzistentní, může to potenciálně způsobit pád celého clusteru. Jakmile Galera zjistí nekonzistentní chování, pokusí se opustit cluster a ukončit tento uzel. Je tedy možné, že všechny uzly mohou být nekonzistentní, takže se dostanete do stavu dilematu.
Pokud uzel Galera Cluster také zaznamená selhání, zejména v období vysokého provozu, je lepší nespouštět uzel hned. Místo toho proveďte úplný test SST nebo přiveďte novou instanci co nejdříve nebo jakmile se provoz sníží. Je možné, že uzel může způsobit nekonzistentní chování, které by mohlo poškodit data.
Oddělte velké transakce a určete, zda použít replikaci streamování
Pojďme rovnou na to. Jednou z největších změn funkcí zejména na Galera Cluster 4.0 je replikace streamování. Minulé verze Galera Cluster 4.0 omezuje transakce <2GiB, což je obvykle řízeno proměnnými wsrep_max_ws_rows a wsrep_max_ws_size. Od Galera Cluster 4.0 můžete odesílat> 2GiB transakcí, ale musíte určit, jak velké fragmenty musí být zpracovány během replikace. Musí být nastaven relací a jediné proměnné, o které musíte dbát, jsou wsrep_trx_fragment_unit a wsrep_trx_fragment_size. Zakázání replikace streamování je jednoduché, protože to uděláte nastavením wsrep_trx_fragment_size = 0. Vezměte na vědomí, že replikace velké transakce má také režii na podřízené uzly (uzly, které se replikují proti aktuálnímu uzlu aktivního zapisovače/hlavního uzlu), protože protokoly budou zapsány do tabulky wsrep_streaming_log v databázi MySQL.
Další věc, kterou je třeba dodat, protože se zabýváte velkou transakcí, je značné, že dokončení vaší transakce může nějakou dobu trvat, takže je třeba vzít v úvahu nastavení proměnné innodb_lock_wait_timeout na vysokou hodnotu. Nastavte to prostřednictvím relace v závislosti na odhadovaném čase, ale delším než odhadovaný čas dokončení, jinak časový limit prodlužte.
Doporučujeme, abyste si přečetli tento předchozí blog o streamování replikace v akci.
Replikace prohlášení GRANTs
Pokud používáte GRANTs a související operace, postupujte podle tabulek MyISAM/Aria v databázi `mysql`. Příkazy GRANT budou replikovány, ale základní tabulky nikoli. To znamená, že INSERT INTO mysql.user ... nebude replikován, protože tabulka je MyISAM.
Výše uvedené však již nemusí platit od verze Percona XtraDB Cluster (PXC) 8.0 (v současnosti experimentální), protože tabulky schémat mysql byly převedeny na InnoDB, zatímco v MariaDB 10.4 jsou některé tabulky stále ve formátu Aria, ale ostatní jsou ve formátu CSV nebo InnoDB. Měli byste určit, jakou verzi a poskytovatele Galery máte, ale nejlépe se vyhnout používání příkazů DML odkazujících na schéma mysql. V opačném případě můžete skončit s neočekávanými výsledky, pokud si nejste jisti, že se jedná o PXC 8.0.
Transakce XA, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK nejsou podporovány
Galera Cluster nepodporuje transakce XA, protože transakce XA zpracovávají vrácení zpět a potvrzení jinak. Příkazy LOCK/UNLOCK nebo GET_LOCK/RELEASE_LOCK jsou nebezpečné při použití nebo použití s Galera. Můžete zaznamenat havárii nebo zámky, které nelze zabít a zůstanou zamčené. Například,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5Tato transakce již byla odemčena a dokonce byla zabita, ale bez úspěchu. Doporučujeme, abyste při migraci na Galera Cluster museli přepracovat svého aplikačního klienta a zbavit se těchto funkcí.
Stabilita sítě je MUSÍ!!!
Galera Cluster může bez problémů pracovat is topologií inter-WAN nebo inter-geo topologií (podívejte se na tento blog o implementaci inter-geo topologie s Galera). Pokud však vaše síťová konektivita mezi jednotlivými uzly není stabilní nebo přerušovaně klesá na netušenou dobu, může to být pro cluster problematické. Nejlepší je mít cluster spuštěný v privátní a místní síti, kde je každý z těchto uzlů připojen. Když navrhujete uzel jako zotavení po havárii, naplánujte si vytvoření clusteru, pokud jsou v jiné oblasti nebo geografické oblasti. Můžete začít číst náš předchozí blog Použití MySQL Galera Cluster Replication k vytvoření Geo-Distributed Cluster:Část jedna, protože by vám to mohlo pomoci nejlépe rozhodnout o topologii Galera Cluster.
Další věc, kterou je třeba přidat k investování do síťového hardwaru, by bylo problematické, pokud by vám přenosová rychlost sítě poskytovala nižší rychlost během přestavby instance během IST nebo horší při SST, zejména pokud je vaše datová sada masivní . Síťový přenos může trvat dlouhé hodiny a to může ovlivnit stabilitu vašeho clusteru, zejména pokud máte cluster se 3 uzly, zatímco 2 uzly nejsou k dispozici, přičemž tyto 2 jsou dárcem a členem. Vezměte na vědomí, že během fáze SST nemohou být uzly DONOR/JOINER používány, dokud nebudou konečně schopny synchronizace s primárním clusterem.
V předchozí verzi Galery, pokud jde o výběr dárcovského uzlu, byl dárce State Snapshot Transfer (SST) vybrán náhodně. V Glera 4 se mnohem více zlepšil a má možnost vybrat si správného dárce v rámci klastru, protože upřednostní dárce, který může poskytnout přírůstkový převod stavu (IST), nebo vybrat dárce ve stejném segmentu. Případně můžete nastavit proměnnou wsrep_sst_donor na správného dárce, kterého byste chtěli vždy vybrat.
Zálohujte svá data a proveďte pevné testování během migrace a před výrobou
Jakmile budete v obleku a rozhodnete se migrovat svá data do Galera Cluster 4.0, ujistěte se, že máte zálohu vždy připravenou. Pokud jste vyzkoušeli ClusterControl, zálohování bude jednodušší.
Ujistěte se, že migrujete na správnou verzi InnoDB a nezapomeňte před provedením testu vždy použít a spustit mysql_upgrade. Ujistěte se, že všechny vaše testy projdou požadovaným výsledkem, který vám může replikace MySQL nabídnout. S největší pravděpodobností není žádný rozdíl mezi úložištěm InnoDB, které používáte v MySQL Replication Cluster oproti MySQL Galera Cluster, pokud doporučení a tipy byly aplikovány a připraveny předem.
Závěr
Migrace na Galera Cluster 4.0 nemusí být vaším požadovaným řešením databázové technologie. Nicméně vás to neláká používat Galera Cluster 4.0, pokud lze připravit, nastavit a poskytnout jeho specifické požadavky. Galera Cluster 4.0 se nyní stal velmi výkonnou životaschopnou volbou a možností, zejména na vysoce dostupné platformě a řešení. Také vám doporučujeme, abyste si přečetli tyto externí blogy o Galera Caveats nebo Limitations of Galera Cluster nebo tuto příručku od MariaDB.