sql >> Databáze >  >> RDS >> MariaDB

Tipy pro monitorování MariaDB Cluster

V předchozích příspěvcích na blogu jsme se zabývali tématy Monitoring Your Galera Cluster, ať už je to MySQL nebo MariaDB. Přestože se technologické verze příliš neliší, MariaDB Cluster má od verze 10.4.2 několik zásadních změn. V této verzi podporuje Galera Cluster 4 a má několik skvělých nových funkcí, na které se podíváme v tomto příspěvku na blogu.

Pro začátečníky, kteří ještě neznají MariaDB Cluster,  je prakticky synchronní multimaster cluster pro MariaDB. Je k dispozici pouze na Linuxu a podporuje pouze úložné motory XtraDB/InnoDB (ačkoli existuje experimentální podpora pro MyISAM – viz systémová proměnná wsrep_replicate_myisam).

Software je přibalená technologie, která je poháněna serverem MariaDB, opravou MySQL-wsrep pro server MySQL a serverem MariaDB vyvinutým společností Codership (podporuje operační systém Unix) a knihovnou poskytovatelů wsrep Galera.

Tento produkt můžete porovnat s MySQL Group Replication nebo s MySQL InnoDB Clusterem, jehož cílem je poskytovat vysokou dostupnost. (I když se liší v principech a přístupech k poskytování HA.) 

Teď, když jsme probrali základy, v tomto blogu vám poskytneme tipy, které považujeme za užitečné při monitorování vašeho clusteru MariaDB.

Základy klastru MariaDB

Když začnete používat MariaDB Cluster, musíte nejprve určit, co přesně je vaším účelem a proč jste si vybrali MariaDB Cluster. Nejprve musíte strávit, jaké jsou funkce a jejich výhody při používání MariaDB Cluster. Důvodem pro jejich identifikaci je to, že to je v podstatě to, co je třeba monitorovat a kontrolovat, abyste mohli určit výkon, normální zdravotní stav a jestli to běží v souladu s vašimi plány.

V zásadě je identifikován jako žádné zpoždění slave, žádné ztracené transakce, škálovatelnost čtení a menší latence klientů. Pak mohou vyvstat otázky jako, jak to nezpůsobí zpoždění otroků nebo ztracené transakce? Jak to dělá čtení škálovatelné nebo s menšími latencemi na straně klienta? Tyto oblasti jsou jednou z klíčových oblastí, které je třeba sledovat a monitorovat zejména při náročném výrobním využití.

I když samotný klastr MariaDB lze odpovídajícím způsobem upravit. Použití změn výchozího chování, jako je pc.weight nebo pc.ignore_quorum, nebo dokonce použití vícesměrového vysílání s UDP pro velký počet uzlů, může ovlivnit způsob, jakým monitorujete povahu vašeho clusteru MariaDB. Ale na druhou stranu, nejzásadnějšími stavovými proměnnými jsou obvykle vaše výhoda, protože víte, že stav a tok vašeho clusteru funguje dobře, nebo jeho degradace, což předem ukazuje na možný problém vedoucí ke katastrofickému selhání.

Vždy sledujte aktivitu serveru (síť, disk, zatížení, paměť a CPU)

Monitorování aktivity serveru může být také složitým úkolem, pokud máte velmi komplikovaný zásobník, který je propleten ve vaší databázové architektuře. Pro klastr MariaDB je však vždy nejlepší, aby vaše uzly byly vždy nastaveny tak specializované, ale co nejjednodušší. Ačkoli vás to neomezuje ve využívání všech náhradních zdrojů, níže jsou uvedeny společné klíčové oblasti, které musíte prozkoumat.

Síť

Galera Cluster 4 obsahuje replikaci streamování jako jednu z klíčových funkcí a změn oproti předchozí verzi. Vzhledem k tomu, že streamingová replikace řeší nevýhody, které měla v předchozích verzích, umožňuje jí spravovat více než 2 GB zápisových sad od Galera Cluster 4. To umožňuje fragmentaci velkých transakcí a důrazně se doporučuje povolit to pouze na úrovni relace. To znamená, že sledování vaší síťové aktivity je velmi důležité a zásadní pro normální činnost vašeho MariaDB Clusteru. To vám pomůže určit, který uzel měl největší nebo nejvyšší síťový provoz na základě časového období.

