Overvågning er et must i alle miljøer, og databaser er ikke undtagelsen. Når du har din databaseinfrastruktur oppe og køre, bliver du nødt til at holde styr på, hvad der sker. Overvågning er et must, hvis du vil være sikker på, at alt går fint, men også hvis du foretager de nødvendige justeringer, mens dit system vokser og udvikler sig. Det vil gøre dig i stand til at identificere tendenser, planlægge opgraderinger eller forbedringer eller reagere tilstrækkeligt på eventuelle problemer eller fejl, der måtte opstå med nye versioner, forskellige formål og så videre.
For hver databaseteknologi er der forskellige ting at overvåge. Nogle af disse er specifikke for databasemotoren, leverandøren eller endda den særlige version, du bruger. Databaseklynger er stærkt afhængige af den underliggende infrastruktur, så netværks- og driftsstatistik er også interessant at se af databaseadministratorerne.
Når du kører flere databasesystemer, kan overvågningen af disse systemer blive noget af en opgave.
I denne blog tager vi et kig på, hvad du skal bruge for at overvåge et MySQL 8.0-miljø. Vi vil også tage et kig på funktioner til overvågning af klyngekontrol, som kan hjælpe dig med at spore dine databasers tilstand gratis.
Overvågning af operativsystem og database
Når du observerer en databaseklynge eller -node, er der to hovedpunkter at tage hensyn til:operativsystemet og selve MySQL-forekomsten. Du bliver nødt til at definere, hvilke målinger du vil overvåge fra begge sider, og hvordan du vil gøre det. Du skal altid følge parameteren i dit systems betydning, og du bør se efter ændringer i adfærdsmodellen.
Tænk på, at når en af dine parametre påvirkes, kan det også påvirke andre, hvilket gør fejlfinding af problemet mere kompliceret. At have et ordentligt overvågnings- og alarmsystem er afgørende for at gøre denne opgave så enkel som muligt.
I de fleste tilfælde bliver du nødt til at bruge nogle værktøjer, da det er svært at finde et til at dække alle de ønskede målinger.
OS Systemovervågning
En vigtig ting (som er fælles for alle databasemotorer og endda for alle systemer) er at overvåge operativsystemets adfærd. Her er nogle punkter at tjekke her. Nedenfor kan du finde de bedste systemressourcer til at se på en databaseserver. Det er faktisk også listen over de allerførste ting, du skal tjekke.
CPU-brug
Et højt CPU-forbrug er ikke en dårlig ting, så længe du ikke når grænsen. For høj procentdel af CPU-brug kan være et problem, hvis det ikke er normal adfærd. I dette tilfælde er det vigtigt at identificere processen/processerne, der genererer dette problem. Hvis problemet er databaseprocessen, skal du kontrollere, hvad der sker inde i databasen.
RAM-hukommelse eller SWAP-brug
Ideelt set bør hele din database være gemt i hukommelsen, men det er ikke altid muligt. Giv MySQL så meget, du har råd til, men efterlad nok til, at andre processer kan fungere.
Hvis du ser en høj værdi for denne metrik, og intet er ændret i dit system, skal du sandsynligvis tjekke din databasekonfiguration. Parametre som shared_buffers og work_mem kan påvirke dette direkte, da de definerer mængden af hukommelse, der skal kunne bruges til MySQL-databasen. Swap er kun til nødstilfælde, og det bør ikke bruges, sørg for at du også har dit operativsystem indstillet til at lade MySQL beslutte om swap-brug.
Diskbrug
Diskbrug er en af nøglemålingerne til at overvåge og advare. Sørg for, at du altid har ledig plads til nye data, midlertidige filer, snapshots eller sikkerhedskopier.
Overvågning af hårde metriske værdier er ikke godt nok. En unormal stigning i brugen af diskplads eller et for stort forbrug af diskadgang er vigtige ting at se, da du kan have et stort antal fejl logget i MySQL-logfilen eller en elendig cache-konfiguration, der kan generere et vigtigt diskadgangsforbrug i stedet for bruge hukommelse til at behandle forespørgslerne. Sørg for, at du er i stand til at fange unormal adfærd, selvom din advarsel og kritiske målinger ikke er nået endnu.
Sammen med overvågningsplads bør vi også overvåge diskaktivitet. De øverste værdier at overvåge er:
- Læse-/skriveanmodninger
- IO-kølængde
- Gennemsnitlig IO-ventetid
- Gennemsnitlig læse-/skrivetid
- Læse-/skrivebåndbredde
Du kan bruge iostat eller pt-diskstats fra Percona for at se alle disse detaljer.
Ting, der kan påvirke din diskydeevne, er ofte relateret til dataoverførsel fra og mod din disk, så overvåg unormale processer, end der kan startes fra andre brugere.
Indlæsningsgennemsnit
En alt-i-en præstationsmåling. At forstå Linux Load er en nøgle til at overvåge OS og databaseafhængige systemer.
Belastningsgennemsnit relateret til de tre punkter nævnt ovenfor. Et højt belastningsgennemsnit kan genereres af en overdreven CPU-, RAM- eller diskbrug.
Netværk
Medmindre der laves sikkerhedskopier eller overføres enorme mængder data, burde det ikke være flaskehalsen.
Et netværksproblem kan påvirke alle systemerne, da applikationen ikke kan oprette forbindelse (eller forbinde tabende pakker) til databasen, så dette er en vigtig metrik at overvåge. Du kan overvåge latens eller pakketab, og hovedproblemet kan være en netværksmætning, et hardwareproblem eller bare en elendig netværkskonfiguration.
Databaseovervågning
Selvom overvågning er et must, er det normalt ikke gratis. Der er altid en omkostning på databasens ydeevne, afhængigt af hvor meget du overvåger, så du bør undgå at overvåge ting, som du ikke vil bruge.
Generelt er der to måder at overvåge dine databaser på, fra logfilerne eller fra databasesiden ved at forespørge.
I tilfælde af logs, for at kunne bruge dem, skal du have et højt logningsniveau, hvilket genererer høj diskadgang, og det kan påvirke ydeevnen af din database.
For forespørgselstilstanden bruger hver forbindelse til databasen ressourcer, så afhængigt af din databases aktivitet og de tildelte ressourcer kan det også påvirke ydeevnen.
Selvfølgelig er der mange metrics i MySQL. Her vil vi fokusere på det vigtigste.
Overvågning af aktive sessioner
Du bør også spore antallet af aktive sessioner og DB op-ned-status. For at forstå problemet skal du ofte se, hvor længe databasen kører. så vi kan bruge dette til at opdage respawns.
Det næste ville være et antal sessioner. Hvis du er tæt på grænsen, skal du tjekke, om der er noget galt, eller om du blot skal øge max_connections-værdien. Forskellen i antallet kan være en stigning eller et fald af forbindelser. Ukorrekt brug af forbindelsespooling, låsning eller netværksproblemer er de mest almindelige problemer relateret til antallet af forbindelser.
Nøgleværdierne her er
- Opetid
- Tråde_forbundne
- Max_used_connections
- Aborted_connects
Databaselåse
Hvis du har en forespørgsel, der venter på en anden forespørgsel, skal du kontrollere, om den anden forespørgsel er en normal proces eller noget nyt. I nogle tilfælde, hvis nogen for eksempel laver en opdatering på et stort bord, kan denne handling påvirke din databases normale adfærd og generere et stort antal låse.
Overvågning af replikering
Nøglemålingerne, der skal overvåges for replikering, er forsinkelsen og replikeringstilstanden. Ikke kun op-ned-status, men også forsinkelse, fordi en kontinuerlig stigning i denne værdi ikke er et særlig godt tegn, da det betyder, at slaven ikke er i stand til at indhente sin herre.
De mest almindelige problemer er netværksproblemer, hardwareressourceproblemer eller problemer med underdimensionering. Hvis du står over for et replikeringsproblem, skal du vide dette hurtigst muligt, da du skal rette det for at sikre et miljø med høj tilgængelighed.
Replikering overvåges bedst ved at kontrollere SLAVE STATUS og følgende parametre:
- SLAVE_RUNNING
- SLAVE_IO_Kører
- SLAVE_SQL_RUNNING
- LAST_SQL_ERRNO
- SECONDS_BEHIND_MASTER
Sikkerhedskopier
Desværre kommer Vanilla Community-udgaven ikke med backup-manageren. Du bør vide, om sikkerhedskopieringen blev gennemført, og om den er brugbar. Normalt tages der ikke højde for dette sidste punkt, men det er nok den mest kritiske kontrol i en backupproces. Her skal vi bruge eksterne værktøjer som percona-xtrabackup eller ClusterControl.
Databaselogfiler
Du bør overvåge din databaselog for fejl som FATAL eller deadlock, eller endda for almindelige fejl som autentificeringsproblemer eller langvarige forespørgsler. De fleste af fejlene er skrevet i logfilen med detaljerede nyttige oplysninger til at rette det. Almindelige fejlpunkter, du skal holde øje med, er fejl, logfilstørrelser. Placeringen af fejlloggen kan findes under variabelen log_error.
Eksterne værktøjer
Sidst men ikke mindst kan du finde en liste over nyttige værktøjer til at overvåge din databaseaktivitet.
Percona Toolkit - er sættet af Linux-værktøjer fra Percona til at analysere MySQL- og OS-aktiviteter. Du kan finde den her. Det understøtter de mest populære 64 bit Linux-distributioner som Debian, Ubuntu og Redhat.
mysqladmin - mysqladmin er et administrationsprogram til MySQL-dæmonen. Det kan bruges til at kontrollere serverens sundhed (ping), liste processerne, se værdierne af variablerne, men også udføre noget administrativt arbejde som oprette/slip databaser, flush (nulstille) logfiler, statistik og tabeller, dræbe kørende forespørgsler, stop serveren og kontroller replikering.
innotop - tilbyder en udvidet visning af SHOW-udsagn. Det er meget kraftfuldt og kan reducere undersøgelsestiden betydeligt. Blandt vanilla MySQL-understøttelse kan du se Galera-visningen og master-slave-replikeringsdetaljer.
mtop - overvåger en MySQL-server, der viser de forespørgsler, der tager mest tid at fuldføre. Funktionerne omfatter at "zoome" ind på en proces for at vise hele forespørgslen, "forklare" forespørgselsoptimeringsoplysningerne for en forespørgsel og "aflive" forespørgsler. Derudover leveres serverydelsesstatistikker, konfigurationsoplysninger og tuning-tip.
Mytop - kører i en terminal og viser statistik om tråde, forespørgsler, langsomme forespørgsler, oppetid, belastning osv. i tabelformat, der ligner Linux
Konklusion
Denne blog er ikke beregnet til at være en udtømmende guide til, hvordan man forbedrer databaseovervågning, men den giver forhåbentlig et klarere billede af, hvilke ting der kan blive væsentlige, og nogle af de grundlæggende parametre, der kan overvåges. Tøv ikke med at fortælle os, hvis vi er gået glip af nogle vigtige i kommentarerne nedenfor.