V našem předchozím blogu o řídicích panelech SCUMM jsme se podívali na řídicí panel s přehledem MySQL. Nová verze ClusterControl (ver. 1.7) nabízí řadu grafů s vysokým rozlišením užitečných metrik a prošli jsme význam každé z metrik a to, jak vám pomáhají při odstraňování problémů s vaší databází. V tomto blogu se podíváme na řídicí panel replikace MySQL. Pokračujme v podrobnostech tohoto řídicího panelu o tom, co nabízí.
Řídicí panel replikace MySQL
MySQL Replication Dashboard nabízí velmi přímočaré sady grafů, které usnadňují monitorování vašeho hlavního serveru MySQL a repliky (replik). Počínaje shora ukazuje nejdůležitější proměnné a informace pro určení stavu repliky nebo dokonce předlohy. Tento řídicí panel nabízí velmi užitečnou součást při kontrole zdraví podřízených nebo master v nastavení master-master. Na tomto řídicím panelu lze také zkontrolovat vytvoření binárního protokolu mastera a určit celkový rozměr, pokud jde o generovanou velikost, v konkrétním daném časovém období.
První věc na tomto řídicím panelu vám poskytuje nejdůležitější informace, které byste mohli potřebovat pro stav vaší repliky. Viz graf níže:
V zásadě vám ukáže IO_Thread, SQL_Thread, chybu replikace a pokud má povolenou proměnnou pouze pro čtení, zobrazí se vám vlákno Slave. Z výše uvedeného ukázkového snímku obrazovky všechny informace ukazují, že můj slave 192.168.70.20 je v pořádku a běží normálně.
Kromě toho má ClusterControl informace, které lze také shromáždit, pokud přejdete na Cluster -> Overview. Přejděte dolů a uvidíte graf níže:
Dalším místem k zobrazení nastavení replikace je zobrazení topologie nastavení replikace, které je dostupné v Cluster -> Topology. Poskytuje rychlým pohledem pohled na různé uzly v nastavení, jejich role, zpoždění replikace, načtené GTID a další. Viz graf níže:
Kromě toho Topology View také zobrazuje všechny různé uzly, které tvoří součást vašeho databázového clusteru, ať už jde o databázové uzly, zátěžové balancéry (ProxySQL/MaxScale/HaProxy) nebo arbitry (garbd), stejně jako spojení mezi nimi. ClusterControl zjišťuje uzly, připojení a jejich stavy. Protože ClusterControl nepřetržitě monitoruje uzly a uchovává informace o stavu, všechny změny v topologii se projeví ve webovém rozhraní. V případě, že je hlášeno selhání uzlů, můžete použít toto zobrazení spolu s řídicími panely SCUMM a zjistit, jaký dopad to může způsobit.
Zobrazení topologie má určitou podobnost s nástrojem Orchestrator, ve kterém můžete spravovat uzly, měnit předlohy přetažením objektu na požadovanou předlohu, restartovat uzly a synchronizovat data. Chcete-li se dozvědět více o našem zobrazení topologie, doporučujeme vám přečíst si náš předchozí blog – “Vizualizace topologie clusteru v ClusterControl”.
Nyní pokračujme s grafy.
-
Zpoždění replikace MySQL
Tento graf zná každý, kdo spravuje MySQL, zejména ti, kteří denně pracují na nastavení master-slave. Tento graf obsahuje trendy pro všechna zpoždění zaznamenaná v určitém časovém rozsahu specifikovaném na tomto panelu. Kdykoli chceme zkontrolovat periodický čas pádu, který má naše replika, pak je dobré se na tento graf podívat. Existují určité případy, kdy se replika může zpozdit z podivných důvodů, jako je váš RAID má degradovaný BBU a potřebuje výměnu, tabulka nemá jedinečný klíč, ale není na hlavním serveru, nechtěné úplné prohledání tabulky nebo úplné prohledání indexu nebo špatný dotaz. nechal běžet vývojář. To je také dobrý indikátor pro určení, zda je zpoždění slave klíčovým problémem, pak možná budete chtít využít výhody paralelní replikace. -
Velikost Binlogu
Tyto grafy spolu souvisí. Graf Binlog Size ukazuje, jak váš uzel generuje binární protokol, a pomáhá určit jeho rozměr na základě doby, kterou skenujete. -
Data Binlog zapisovaná každou hodinu
Data Binlog zapisovaná každou hodinu je graf založený na aktuálním dni a zaznamenaném předchozím dni. To může být užitečné, kdykoli chcete zjistit, jak velký je váš uzel, který přijímá zápisy, což můžete později použít pro plánování kapacity.
-
Počet Binlogů
Řekněme, že v daný týden očekáváte vysokou návštěvnost. Chcete porovnat, jak velké zápisy procházejí vaším hlavním a podřízeným zařízením s předchozím týdnem. Tento graf je velmi užitečný pro tento druh situace - Chcete-li zjistit, jak vysoké byly generované binární protokoly na samotném masteru nebo dokonce na slave, pokud je povolena proměnná log_slave_updates. Tento indikátor můžete také použít k určení vygenerovaných binárních dat protokolu master vs. slaves, zejména pokud filtrujete některé tabulky nebo schémata (replicate_ignore_db, replicate_ignore_table, replicate_wild_do_table) na svých podřízených zařízeních, které byly vygenerovány, když je povolen log_slave_updates. -
Binlogy vytvářené každou hodinu
Tento graf je rychlým přehledem pro porovnání vašich binlogů vytvářených každou hodinu od včerejšího a dnešního data. -
Relay Log Space
Tento graf slouží jako základ vygenerovaných reléových protokolů z vaší repliky. Při použití spolu s grafem zpoždění replikace MySQL pomáhá určit, jak velký je počet generovaných protokolů přenosu, což musí správce vzít v úvahu z hlediska dostupnosti disku aktuální repliky. Může to způsobit potíže, když váš slave přísně zaostává a generuje velké množství protokolů přenosu. To může rychle spotřebovat místo na disku. Existují určité situace, kdy se kvůli vysokému počtu zápisů z masteru bude slave/replika ohromně zpožďovat, takže generování velkého množství protokolů může na této replice způsobit vážné problémy. To může operačnímu týmu pomoci, když mluví s vedením o kapacitním plánování. -
Relay Log zapisovaný každou hodinu
Stejný jako Relay Log Space, ale přidává rychlý přehled pro porovnání vašich reléových protokolů zapsaných ze včerejška a dnešního data.
Závěr
Zjistili jste, že použití SCUMM k monitorování replikace MySQL zvyšuje produktivitu a efektivitu provozního týmu. Použití funkcí, které máme z předchozích verzí, v kombinaci s grafy poskytnutými se SCUMM je jako jít do posilovny a vidět masivní zlepšení ve vaší produktivitě. To je to, co SCUMM může nabídnout:monitorování steroidů! (nyní neobhajujeme, že byste měli při návštěvě posilovny brát steroidy!)
V části 3 tohoto blogu budu diskutovat o InnoDB Metrics a MySQL Performance Schema Dashboards.