Jak vám to pomůže zlepšit tam, kde byly identifikovány uzly s nejvyšším síťovým provozem? To vám poskytuje prostor pro zlepšení topologie vaší databáze nebo architektonické vrstvy vašeho databázového clusteru. Použití load balancerů nebo databázového proxy vám umožňuje proaktivně konfigurovat databázový provoz, zejména při určování, které konkrétní zápisy mají jít do konkrétního uzlu. Řekněme, že ze 3 uzlů je jeden z nich schopnější zpracovávat velké a velké dotazy kvůli rozdílům v hardwarových specifikacích. To vám umožní řídit větší část vašich kapitálových výdajů a zlepšit plánování kapacity podle toho, jak se mění požadavky na určité časové období.

Disk

Protože na síťové aktivitě záleží také na výkonu vašeho disku, zejména během doby proplachování. Nejlepší je také určit, jak bude probíhat odevzdání času a vyhledávání, když je dosaženo vysokého špičkového zatížení. Jsou chvíle, kdy zásobujete svého hostitele databáze nejen tím, že se věnujete aktivitě Galera Cluster, ale také kombinujete s dalšími nástroji, jako je docker, SQL proxy, jako je ProxySQL nebo MaxScale. To vám dává kontrolu nad servery s nízkou zátěží a umožňuje vám využívat dostupné náhradní zdroje, které lze využít pro jiné užitečné účely, zejména pro váš zásobník architektury databáze. Jakmile budete schopni určit, který uzel při monitorování má nejnižší zatížení, ale stále je schopen řídit využití I/O disku, můžete vybrat konkrétní uzel a přitom sledovat uplynulý čas. Opět vám to stále poskytuje lepší správu s plánováním kapacity.

Aktivita CPU, paměti a zatížení

Dovolte mi stručně uvést tyto tři oblasti, na které je třeba se při monitorování zaměřit. V této sekci je vždy nejlepší mít lepší pozorovatelnost následujících oblastí najednou. Je to rychlejší a snáze pochopitelné, zejména vyloučení úzkého hrdla výkonu nebo identifikace chyb, které způsobují, že se vaše uzly buď zablokují, a které mohou také ovlivnit ostatní uzly a možnost sestupu v clusteru.

Jak tedy CPU, paměť a zátěžová aktivita při monitorování pomáhají vašemu MariaDB Cluster? No, jak jsem zmínil výše, to jsou jedna z mála věcí, ale velký faktor pro každodenní rutinní kontroly. Nyní vám to také pomůže určit, zda se jedná o periodické nebo náhodné výskyty. Pokud je to periodické, může to souviset se zálohami spuštěnými v jednom z vašich uzlů Galera, nebo se jedná o rozsáhlý dotaz, který vyžaduje optimalizaci. Například chybné dotazy bez správných indexů nebo nevyvážené využití načítání dat, jako je porovnávání řetězců pro tak velký řetězec. To může být nepopiratelně nepoužitelné pro databáze typu OLTP, jako je MariaDB Cluster, zejména pokud je to skutečně povaha a požadavky vaší aplikace. Pro vyhledávání velkých řetězců a/nebo porovnávání řetězců je lepší používat jiné analytické nástroje, jako je MariaDB Columnstore, nebo jiné nástroje pro analytické zpracování (Apache Spark, Kafka nebo MongoDB atd.).

Když jsou tedy všechny tyto klíčové oblasti monitorovány, je otázkou, jak by měly být monitorovány? Musí být sledován alespoň za minutu. S propracovaným monitorováním, tj. za sekundu kolektivních metrik může být náročné na zdroje a hodně chamtivé, pokud jde o vaše zdroje. I když je půlminutová kolektivita přijatelná, zejména pokud jsou vaše data a RPO (cíl bodu obnovy) velmi nízké, takže potřebujete podrobnější metriky dat v reálném čase. Je velmi důležité, abyste byli schopni dohlížet na celkový obraz vašeho databázového clusteru. Kromě toho je také nejlepší a důležité, že kdykoli, jaké metriky sledujete, máte k dispozici správný nástroj, který vás upozorní, když jsou věci v nebezpečí nebo dokonce jen varování. Použití správného nástroje, jako je ClusterControl, vám pomůže spravovat tyto klíčové oblasti, které mají být monitorovány. Používám zde bezplatnou verzi nebo komunitní edici ClusterControl a pomáhá mi monitorovat mé uzly bez jakýchkoli potíží od instalace až po monitorování uzlů pomocí pouhých několika kliknutí. Podívejte se například na níže uvedené snímky obrazovky:

