Většina správců databází tu a tam provádí kontroly stavu svých databází. Obvykle by se to stalo denně nebo týdně. Dříve jsme diskutovali, proč jsou takové kontroly důležité a co by měly zahrnovat.
Abyste se ujistili, že jsou vaše systémy v dobrém stavu, budete muset projít poměrně hodně informací – statistiky hostitelů, statistiky MySQL, statistiky zátěže, stav záloh, databázové balíčky, protokoly a tak dále. Taková data by měla být dostupná v každém řádně monitorovaném prostředí, i když někdy jsou rozptýlena na více místech – můžete mít jeden nástroj pro sledování stavu MySQL, jiný nástroj pro sběr systémových statistik, možná sadu skriptů, např. vaše zálohy. Díky tomu jsou kontroly stavu mnohem časově náročnější, než by měly být – DBA musí dát dohromady různé části, aby pochopil stav systému.
Integrované nástroje jako ClusterControl mají tu výhodu, že všechny bity jsou umístěny na stejném místě (nebo ve stejné aplikaci). Stále to neznamená, že jsou umístěny vedle sebe – mohou se nacházet v různých částech uživatelského rozhraní a DBA možná bude muset strávit nějaký čas proklikáváním se uživatelským rozhraním, aby se dostal ke všem zajímavým datům.
Celá myšlenka, která stojí za vytvářením provozních zpráv, je vložit všechna nejdůležitější data do jediného dokumentu, který lze rychle zkontrolovat, abyste porozuměli stavu databází.
Provozní zprávy jsou dostupné z nabídky Postranní nabídka -> Provozní zprávy:
Jakmile tam přejdete, zobrazí se vám seznam sestav vytvořených ručně nebo automaticky na základě předem definovaného plánu:
Pokud chcete vytvořit nový přehled ručně, použijete možnost Vytvořit. Vyberte typ sestavy, název klastru (pro klastrovou sestavu), příjemce e-mailu (volitelné – pokud chcete, aby vám byla sestava doručena) a máte hotovo:
Zprávy lze také naplánovat na pravidelné vytváření:
V současné době je k dispozici 5 typů přehledů:
- Přehled dostupnosti – všechny clustery.
- Záložní sestava – Všechny clustery.
- Zpráva o změně schématu – pouze cluster založený na MySQL/MariaDB.
- Denní systémový přehled – podle clusteru.
- Přehled upgradu balíčku – podle clusteru.
Zpráva o dostupnosti
Přehledy dostupnosti se zaměřují na dostupnost. Zahrnuje tři oddíly. Nejprve shrnutí dostupnosti:
Můžete vidět informace o statistikách dostupnosti vašich databází, typu clusteru, celkové době provozu a výpadku, aktuálním stavu clusteru a době, kdy se tento stav naposledy změnil.
Další část poskytuje další podrobnosti o dostupnosti pro každý cluster. Níže uvedený snímek obrazovky ukazuje pouze jeden z databázových clusterů:
Můžeme vidět, kdy se uzel přepnul do stavu a jaký byl přechod. Je to pěkné místo, kde můžete zkontrolovat, zda se v nedávných dnech vyskytly nějaké problémy s clusterem. Podobné údaje jsou uvedeny ve třetí části této zprávy, kde si můžete projít historii změn stavu clusteru.
Záložní zpráva
Druhým typem sestavy je sestava pokrývající zálohy všech clusterů. Obsahuje dvě části – shrnutí zálohy a podrobnosti o záloze, kde první vám v podstatě poskytuje krátké shrnutí, kdy byla vytvořena poslední záloha, zda byla úspěšně dokončena nebo selhala, stav ověření zálohy, úspěšnost a dobu uchování:
ClusterControl také poskytuje příklady zásad zálohování, pokud zjistí, že některý z monitorovaných databázových clusterů běží bez naplánovaného zálohování nebo nakonfigurovaného zpožděného slave zařízení. Dále jsou podrobnosti zálohování:
Můžete také zkontrolovat seznam záloh provedených na clusteru s jejich stavem, typem a velikostí v zadaném intervalu. To je tak blízko, že si můžete být jisti, že zálohy fungují správně, aniž byste museli spouštět test úplné obnovy. Rozhodně doporučujeme takové testy provádět každou chvíli. Dobrou zprávou je, že ClusterControl podporuje obnovu a ověření založené na MySQL na samostatném hostiteli v části Záloha -> Obnovit zálohu.
Denní systémová zpráva
Tento typ sestavy obsahuje podrobné informace o konkrétním clusteru. Začíná souhrnem různých výstrah, které souvisejí s clusterem:
Další část je o stavu uzlů, které jsou součástí clusteru:
Máte seznam uzlů v clusteru, jejich typ, roli (master nebo slave), stav uzlu, dobu provozu a OS.
Další částí zprávy je shrnutí zálohy, stejně jako jsme diskutovali výše. Další představuje souhrn hlavních dotazů v clusteru:
Nakonec vidíme „Přehled stavu uzlu“, ve kterém se vám zobrazí grafy související s metrikami OS a MySQL pro každý uzel.
Jak můžete vidět, máme zde grafy pokrývající všechny aspekty zatížení hostitele – CPU, paměť, síť, disk, zatížení CPU a volný disk. To stačí k tomu, abyste si udělali představu, zda se nedávno stalo něco divného nebo ne. Můžete také vidět některé podrobnosti o zátěži MySQL – kolik dotazů bylo vykonáno, jaký typ dotazu, jak byl přístup k datům (přes který handler)? To by na druhou stranu mělo stačit k výběru většiny problémů na straně MySQL. To, na co se chcete podívat, jsou všechny špičky a poklesy, které jste v minulosti neviděli. Možná byl do mixu přidán nový dotaz a v důsledku toho handler_read_rnd_next raketově vzrostl? Možná došlo ke zvýšení zátěže CPU a vysoký počet připojení by mohl ukazovat na zvýšené zatížení MySQL, ale také na určitý druh sporu. Nečekaný vzorec může být dobré prozkoumat, abyste věděli, co se děje.
Zpráva o aktualizaci balíčku
Tato zpráva poskytuje souhrn balíčků dostupných pro upgrade správcem úložiště na monitorovaných hostitelích. Pro přesné hlášení se ujistěte, že na každém hostiteli vždy používáte stabilní a důvěryhodná úložiště. V některých nežádoucích případech by monitorovaní hostitelé mohli být po upgradu nakonfigurováni se zastaralým úložištěm (např. každá hlavní verze MariaDB používá jiné úložiště), neúplným interním úložištěm (např. částečně zrcadleným z upstreamu) nebo hraničním úložištěm (běžně pro nestabilní balíčky sestavené v noci).
První část je shrnutí upgradu:
Shrnuje celkový počet balíčků dostupných pro upgrade a také související spravované služby pro cluster, jako je vyrovnávání zatížení, virtuální IP adresa a arbitr. Dále ClusterControl poskytuje podrobný seznam balíčků seskupený podle typu balíčku pro každého hostitele:
Tato zpráva poskytuje dostupnou verzi a může nám velmi pomoci efektivně naplánovat dobu údržby. U kritických upgradů, jako jsou bezpečnostní a databázové balíčky, bychom je mohli upřednostnit před nekritickými upgrady, které by mohly být konsolidovány s jinými méně prioritními okny údržby.
Zpráva o změně schématu
Tato sestava porovnává změny vybrané databáze MySQL/MariaDB ve struktuře tabulky, ke kterým došlo mezi dvěma různými generovanými sestavami. Ve starších verzích MySQL/MariaDB je operace DDL neatomická operace (před 8.0) a vyžaduje úplnou kopii tabulky (před verzí 5.6 pro většinu operací) – blokuje ostatní transakce, dokud nebude dokončena. Změny schématu se mohou stát obrovskou bolestí, jakmile vaše tabulky získají značné množství dat, a musí být pečlivě naplánovány, zejména v klastrovém nastavení. Ve vícevrstvém vývojovém prostředí jsme viděli mnoho případů, kdy vývojáři tiše upravili strukturu tabulky, což mělo významný dopad na výkon dotazů.
Aby ClusterControl vytvořil přesnou zprávu, musí být v konfiguračním souboru CMON pro příslušný cluster nakonfigurovány speciální možnosti:
- adresa_detekce_změny schématu - Kontroly budou prováděny pomocí ZOBRAZIT TABULKY/ZOBRAZIT VYTVOŘIT TABULKU, aby se zjistilo, zda se schéma změnilo. Kontroly se provádějí na zadané adrese a má formát HOSTNAME:PORT. schema_change_detection_databases musí být také nastaveno. Vytvoří se diferenciál změněné tabulky (pomocí diff).
- schema_change_detection_databases - Čárkami oddělený seznam databází ke sledování změn schématu. Pokud je prázdné, nebudou prováděny žádné kontroly.
V tomto příkladu bychom chtěli monitorovat změny schématu pro databázi „myapp“ a „sbtest“ v našem clusteru MariaDB s ID clusteru 27. Vyberte jeden z uzlů databáze jako hodnotu adresa_detekce_změny schématu . Pro replikaci MySQL by to měl být hlavní hostitel nebo jakýkoli podřízený hostitel, který uchovává databáze (v případě, že je aktivní částečná replikace). Poté do /etc/cmon.d/cmon_27.cnf přidejte dva následující řádky:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestRestartujte službu CMON a načtěte změnu:
$ systemctl restart cmonU první a nejdůležitější sestavy vrací ClusterControl pouze výsledek shromažďování metadat, podobně jako níže:
S první sestavou jako výchozí, následující sestavy vrátí výstup, který očekáváme:
Vezměte na vědomí, že ve zprávě jsou vytištěny pouze nové tabulky nebo změněné tabulky. První zpráva je určena pouze pro sběr metadat pro srovnání v následujících kolech, takže ji musíme spustit alespoň dvakrát, abychom viděli rozdíl.
Pomocí této zprávy nyní můžete shromáždit stopy struktury databáze a pochopit, jak se vaše databáze vyvíjela v průběhu času.
Poslední myšlenky
Provozní zpráva je komplexní způsob, jak porozumět stavu vaší databázové infrastruktury. Je vytvořen pro provozní i manažerské pracovníky a může být velmi užitečný při analýze vašich databázových operací. Přehledy mohou být generovány na místě nebo vám mohou být doručeny prostřednictvím e-mailu, což usnadňuje práci, pokud máte silo pro podávání zpráv.
Rádi bychom slyšeli váš názor na cokoli dalšího, co byste chtěli do zprávy zahrnout, co chybí a co není potřeba.