V naší nejnovější verzi ClusterControl 1.7.0 jsme přidali řadu nových řídicích panelů pro MySQL. - a v našem předchozím blogu jsme vám ukázali, jak monitorovat ProxySQL pomocí Prometheus a ClusterControl.
V tomto blogu se podíváme na řídicí panel Přehled MySQL.
Povolili jsme tedy Agent Based Monitoring na kartě Dashboard, abychom mohli začít shromažďovat metriky do uzlů. Vezměte na vědomí, že když povolujete monitorování založené na agentech, máte možnost nastavit „Interval seškrabování (v sekundách) “ a „Uchování údajů (dny) “. Scraping Interval je místo, kde chcete nastavit, jak agresivně bude Prometheus sklízet data z cíle, a Data Retention je doba, po kterou chcete uchovávat svá data shromážděná společností Prometheus, než budou smazána.
Když je povoleno, můžete určit, který cluster má agenty a který má monitorování bez agentů.
Ve srovnání s přístupem bez agentů bude granularita vašich dat v grafech u agentů vyšší.
Grafy MySQL
Nejnovější verze ClusterControl 1.7.0 (kterou si můžete zdarma stáhnout – ClusterControl Community) má následující řídicí panely MySQL, pro které můžete shromažďovat informace pro své servery MySQL. Jedná se o MySQL Overview, MySQL InnoDB Metrics, MySQL Performance Schema a MySQL Replication.
Podrobně se budeme věnovat grafům dostupným na řídicím panelu Přehled MySQL.
Přehledový panel MySQL
Tento řídicí panel obsahuje obvyklé důležité proměnné nebo informace týkající se stavu vašeho MySQL uzlu. Grafy obsažené na tomto panelu jsou specifické pro uzel vybraný při prohlížení panelů, jak je vidět níže:
Skládá se z 26 grafů, ale při diagnostice problémů možná nebudete všechny potřebovat. Tyto grafy však poskytují zásadní znázornění celkových metrik pro vaše servery MySQL. Pojďme si projít ty základní, protože to jsou pravděpodobně nejběžnější věci, na které se DBA bude běžně dívat.
První čtyři grafy zobrazené výše spolu s dobou provozuschopnosti MySQL, počtem dotazů za sekundu a informacemi o fondu vyrovnávací paměti jsou nejzákladnějšími ukazateli, které bychom mohli potřebovat. Z výše uvedených grafů jsou jejich znázornění:
- Připojení MySQL
Zde chcete zkontrolovat celkový počet dosud přidělených klientských připojení v určitém časovém období. - Aktivita vlákna klienta MySQL
Jsou chvíle, kdy může být váš server MySQL velmi zaneprázdněn. Můžete například očekávat nárůst provozu v určitou dobu a vy chcete monitorovat aktivitu běžících vláken. Na tento graf je opravdu důležité se podívat. Může nastat situace, kdy výkon vašeho dotazu může přejít na jih, pokud například velká aktualizace způsobí, že jiná vlákna čekají na získání uzamčení. To by vedlo ke zvýšenému počtu vašich běžících vláken. Míra vynechání mezipaměti se vypočítá jako Threads_created/Connections. - Dotazy k MySQL
Toto jsou dotazy běžící v určitém časovém období. Vlákno může být transakce složená z více dotazů a toto může být dobrý graf, na který se můžete podívat. - Mezipaměť vláken MySQL
Tento graf ukazuje hodnotu thread_cache_size, vlákna, která jsou uložena v mezipaměti (vlákna, která jsou znovu použita) a vlákna, která jsou vytvořena (nová vlákna). Na tomto grafu můžete zkontrolovat případy, kdy potřebujete vyladit čtené dotazy, když si všimnete vysokého počtu příchozích připojení a počet vytvořených vláken rychle narůstá. Pokud například vaše Threads_running / thread_cache_size> 2, pak zvýšení vaší thread_cache_size může zvýšit výkon vašeho serveru. Vezměte na vědomí, že vytváření a ničení vláken je nákladné. V posledních verzích MySQL (>=5.6.8) má však tato proměnná ve výchozím nastavení automatickou velikost, kterou byste mohli považovat za nedotčenou.
Další čtyři grafy jsou MySQL Temporary Objects, MySQL Select Types, MySQL Sorts a MySQL Slow Queries. Tyto grafy spolu souvisí, zvláště pokud diagnostikujete dlouhotrvající dotazy a velké dotazy, které vyžadují optimalizaci.
- Dočasné objekty MySQL
Tento graf by byl dobrým zdrojem, na který se můžete spolehnout, pokud chcete monitorovat dlouho běžící dotazy, které by skončily pomocí disku místo dočasných tabulek nebo souborů uložených v paměti. Je to dobré místo, kde začít hledat periodický výskyt dotazů, které by se mohly sčítat a vytvářet problémy s místem na disku, zejména v neobvyklých časech. - Vybrané typy MySQL
Jedním ze zdrojů špatného výkonu jsou dotazy, které používají úplná spojení, prohledávání tabulek, výběrový rozsah, který nepoužívá žádné indexy. Tento graf ukazuje, jak si vede váš dotaz a co ze seznamu od úplných spojení po spojení v celém rozsahu, výběr rozsahu, prohledávání tabulek má nejvyšší trendy. - Třídí MySQL
Diagnostika dotazů, které používají řazení, a dotazů, jejichž dokončení trvá dlouho. - Pomalé dotazy MySQL
Trendy vašich pomalých dotazů jsou shromážděny zde v tomto grafu. To je velmi užitečné zejména při diagnostice toho, jak často jsou vaše dotazy pomalé. Jaké věci je potřeba doladit? Může to být příliš malý fond vyrovnávacích pamětí, tabulky, které postrádají indexy a prochází úplnou kontrolou tabulky, logické zálohy běžící podle neočekávaného plánu atd. Použití našeho Query Monitor v ClusterControl spolu s tímto grafem je výhodné, protože pomáhá určit pomalé dotazy.
Další grafy, které pokrýváme, jsou více aktivity sítě, uzamčení tabulek a základní vnitřní paměti, kterou MySQL spotřebovává během činnosti MySQL.
- Přerušená připojení MySQL
Počet přerušených připojení se zobrazí v tomto grafu. To se vztahuje na přerušené klienty, například tam, kde byla síť náhle uzavřena nebo kde došlo k výpadku či přerušení internetového připojení. Zaznamenává také přerušená připojení nebo pokusy, jako jsou nesprávná hesla nebo špatné pakety při navazování připojení od klienta. - Zámky tabulek MySQL
Trendy pro tabulky, které požadují zámek tabulky, který byl udělen okamžitě, a pro tabulky, které požadují zámek, který nebyl okamžitě získán. Pokud máte například zámky na úrovni tabulky u tabulek MyISAM a příchozích požadavků stejné tabulky, nelze je udělit okamžitě. - Provoz sítě MySQL
Tento graf ukazuje trendy příchozí a odchozí síťové aktivity na serveru MySQL. „Příchozí“ jsou data přijatá serverem MySQL, zatímco „Odchozí“ jsou data odeslaná nebo přenesená serverem ze serveru MySQL. Tento graf je nejlepší zkontrolovat, pokud chcete monitorovat síťový provoz, zejména při diagnostikování provozu je střední, ale ptáte se, proč má velmi vysoký objem odchozích přenesených dat, jako jsou například data BLOB. - Využití sítě MySQL za hodinu
Stejné jako síťový provoz, který zobrazuje přijatá a odeslaná data. Mějte na paměti, že je založen na „za hodinu“ a označen jako „poslední den“, což nebude následovat po časovém období, které jste vybrali ve výběru data. - Přehled vnitřní paměti MySQL
Tento graf je známý pro zkušeného MySQL DBA. Každá z těchto legend ve sloupcovém grafu je velmi důležitá, zejména pokud chcete sledovat využití paměti, využití fondu vyrovnávací paměti nebo velikost adaptivního hash indexu.
Následující grafy ukazují čítače, na které se může DBA spolehnout, jako je kontrola statistik, například statistiky pro výběry, vložení, aktualizace, počet provedených master statusů, počet ZOBRAZIT PROMĚNNÉ, které byly provedeny, kontrola pokud máte špatné dotazy provádějící skenování tabulek nebo tabulky nepoužívající indexy prohlížením čítačů read_* atd.
- Nejvyšší počítadla příkazů (za hodinu)
Toto jsou grafy, které byste pravděpodobně museli zkontrolovat, kdykoli byste chtěli vidět statistiky pro vložení, odstranění, aktualizace, provedené příkazy, jako je shromažďování seznamu procesů, stav podřízeného zařízení, stav zobrazení (statistiky zdraví serveru MySQL ), a mnoho dalších. Toto je dobré místo, pokud chcete zkontrolovat, jaké čítače příkazů MySQL jsou nejvyšší a zda je potřeba nějaké ladění výkonu nebo optimalizace dotazů. Může vám také umožnit identifikovat, které příkazy běží agresivně, aniž byste to potřebovali. - Obslužné rutiny MySQL
DBA často tyto obslužné programy prošel a zkontroloval, jak si vedou dotazy na vašem serveru MySQL. V podstatě tento graf pokrývá čítače z Handler API MySQL. Nejběžnější čítače handlerů pro DBA pro úložiště API v MySQL jsou Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd a Handler_read_rnd_next. Existuje mnoho obslužných programů MySQL, které lze zkontrolovat. Můžete si o nich přečíst v dokumentaci zde. - Obslužné rutiny transakcí MySQL
Pokud váš server MySQL používá transakce XA, příkazy SAVEPOINT, ROLLBACK TO SAVEPOINT. Pak je tento graf dobrým odkazem, na který se můžete podívat. Tento graf můžete také použít ke sledování všech interních potvrzení vašeho serveru. Vezměte na vědomí, že počítadlo pro Handler_commit se zvyšuje i pro příkazy SELECT, ale liší se od příkazů insert/update/delete, které přecházejí do binárního protokolu během volání příkazu COMMIT.
Následující graf ukazuje trendy o stavech procesů a jejich hodinovém využití. V legendě sloupcového grafu je zde mnoho klíčových bodů, které by DBA zkontroloval. Setkáte se s problémy s místem na disku, problémy s připojením a zjistěte, zda váš fond připojení funguje podle očekávání, s vysokým I/O na disku, problémy se sítí atd.
- Stavy procesu/Nejvyšší stavy procesu každou hodinu
Tento graf je místo, kde můžete sledovat stavy horních vláken vašich dotazů spuštěných v seznamu procesů. To je velmi informativní a užitečné pro takové úlohy DBA, kde zde můžete prozkoumat všechny zbývající stavy, které je třeba vyřešit. Například otevírání tabulek stav je velmi vysoký a jeho minimální hodnota se téměř blíží maximální hodnotě. To by mohlo znamenat, že potřebujete upravit table_open_cache. Pokud statistiky je vysoká a zaznamenáváte zpomalení vašeho serveru, mohlo by to znamenat, že váš server je vázán na disk a možná budete muset zvážit zvýšení fondu vyrovnávací paměti. Pokud máte vysoký počet vytváření tabulky tmp pak možná budete muset zkontrolovat svůj pomalý protokol a optimalizovat problematické dotazy. Úplný seznam stavů vláken MySQL si můžete prohlédnout v příručce zde.
Další graf, který budeme kontrolovat, se týká mezipaměti dotazů, mezipaměti definic tabulky MySQL a toho, jak často MySQL otevírá systémové soubory.
- Paměť/aktivita mezipaměti dotazů MySQL
Tyto grafy spolu souvisí. Pokud máte query_cache_size <> 0 a query_cache_type <> 0, pak vám může pomoci tento graf. V novějších verzích MySQL však byla mezipaměť dotazů označena jako zastaralá, protože je známo, že mezipaměť dotazů MySQL způsobuje problémy s výkonem. Možná to v budoucnu nebudete potřebovat. Nejnovější verze MySQL 8.0 má drastická vylepšení; má tendenci zvyšovat výkon, protože přichází s několika strategiemi pro zpracování informací z mezipaměti ve vyrovnávacích pamětích. - Otevření souborů MySQL
Tento graf ukazuje trend pro otevřené soubory od doby provozu serveru MySQL, ale nezahrnuje soubory, jako jsou zásuvky nebo roury. Nezahrnuje také soubory, které jsou otevřeny modulem úložiště, protože mají svůj vlastní čítač, kterým je Innodb_num_open_files. - Otevřené soubory MySQL
Tento graf je místo, kde chcete zkontrolovat aktuálně otevřené soubory InnoDB, aktuálně otevřené soubory MySQL a proměnnou open_files_limit. - Stav otevřené mezipaměti tabulky MySQL
Pokud zde máte nastavenou velmi nízkou tabulku table_open_cache, tento graf vám řekne o těch tabulkách, které selžou do mezipaměti (nově otevřené tabulky) nebo chybí kvůli přetečení. Pokud ve svém seznamu procesů narazíte na vysoký počet nebo příliš mnoho stavu „Otevírací tabulky“, tento graf vám poslouží jako reference, abyste to zjistili. To vám řekne, zda je potřeba zvýšit proměnnou table_open_cache. - Otevřené tabulky MySQL
Ve srovnání se stavem otevřené mezipaměti tabulky MySQL je tento graf užitečný při určitých příležitostech, jako když chcete zjistit, zda je potřeba zvýšit vaši table_open_cache nebo ji snížit, pokud zaznamenáte vysoký nárůst otevřených tabulek nebo stavové proměnné Open_tables . Všimněte si, že table_open_cache může zabírat velké množství místa v paměti, takže to musíte nastavovat opatrně, zejména v produkčních systémech. - Mezipaměť definice tabulky MySQL
Pokud chcete zkontrolovat počet stavových proměnných Open_table_definitions a Opened_table_definitions, pak potřebujete tento graf. U novějších verzí MySQL (>=5.6.8) možná nebudete muset měnit hodnotu této proměnné a používat výchozí hodnotu, protože má funkci automatické změny velikosti.
Závěr
Doplněk SCUMM v nejnovější verzi ClusterControl 1.7.0 poskytuje významné nové výhody pro řadu klíčových úloh DBA. Nové grafy mohou pomoci snadno určit příčinu problémů, se kterými by se správci databází nebo systémoví správci obvykle museli vypořádat, a pomoci rychleji najít vhodná řešení.
Rádi bychom slyšeli vaše zkušenosti a názory na používání ClusterControl 1.7.0 se SCUMM (který si můžete zdarma stáhnout – ClusterControl Community).
V části 2 tohoto blogu se budu zabývat efektivním monitorováním replikace MySQL pomocí řídicích panelů SCUMM.