Zobrazení je přesnější a rychlejší přehled toho, co se aktuálně děje. Lze použít i podrobnější graf

nebo s výkonnějším a bohatším datovým modelem, který také podporuje dotazovací jazyk vám poskytne analýzu výkonu vašeho MariaDB Clusteru na základě historických dat, která včas porovná jeho výkon. Například,

To vám jen poskytuje viditelnější metriky. Takže vidíte, jak je skutečně důležité mít správný nástroj při monitorování vašeho MariaDB Clusteru.

Zajistěte hromadné sledování statistických proměnných clusteru MariaDB

Čas od času nemůže být nevyhnutelné, že verze MariaDB Cluster budou produkovat nové statistiky pro monitorování nebo vylepšení povahy monitorování databáze tím, že poskytnou více stavových proměnných a zpřesní hodnoty, na které se budete dívat. Jak jsem uvedl výše, používám ClusterControl ke sledování svých uzlů v tomto příkladu blogu. To však neznamená, že je to nejlepší nástroj. Myslím tím, že PMM od Percona je velmi bohaté, pokud jde o kolektivní monitorování pro každou statistickou proměnnou, které kdykoli nabízí MariaDB Cluster novější statistické proměnné, můžete to využít a také změnit, protože PMM je open-source nástroj. Je velkou výhodou, že máte také veškerou viditelnost svého MariaDB Clusteru, protože každý aspekt se počítá zejména v produkční databázi, která uspokojuje stovky tisíc požadavků za minutu.

Pojďme ale k tomuto problému zde konkrétněji. Jaké jsou tyto statistické proměnné, které je třeba zkoumat? U MariaDB Clusteru je mnoho, na co se dá spolehnout, ale když se znovu zaměříme na funkce a výhody, o kterých věříme, že používáte MariaDB Cluster to, co nabízí, pak se zaměříme na to.

Galera Cluster – Řízení toku

Řízení toku vašeho klastru MariaDB vám poskytuje přehled o tom, jak funguje stav replikace v celém klastru. Proces replikace v Galera Cluster využívá mechanismus zpětné vazby, což znamená, že signalizuje všem uzlem v tomto clusteru a označí, zda má uzel pozastavit nebo obnovit replikaci podle svých potřeb. To také zabraňuje tomu, aby jakýkoli uzel příliš zaostával, zatímco ostatní aplikují příchozí transakce. Takto funguje řízení průtoku v rámci Galery. Nyní to musíte vidět a nepřehlížet při sledování vašeho MariaDB Clusteru. To, jak je zmíněno v jedné z výhod používání MariaDB Cluster, je to, že se vyhnete zpoždění otroků. I když je to příliš naivní na pochopení o řízení toku a zpoždění slave, ale s řízením toku to ovlivní výkon vašeho clusteru Galera, když je hodně fronty a odevzdání nebo vyprázdnění stránek na disk je velmi nízké pro takové problémy s diskem nebo jen běžící dotaz je špatný dotaz. Pokud jste začátečník v tom, jak Galera funguje, možná vás bude zajímat, když si přečtete tento externí příspěvek o tom, co je řízení toku v Galeře.

Bajty odeslané/přijaté

Poslané nebo přijaté bajty korelují se síťovou aktivitou a dokonce jsou jednou z klíčových oblastí, které je třeba poměřit vedle sebe s řízením toku. To vám umožní určit, který uzel je nejvíce ovlivněn nebo připisuje problémy s výkonem, které trpí ve vašem clusteru Galera. Je to velmi důležité, protože můžete zkontrolovat, zda může dojít k nějaké degradaci hardwaru, jako je vaše síťové zařízení nebo základní úložné zařízení, u kterého může synchronizace špinavých stránek trvat příliš dlouho.

