Vi har lagt till ett antal nya instrumentpaneler för MySQL i vår senaste version av ClusterControl 1.7.0. - och i vår tidigare blogg visade vi dig hur du övervakar din ProxySQL med Prometheus och ClusterControl.
I den här bloggen kommer vi att titta på MySQL Overview dashboard.
Så vi har aktiverat agentbaserad övervakning under fliken Dashboard för att börja samla in mätvärden till noderna. Observera att när du aktiverar agentbaserad övervakning har du möjlighet att ställa in "Scrape Interval (seconds) ” och ”Datalagring (dagar) ”. Skrapningsintervall är där du vill ställa in hur aggressivt Prometheus ska hämta data från målet och datalagring är hur länge du vill behålla din data som samlas in av Prometheus innan den raderas.
När det är aktiverat kan du identifiera vilket kluster som har agenter och vilket som har agentfri övervakning.
Jämfört med det agentlösa tillvägagångssättet kommer granulariteten i dina data i diagram att vara högre med agenter.
MySQL-graferna
Den senaste versionen av ClusterControl 1.7.0 (som du kan ladda ner gratis - ClusterControl Community) har följande MySQL Dashboards för vilka du kan samla information för dina MySQL-servrar. Dessa är MySQL Overview, MySQL InnoDB Metrics, MySQL Performance Schema och MySQL Replication.
Vi kommer att täcka i detalj de grafer som är tillgängliga i MySQL Overview-instrumentpanelen.
Dashboard för MySQL-översikt
Den här instrumentpanelen innehåller de vanliga viktiga variablerna eller information om hälsan hos din MySQL-nod. Diagrammen på den här instrumentpanelen är specifika för den nod som valdes när du tittade på instrumentpanelerna enligt nedan:
Den består av 26 grafer, men du kanske inte behöver alla dessa när du ska diagnostisera problem. Dessa grafer ger dock en viktig representation av den övergripande statistiken för dina MySQL-servrar. Låt oss gå igenom de grundläggande, eftersom dessa förmodligen är de vanligaste sakerna som en DBA rutinmässigt kommer att titta på.
De fyra första graferna som visas ovan tillsammans med MySQL:s drifttid, fråga per sekunder och buffertpoolinformation är de mest grundläggande tipsen vi kan behöva. Från graferna som visas ovan, här är deras representationer:
- MySQL-anslutningar
Det är här du vill kontrollera dina totala klientanslutningar hittills tilldelade under en viss tidsperiod. - Trådaktivitet för MySQL-klient
Det finns tillfällen då din MySQL-server kan vara mycket upptagen. Det kan till exempel förväntas ta emot en ökning av trafiken vid en specifik tidpunkt, och du vill övervaka din löpande trådaktivitet. Den här grafen är verkligen viktig att titta på. Det kan finnas tillfällen din frågeprestanda kan gå söderut om, till exempel, en stor uppdatering får andra trådar att vänta på att få lås. Detta skulle leda till ett ökat antal av dina löpande trådar. Cacheminnets missfrekvens beräknas som Threads_created/Connections. - MySQL-frågor
Det här är frågorna som körs under en viss tidsperiod. En tråd kan vara en transaktion som består av flera frågor och det här kan vara ett bra diagram att titta på. - MySQL Thread Cache
Den här grafen visar värdet för thread_cache_size, trådar som är cachade (trådar som återanvänds) och trådar som skapas (nya trådar). Du kan kontrollera den här grafen för sådana tillfällen som att du behöver justera dina läsfrågor när du märker ett stort antal inkommande anslutningar och dina skapade trådar ökar snabbt. Till exempel, om din Threads_running / thread_cache_size> 2 kan öka din thread_cache_size ge en prestandahöjning till din server. Observera att det är dyrt att skapa och förstöra trådar. Men i de senaste versionerna av MySQL (>=5.6.8) har denna variabel automatisk storlek som standard som du kanske anser vara orörd.
De nästa fyra graferna är MySQL Temporary Objects, MySQL Select Types, MySQL Sorts och MySQL Slow Queries. Dessa grafer är relaterade till varandra speciellt om du diagnostiserar långvariga frågor och stora frågor som behöver optimeras.
- Tillfälliga MySQL-objekt
Den här grafen skulle vara en bra källa att lita på om du vill övervaka långvariga frågor som skulle sluta använda disk istället för tillfälliga tabeller eller filer som hamnar i minnet. Det är ett bra ställe att börja leta efter periodiska förekomster av frågor som kan lägga till för att skapa problem med diskutrymme, särskilt under udda tider. - MySQL Select Types
En källa till dålig prestanda är frågor som använder fullständiga kopplingar, tabellsökningar, välj intervall som inte använder några index. Det här diagrammet skulle visa hur din fråga presterar och vad bland listan från fullständiga kopplingar till kopplingar i hela intervallet, välj intervall, tabellgenomsökningar som har de högsta trenderna. - MySQL-sorteringar
Diagnostisera de frågor som använder sortering och de som tar lång tid att slutföra. - MySQL långsamma frågor
Trender för dina långsamma frågor samlas här på den här grafen. Detta är mycket användbart, särskilt för att diagnostisera hur ofta dina frågor är långsamma. Vad är det för saker som behöver trimmas? Det kan vara en för liten buffertpool, tabeller som saknar index och genomsöker en hel tabell, logiska säkerhetskopior som körs enligt ett oväntat schema, etc. Att använda vår Query Monitor i ClusterControl tillsammans med denna graf är fördelaktigt, eftersom det hjälper till att avgöra långsamma frågor.
Nästa grafer vi har täcker är mer av nätverksaktivitet, tabelllås och det underliggande internminnet som MySQL förbrukar under MySQL:s aktivitet.
- MySQL avbrutna anslutningar
Antalet avbrutna anslutningar kommer att visas på denna graf. Detta täcker de avbrutna klienterna som där nätverket stängdes abrupt eller där internetanslutningen var nere eller avbröts. Den registrerar också de avbrutna anslutningarna eller försöken som fel lösenord eller dåliga paket när en anslutning upprättas från klienten. - MySQL-tabelllås
Trender för tabeller som begär ett bordslås som har beviljats omedelbart och för tabeller som begär ett lås som inte har förvärvats omedelbart. Om du till exempel har lås på tabellnivå på MyISAM-tabeller och inkommande förfrågningar från samma bord, kan dessa inte beviljas omedelbart. - MySQL-nätverkstrafik
Det här diagrammet visar trenderna för inkommande och utgående nätverksaktivitet i MySQL-servern. "Inkommande" är data som tas emot av MySQL-servern medan "Utgående" är data som skickas eller överförs av servern från MySQL-servern. Den här grafen är bäst att kontrollera om du vill övervaka din nätverkstrafik, särskilt när du diagnostiserar om din trafik är måttlig men du undrar varför den har en mycket hög utgående överförd data, som till exempel BLOB-data. - Användning av MySQL-nätverk varje timme
Samma som nätverkstrafiken som visar mottagna och skickade data. Observera att den är baserad på "per timme" och märkt med "sista dagen" som inte följer den tidsperiod du valde i datumväljaren. - Översikt över MySQL internminne
Den här grafen är bekant för en erfaren MySQL DBA. Var och en av dessa förklaringar i stapeldiagrammet är mycket viktiga, särskilt om du vill övervaka din minnesanvändning, din buffertpoolanvändning eller din adaptiva hashindexstorlek.
Följande grafer visar räknarna som en DBA kan lita på som att kontrollera statistiken till exempel, statistiken för urval, infogar, uppdateringar, antalet masterstatus som har exekveras, antalet VISA VARIABLER som har exekveras, kontrollera om du har dåliga frågor som gör tabellsökningar eller tabeller som inte använder index genom att titta över read_*-räknare, etc.
- Översta kommandoräknare (varje timme)
Det här är graferna du förmodligen måste kontrollera när du vill se statistiken för dina infogningar, borttagningar, uppdateringar, utförda kommandon som att samla in processlistan, slavstatus, visa status (hälsostatistik för MySQL-servern ), och många fler. Det här är ett bra ställe om du vill kontrollera vilken typ av MySQL-kommandoträknare som är överst och om någon prestandajustering eller frågeoptimering behövs. Det kan också tillåta dig att identifiera vilka kommandon som körs aggressivt samtidigt som du inte behöver det. - MySQL-hanterare
Ofta går en DBA över dessa hanterare och kontrollerar hur frågorna fungerar på din MySQL-server. I grund och botten täcker denna graf räknarna från Handler API i MySQL. De vanligaste hanterarräknare för en DBA för lagrings-API:et i MySQL är Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd och Handler_read_rnd_next. Det finns massor av MySQL-hanterare att kontrollera. Du kan läsa om dem i dokumentationen här. - MySQL-transaktionshanterare
Om din MySQL-server använder XA-transaktioner, SAVEPOINT, ROLLBACK TO SAVEPOINT-satser. Då är denna graf en bra referens att titta på. Du kan också använda denna graf för att övervaka alla din servers interna commits. Observera att räknaren för Handler_commit ökar även för SELECT-satser men skiljer sig från insert/update/delete-satser som går till den binära loggen under ett anrop till COMMIT-sats.
Nästa graf kommer att visa trender om processtillstånd och deras användning per timme. Det finns många nyckelpunkter här i stapeldiagramförklaringen som en DBA skulle kontrollera. Stöter på problem med diskutrymme, anslutningsproblem och se om din anslutningspool fungerar som förväntat, hög disk I/O, nätverksproblem, etc.
- Processtillstånd/Översta processtillstånd per timme
Det här diagrammet är där du kan övervaka topptrådstillstånden för dina frågor som körs i processlistan. Detta är mycket informativt och användbart för sådana DBA-uppgifter där du här kan undersöka alla utestående statusar som behöver lösas. Till exempel öppningstabeller tillståndet är mycket högt och dess lägsta värde är nästan nära maxvärdet. Detta kan tyda på att du behöver justera table_open_cachen. Om statistik är hög och du märker att din server saktar ner, kan detta tyda på att din server är diskbunden och du kan behöva överväga att öka din buffertpool. Om du har ett stort antal skapande tmp-tabeller då kanske du måste kontrollera din långsamma logg och optimera de stötande frågorna. Du kan kolla in manualen för den fullständiga listan över MySQL-trådstillstånd här.
Nästa graf vi ska kontrollera handlar om frågecache, MySQL-tabelldefinitionscache, hur ofta MySQL öppnar systemfiler.
- MySQL Query Cache-minne/aktivitet
Dessa grafer är relaterade till varandra. Om du har query_cache_size <> 0 och query_cache_type <> 0, så kan den här grafen vara till hjälp. Men i de nyare versionerna av MySQL har frågecachen markerats som föråldrad eftersom MySQL-frågecachen är känd för att orsaka prestandaproblem. Du kanske inte behöver detta i framtiden. Den senaste versionen av MySQL 8.0 har drastiska förbättringar; det tenderar att öka prestanda eftersom det kommer med flera strategier för att hantera cacheinformation i minnesbuffertar. - MySQL-filöppningar
Det här diagrammet visar trenden för de öppnade filerna sedan MySQL-serverns drifttid men det exkluderar filer som sockets eller pipes. Det inkluderar inte heller filer som öppnas av lagringsmotorn eftersom de har en egen räknare som är Innodb_num_open_files. - MySQL Öppna filer
Det här diagrammet är där du vill kontrollera dina InnoDB-filer som för närvarande hålls öppna, de nuvarande öppna MySQL-filerna och din open_files_limit-variabel. - MySQL Table Open Cache Status
Om du har mycket låg table_open_cache inställd här, kommer denna graf att berätta om de tabeller som misslyckas med cachen (nyöppnade tabeller) eller missar på grund av översvämning. Om du stöter på ett högt antal eller för mycket "Öppningstabeller"-status i din processlista, kommer denna graf att fungera som din referens för att fastställa detta. Detta kommer att tala om för dig om det finns ett behov av att öka din table_open_cache-variabel. - MySQL öppna tabeller
I förhållande till MySQL Table Open Cache Status, är den här grafen användbar vid vissa tillfällen som du vill identifiera om det finns ett behov av att öka din table_open_cache eller sänka den om du märker en hög ökning av öppna tabeller eller Open_tables statusvariabel . Observera att table_open_cache kan ta en stor mängd minnesutrymme så du måste ställa in detta med försiktighet, särskilt i produktionssystem. - MySQL Table Definition Cache
Om du vill kontrollera antalet statusvariabler för Open_table_definitions och Opened_table_definitions, då är det här diagrammet du behöver. För nyare versioner av MySQL (>=5.6.8) kanske du inte behöver ändra värdet på den här variabeln och använda standardvärdet eftersom den har funktionen för automatisk storleksändring.
Slutsats
SCUMM-tillägget i den senaste versionen av ClusterControl 1.7.0 ger betydande nya fördelar för ett antal viktiga DBA-uppgifter. De nya graferna kan hjälpa till att enkelt fastställa orsaken till problem som DBA:er eller systemadministratörer vanligtvis måste hantera och hjälpa till att hitta lämpliga lösningar snabbare.
Vi vill gärna höra dina erfarenheter och tankar om att använda ClusterControl 1.7.0 med SCUMM (som du kan ladda ner gratis - ClusterControl Community).
I del 2 av den här bloggen kommer jag att diskutera effektiv övervakning av MySQL-replikering med SCUMM Dashboards.