Vi tilføjede en række nye dashboards til MySQL i vores seneste udgivelse af ClusterControl 1.7.0. - og i vores tidligere blog viste vi dig, hvordan du overvåger din ProxySQL med Prometheus og ClusterControl.
I denne blog vil vi se på MySQL Overview-dashboardet.
Så vi har aktiveret agentbaseret overvågning under fanen Dashboard for at begynde at indsamle metrics til noderne. Vær opmærksom på, at når du aktiverer agentbaseret overvågning, har du mulighed for at indstille "Scrape-interval (sekunder) ” og “Dataopbevaring (dage) ”. Scraping Interval er det sted, hvor du vil indstille, hvor aggressivt Prometheus vil høste data fra målet, og dataopbevaring er, hvor længe du vil beholde dine data indsamlet af Prometheus, før de slettes.
Når det er aktiveret, kan du identificere, hvilken klynge der har agenter, og hvilken der har agentfri overvågning.
Sammenlignet med den agentfri tilgang, vil granulariteten af dine data i grafer være højere med agenter.
MySQL-graferne
Den seneste version af ClusterControl 1.7.0 (som du kan downloade gratis - ClusterControl Community) har følgende MySQL Dashboards, som du kan samle information til dine MySQL-servere om. Disse er MySQL Overview, MySQL InnoDB Metrics, MySQL Performance Schema og MySQL Replication.
Vi vil i detaljer dække de grafer, der er tilgængelige i MySQL Overview-dashboardet.
MySQL Oversigt Dashboard
Dette dashboard indeholder de sædvanlige vigtige variabler eller oplysninger om helbredet for din MySQL-node. Graferne på dette dashboard er specifikke for den node, der er valgt ved visning af dashboards som vist nedenfor:
Den består af 26 grafer, men du behøver muligvis ikke alle disse, når du skal diagnosticere problemer. Disse grafer giver dog en vigtig repræsentation af de overordnede målinger for dine MySQL-servere. Lad os gennemgå de grundlæggende, da disse nok er de mest almindelige ting, som en DBA rutinemæssigt vil se på.
De første fire grafer vist ovenfor sammen med MySQL's oppetid, forespørgsel pr. sekunder og bufferpuljeinformation er de mest grundlæggende pointer, vi kan få brug for. Fra graferne vist ovenfor, her er deres repræsentationer:
- MySQL-forbindelser
Det er her, du vil kontrollere dine samlede klientforbindelser, der hidtil er allokeret i en bestemt periode. - MySQL Client Thread Activity
Der er tidspunkter, hvor din MySQL-server kan være meget travl. For eksempel kan det forventes at modtage stigning i trafikken på et bestemt tidspunkt, og du vil overvåge din løbende trådaktivitet. Denne graf er virkelig vigtig at se på. Der kan være tidspunkter, hvor din forespørgselsydeevne kan gå sydpå, hvis f.eks. en stor opdatering får andre tråde til at vente på at få lås. Dette ville føre til et øget antal af dine løbende tråde. Cache-misfrekvensen beregnes som Threads_created/Connections. - MySQL-spørgsmål
Dette er de forespørgsler, der kører i en bestemt periode. En tråd kan være en transaktion, der består af flere forespørgsler, og dette kan være en god graf at se på. - MySQL Thread Cache
Denne graf viser værdien for thread_cache_size, tråde, der er cachelagret (tråde, der genbruges), og tråde, der oprettes (nye tråde). Du kan tjekke denne graf for sådanne tilfælde som du har brug for at justere dine læseforespørgsler, når du bemærker et højt antal indgående forbindelser, og dine oprettede tråde stiger hurtigt. For eksempel, hvis din Threads_running / thread_cache_size> 2 kan en forøgelse af din thread_cache_size give et ydelsesboost til din server. Vær opmærksom på, at oprettelse og ødelæggelse af tråde er dyre. Men i de seneste versioner af MySQL (>=5.6.8) har denne variabel automatisk størrelse som standard, som du måske betragter den som uberørt.
De næste fire grafer er MySQL Temporary Objects, MySQL Select Types, MySQL Sorts og MySQL Slow Queries. Disse grafer er relateret til hinanden, især hvis du diagnosticerer langvarige forespørgsler og store forespørgsler, der skal optimeres.
- Midlertidige MySQL-objekter
Denne graf ville være en god kilde at stole på, hvis du ønsker at overvåge langvarige forespørgsler, der ville ende med at bruge disk i stedet for midlertidige tabeller eller filer, der bliver gemt i hukommelsen. Det er et godt sted at begynde at lede efter periodiske forekomster af forespørgsler, der kan tilføje op til problemer med diskplads, især under skæve tider. - MySQL Vælg typer
En kilde til dårlig ydeevne er forespørgsler, der bruger fulde joinforbindelser, tabelscanninger, udvalgte område, der ikke bruger nogen indekser. Denne graf viser, hvordan din forespørgsel klarer sig, og hvad blandt listen fra fulde koblinger til fulde bånd, vælg område, tabelscanninger har de højeste tendenser. - MySQL-sortering
Diagnosticering af de forespørgsler, der bruger sortering, og dem, der tager lang tid at afslutte. - Langsomme MySQL-forespørgsler
Tendenser for dine langsomme forespørgsler er samlet her på denne graf. Dette er meget nyttigt, især til at diagnosticere, hvor ofte dine forespørgsler er langsomme. Hvad er det, der skal tunes? Det kan være for lille bufferpulje, tabeller, der mangler indekser og scanner hele tabellen, logiske sikkerhedskopier, der kører på uventet tidsplan, osv. Det er en fordel at bruge vores Query Monitor i ClusterControl sammen med denne graf, da det hjælper med at bestemme langsomme forespørgsler.
De næste grafer, vi har dækket, er mere af netværksaktiviteten, tabellåse og den underliggende interne hukommelse, som MySQL bruger under MySQL'ens aktivitet.
- MySQL afbrudte forbindelser
Antallet af afbrudte forbindelser gengives på denne graf. Dette dækker de afbrudte klienter, såsom hvor netværket blev lukket brat, eller hvor internetforbindelsen var nede eller afbrudt. Den registrerer også de afbrudte forbindelser eller forsøg som f.eks. forkerte adgangskoder eller dårlige pakker ved etablering af en forbindelse fra klienten. - MySQL-bordlåse
Tendenser for tabeller, der anmoder om en bordlås, der er givet med det samme, og for tabeller, der anmoder om en lås, der ikke er anskaffet med det samme. Hvis du f.eks. har låse på tabelniveau på MyISAM-tabeller og indgående anmodninger fra samme tabel, kan disse ikke gives med det samme. - MySQL-netværkstrafik
Denne graf viser tendenserne for den indgående og udgående netværksaktivitet i MySQL-serveren. "Inbound" er de data, der modtages af MySQL-serveren, mens "Outbound" er de data, der sendes eller overføres af serveren fra MySQL-serveren. Denne graf er bedst at kontrollere, hvis du vil overvåge din netværkstrafik, især når du diagnosticerer, om din trafik er moderat, men du undrer dig over, hvorfor den har en meget høj udgående overførte data, som f.eks. BLOB-data. - MySQL-netværksbrug hver time
Samme som netværkstrafikken, der viser de modtagne og sendte data. Vær opmærksom på, at det er baseret på "per time" og mærket med "sidste dag", som ikke følger det tidsrum, du valgte i datovælgeren. - Oversigt over MySQL intern hukommelse
Denne graf er kendt for en erfaren MySQL DBA. Hver af disse forklaringer i søjlediagrammet er meget vigtige, især hvis du vil overvåge dit hukommelsesforbrug, din bufferpuljebrug eller din adaptive hash-indeksstørrelse.
Følgende grafer viser de tællere, som en DBA kan stole på, såsom kontrol af statistikkerne, f.eks. statistikken for valg, indsættelser, opdateringer, antallet af masterstatus, der er blevet udført, antallet af VIS VARIABLER, der er blevet udført, tjek hvis du har dårlige forespørgsler, der laver tabelscanninger eller tabeller, der ikke bruger indekser ved at se over read_*-tællerne osv.
- Top kommandotællere (hver time)
Dette er de grafer, du sandsynligvis skal tjekke, når du vil se statistikkerne for dine indsættelser, sletninger, opdateringer, udførte kommandoer såsom indsamling af proceslisten, slavestatus, vis status (sundhedsstatistik for MySQL-serveren ), og mange flere. Dette er et godt sted, hvis du vil kontrollere, hvilken slags MySQL-kommandotællere, der er øverst, og om der er behov for en ydelsesjustering eller forespørgselsoptimering. Det kan også give dig mulighed for at identificere, hvilke kommandoer der kører aggressivt, mens du ikke har brug for det. - MySQL-handlere
Ofte ville en DBA gennemgå disse behandlere og kontrollere, hvordan forespørgslerne klarer sig på din MySQL-server. Grundlæggende dækker denne graf tællerne fra Handler API af MySQL. De mest almindelige handlertællere for en DBA for storage-API'en i MySQL er Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd og Handler_read_rnd_next. Der er masser af MySQL-handlere at tjekke efter. Du kan læse om dem i dokumentationen her. - MySQL Transaction Handlers
Hvis din MySQL-server bruger XA-transaktioner, SAVEPOINT, ROLLBACK TO SAVEPOINT-udsagn. Så er denne graf en god reference at se på. Du kan også bruge denne graf til at overvåge alle din servers interne commits. Bemærk, at tælleren for Handler_commit stiger selv for SELECT-sætninger, men adskiller sig fra insert/update/delete-sætninger, som går til den binære log under et kald til COMMIT-sætning.
Den næste graf viser tendenser om procestilstande og deres timeforbrug. Der er masser af nøglepunkter her i søjlegrafforklaringen, som en DBA ville tjekke. Støder problemer med diskplads, forbindelsesproblemer og se, om din forbindelsespulje fungerer som forventet, høj disk I/O, netværksproblemer osv.
- Procestilstande/Topprocestilstande hver time
Denne graf er, hvor du kan overvåge toptrådstilstandene for dine forespørgsler, der kører i proceslisten. Dette er meget informativt og nyttigt for sådanne DBA-opgaver, hvor du her kan undersøge eventuelle udestående statusser, der skal løses. For eksempel åbningstabeller tilstanden er meget høj, og dens minimumsværdi er næsten tæt på maksimumværdien. Dette kunne indikere, at du skal justere table_open_cachen. Hvis statistikken er høj, og du bemærker, at din server er langsommere, kan dette indikere, at din server er diskbundet, og du skal muligvis overveje at øge din bufferpulje. Hvis du har et højt antal skabende tmp-tabel så skal du måske tjekke din langsomme log og optimere de stødende forespørgsler. Du kan tjekke manualen for den komplette liste over MySQL-trådtilstande her.
Den næste graf, vi skal tjekke, handler om forespørgselscache, MySQL-tabeldefinitionscache, hvor ofte MySQL åbner systemfiler.
- MySQL-forespørgselscachehukommelse/aktivitet
Disse grafer er relateret til hinanden. Hvis du har query_cache_size <> 0 og query_cache_type <> 0, så kan denne graf være til hjælp. I de nyere versioner af MySQL er forespørgselscachen dog blevet markeret som forældet, da MySQL-forespørgselscachen er kendt for at forårsage ydeevneproblemer. Du har muligvis ikke brug for dette i fremtiden. Den seneste version af MySQL 8.0 har drastiske forbedringer; det har en tendens til at øge ydeevnen, da det kommer med flere strategier til at håndtere cacheoplysninger i hukommelsesbufferne. - MySQL-filåbninger
Denne graf viser tendensen for de åbnede filer siden MySQL-serverens oppetid, men den udelukker filer såsom sockets eller pipes. Det inkluderer heller ikke filer, der åbnes af lagermotoren, da de har deres egen tæller, der er Innodb_num_open_files. - MySQL Åbne filer
Denne graf er det sted, hvor du vil kontrollere dine InnoDB-filer, der i øjeblikket holdes åbne, de aktuelle MySQL-åbne filer og din open_files_limit-variabel. - MySQL Table Open Cache Status
Hvis du har indstillet meget lav table_open_cache her, vil denne graf fortælle dig om de tabeller, der fejler cachen (nyåbnede tabeller) eller mangler på grund af overløb. Hvis du støder på et højt antal eller for meget "Åbningstabeller"-status i din procesliste, vil denne graf tjene som din reference til at bestemme dette. Dette vil fortælle dig, om der er behov for at øge din table_open_cache-variabel. - MySQL åbne tabeller
I forhold til MySQL Table Open Cache Status, er denne graf nyttig i visse tilfælde, som du vil identificere, om der er behov for at øge din table_open_cache eller sænke den ned, hvis du bemærker en høj stigning i åbne tabeller eller Open_tables statusvariabel . Bemærk, at table_open_cache kan tage en stor mængde hukommelse, så du skal indstille dette med omhu, især i produktionssystemer. - MySQL Table Definition Cache
Hvis du vil tjekke antallet af dine Open_table_definitions og Opened_table_definitions statusvariabler, så er denne graf, hvad du har brug for. For nyere versioner af MySQL (>=5.6.8), behøver du muligvis ikke at ændre værdien af denne variabel og bruge standardværdien, da den har en automatisk størrelsesfunktion.
Konklusion
SCUMM-tilføjelsen i den seneste version af ClusterControl 1.7.0 giver betydelige nye fordele for en række vigtige DBA-opgaver. De nye grafer kan hjælpe med nemt at lokalisere årsagen til problemer, som DBA'er eller sysadmins typisk vil skulle håndtere, og hjælpe med at finde passende løsninger hurtigere.
Vi vil meget gerne høre dine erfaringer og tanker om at bruge ClusterControl 1.7.0 med SCUMM (som du kan downloade gratis - ClusterControl Community).
I del 2 af denne blog vil jeg diskutere effektiv overvågning af MySQL-replikering med SCUMM Dashboards.