Načtení clusteru

No, jde spíše o databázovou aktivitu o tom, kolik změn nebo načtení dat bylo dosud dotazováno nebo provedeno od doby provozu serveru. Pomáhá vám vyloučit, jaké druhy dotazů nejvíce ovlivňují výkon vašeho databázového clusteru. To vám umožní poskytnout prostor pro zlepšení, zejména pokud jde o vyvážení zatížení vašich databázových požadavků. Použití ProxySQL vám zde pomůže s jemnějším a podrobnějším přístupem pro směrování dotazů. Ačkoli MaxScale také nabízí tuto funkci, ProxySQL má větší granularitu, ačkoli má také určitý dopad na výkon nebo náklady. Dopad přichází, když máte pouze jeden ProxySQL jako SQL proxy pro vypracování směrování dotazů a může mít problémy, když je vysoký provoz. Pokud přidáte více uzlů ProxySQL, abyste vyrovnali větší provoz, který je základem KeepAlived, bude to drahé. I když je to perfektní kombo, ale může být provozováno za nízkou cenu, dokud není potřeba. Jak však budete moci určit, zda je to nutné, že? To je otázka, která zde zůstává, takže pozorné sledování těchto klíčových oblastí je velmi důležité, nejen pro pozorovatelnost, ale také pro zlepšení výkonu vašeho databázového clusteru v průběhu času.

Cluster MariaDB jako takový obsahuje spoustu proměnných, na které se můžete dívat. Nejdůležitější věcí, kterou zde musíte vzít v úvahu, je nástroj, který používáte pro monitorování svého databázového clusteru. Jak již bylo zmíněno dříve, dávám přednost použití bezplatné verze licence ClusterControl (Community Edition) zde na tomto blogu, protože mi poskytuje více flexibilních způsobů, jak se na ně dívat v Galera Cluster. Viz příklad níže,

Označil jsem nebo zakroužkoval červeně ty karty, které mi umožňují vizuální kontrolu zdraví mého MariaDB Clusteru. Řekněme, že pokud je vaše aplikace čas od času nenasytná používání streamingové replikace a odesílá velké množství fragmentů (velký síťový přenos) pro interaktivitu clusteru, je nejlepší určit, jak dobře vaše uzly zvládnou stres. Zejména během zátěžového testování před prosazením konkrétních změn ve vaší aplikaci je vždy nejlepší vyzkoušet a otestovat, abyste určili správu kapacity vašeho aplikačního produktu a určili, zda vaše aktuální databázové uzly a návrh zvládnou zátěž požadavků vaší aplikace.

Dokonce i na komunitním vydání ClusterControl jsem schopen shromáždit podrobné a propracovanější výsledky zdraví mého MariaDB Clusteru. Viz níže,

Takto budete přistupovat k monitorování svého clusteru MariaDB. Dokonalá vizualizace je vždy jednodušší a rychlejší na správu. Když věci půjdou na jih, nemůžete si dovolit ztrácet svou produktivitu a také prostoje mohou ovlivnit vaše podnikání. I když vám mít zdarma nezajistí luxus a pohodlí při správě databází s vysokým provozem, mít alarmy, upozornění a správu databází v jedné oblasti jsou doplňky, které ClusterControl umí.

Závěr

MariaDB Cluster není tak jednoduchý na monitorování ve srovnání s tradičními asynchronními nastaveními MySQL/MariaDB master-slave. Funguje to jinak a musíte mít ty správné nástroje k určení toho, co se děje a co se děje ve vašem databázovém clusteru. Před spuštěním MariaDB Clusteru si vždy připravte plánování kapacity dopředu, aniž byste předem museli řádně monitorovat. Vždy je nejlepší, když zatížení a aktivita vaší databáze budou známy před katastrofickou událostí.


  1. Jak vypsat databáze a tabulky v PostgreSQL

  2. MySQL rychle odstraňuje duplikáty z velké databáze

  3. Přejmenování indexů pomocí procedury sp_rename

  4. Příklady DAY() – MySQL