Størstedelen af DBA’er udfører i ny og næ sundhedstjek på deres databaser. Normalt ville det ske på daglig eller ugentlig basis. Vi har tidligere diskuteret, hvorfor sådanne kontroller er vigtige, og hvad de bør omfatte.
For at sikre, at dine systemer er i god form, skal du gennemgå en hel del information - værtsstatistikker, MySQL-statistikker, arbejdsbelastningsstatistikker, sikkerhedskopieringstilstand, databasepakker, logfiler og så videre. Sådanne data bør være tilgængelige i ethvert korrekt overvåget miljø, selvom det nogle gange er spredt ud over flere lokationer - du kan have et værktøj til at overvåge MySQL-tilstand, et andet værktøj til at indsamle systemstatistik, måske et sæt scripts, f.eks. for at kontrollere tilstanden af dine sikkerhedskopier. Dette gør sundhedstjek meget mere tidskrævende, end de burde være - DBA skal sammensætte de forskellige brikker for at forstå systemets tilstand.
Integrerede værktøjer som ClusterControl har en fordel, at alle bits er placeret på samme sted (eller i samme applikation). Det betyder stadig ikke, at de er placeret ved siden af hinanden - de kan være placeret i forskellige sektioner af brugergrænsefladen, og en DBA skal muligvis bruge lidt tid på at klikke sig igennem brugergrænsefladen for at nå alle de interessante data.
Hele ideen bag oprettelse af driftsrapporter er at samle alle de vigtigste data i et enkelt dokument, som hurtigt kan gennemgås for at få en forståelse af databasernes tilstand.
Driftsrapporter er tilgængelige fra menuen Sidemenu -> Driftsrapporter:
Når du går dertil, vil du blive præsenteret for en liste over rapporter, der er oprettet manuelt eller automatisk, baseret på en foruddefineret tidsplan:
Hvis du vil oprette en ny rapport manuelt, skal du bruge muligheden 'Opret'. Vælg type rapport, klyngenavn (til rapport pr. klynge), e-mail-modtagere (valgfrit - hvis du ønsker, at rapporten skal leveres til dig), og du er stort set færdig:
Rapporterne kan også planlægges til at blive oprettet på regelmæssig basis:
På nuværende tidspunkt er 5 typer rapporter tilgængelige:
- Tilgængelighedsrapport – Alle klynger.
- Sikkerhedskopieringsrapport – Alle klynger.
- Skemaændringsrapport - Kun MySQL/MariaDB-baseret klynge.
- Daglig systemrapport - pr. klynge.
- Pakkeopgraderingsrapport – pr. klynge.
Tilgængelighedsrapport
Tilgængelighedsrapporter fokuserer på, ja, tilgængelighed. Den omfatter tre sektioner. Først tilgængelighedsoversigt:
Du kan se oplysninger om tilgængelighedsstatistikker for dine databaser, klyngetypen, samlet oppetid og nedetid, klyngens nuværende tilstand og hvornår denne tilstand sidst ændrede sig.
Et andet afsnit giver flere detaljer om tilgængelighed for hver klynge. Skærmbilledet nedenfor viser kun én af databaseklyngen:
Vi kan se, hvornår en node skiftede tilstand, og hvad overgangen var. Det er et rart sted at tjekke, om der var nogen nylige problemer med klyngen. Lignende data er vist i den tredje sektion af denne rapport, hvor du kan gennemgå historikken for ændringer i klyngetilstand.
Sikkerhedskopieringsrapport
Den anden type af rapporten er en, der dækker sikkerhedskopier af alle klynger. Den indeholder to sektioner - backupresumé og backupdetaljer, hvor førstnævnte grundlæggende giver dig en kort oversigt over, hvornår den sidste backup blev oprettet, om den blev gennemført med succes eller mislykkedes, backupverifikationsstatus, succesrate og opbevaringsperiode:
ClusterControl giver også eksempler på sikkerhedskopieringspolitik, hvis den finder nogen af de overvågede databaseklynge, der kører uden planlagt sikkerhedskopiering eller forsinket slave konfigureret. Dernæst er sikkerhedskopieringsdetaljerne:
Du kan også kontrollere listen over sikkerhedskopier udført på klyngen med deres tilstand, type og størrelse inden for det angivne interval. Dette er så tæt på, som du kan komme for at være sikker på, at sikkerhedskopier fungerer korrekt uden at køre en fuld gendannelsestest. Vi anbefaler klart, at sådanne tests udføres i ny og næ. Gode nyheder er, at ClusterControl understøtter MySQL-baseret gendannelse og verifikation på en selvstændig vært under Backup -> Gendan Backup.
Daglig systemrapport
Denne type rapport indeholder detaljerede oplysninger om en bestemt klynge. Det starter med en oversigt over forskellige advarsler, der er relateret til klyngen:
Næste afsnit handler om tilstanden af noderne, der er en del af klyngen:
Du har en liste over noderne i klyngen, deres type, rolle (master eller slave), status for noden, oppetid og OS.
Et andet afsnit af rapporten er backupresuméet, det samme som vi diskuterede ovenfor. Den næste præsenterer en oversigt over de mest populære forespørgsler i klyngen:
Til sidst ser vi en "Knudestatusoversigt", hvor du vil blive præsenteret for grafer relateret til OS- og MySQL-metrics for hver node.
Som du kan se, har vi her grafer, der dækker alle aspekter af belastningen på værten - CPU, hukommelse, netværk, disk, CPU-belastning og diskfri. Dette er nok til at få en idé om, hvorvidt der skete noget underligt for nylig eller ej. Du kan også se nogle detaljer om MySQL-arbejdsbelastning - hvor mange forespørgsler blev udført, hvilken type forespørgsel, hvordan data blev tilgået (via hvilken handler)? Dette burde på den anden side være nok til at vælge de fleste problemer på MySQL-siden. Det, du vil se på, er alle spidser og fald, som du ikke har set tidligere. Måske er en ny forespørgsel blevet tilføjet til blandingen og som et resultat handler_read_rnd_next røget i vejret? Måske var der en stigning i CPU-belastningen, og et højt antal forbindelser kunne pege på øget belastning på MySQL, men også på en eller anden form for strid. Et uventet mønster kan være godt at undersøge, så du ved, hvad der foregår.
Pakkeopgraderingsrapport
Denne rapport giver en oversigt over pakker, der er tilgængelige for opgradering af lageradministratoren på de overvågede værter. For en nøjagtig rapportering skal du sikre, at du altid bruger stabile og pålidelige arkiver på hver vært. I nogle uønskede tilfælde kan de overvågede værter konfigureres med et forældet lager efter en opgradering (f.eks. bruger hver større MariaDB-version forskelligt lager), ufuldstændigt internt lager (f.eks. delvist spejlet fra opstrøms) eller blødende kant-lager (almindeligvis for ustabilt) natlige pakker).
Det første afsnit er opgraderingsoversigten:
Den opsummerer det samlede antal pakker, der er tilgængelige for opgradering, samt den relaterede administrerede service for klyngen som load balancer, virtuel IP-adresse og voldgiftsdommer. Dernæst giver ClusterControl en detaljeret pakkeliste, grupperet efter pakketype for hver vært:
Denne rapport giver den tilgængelige version og kan i høj grad hjælpe os med at planlægge vores vedligeholdelsesvindue effektivt. For kritiske opgraderinger som sikkerhed og databasepakker kunne vi prioritere det frem for ikke-kritiske opgraderinger, som kunne konsolideres med andre mindre prioriterede vedligeholdelsesvinduer.
Skemaændringsrapport
Denne rapport sammenligner de valgte MySQL/MariaDB-databaseændringer i tabelstruktur, som skete mellem to forskellige genererede rapporter. I de ældre MySQL/MariaDB-versioner er DDL-operation en ikke-atomisk operation (før 8.0) og kræver fuld tabelkopi (før 5.6 for de fleste operationer) - blokerer andre transaktioner, indtil den er fuldført. Skemaændringer kan blive en stor smerte, når først dine tabeller får en betydelig mængde data og skal planlægges omhyggeligt, især i en klynget opsætning. I et udviklingsmiljø med flere niveauer har vi set mange tilfælde, hvor udviklere stille og roligt ændrer tabelstrukturen, hvilket resulterer i betydelig indvirkning på forespørgselsydeevnen.
For at ClusterControl kan producere en nøjagtig rapport, skal specielle muligheder konfigureres i CMON-konfigurationsfilen for den respektive klynge:
- schema_change_detection_address - Kontroller vil blive udført ved hjælp af VIS TABELLER/VIS OPRET TABEL for at afgøre, om skemaet er ændret. Kontrollerne udføres på den angivne adresse og har formatet HOSTNAVN:PORT. schema_change_detection_databases skal også indstilles. En differential af en ændret tabel oprettes (ved hjælp af diff).
- schema_change_detection_databases - Kommasepareret liste over databaser, der skal overvåges for skemaændringer. Hvis tom, foretages ingen kontrol.
I dette eksempel vil vi gerne overvåge skemaændringer for databasen "myapp" og "sbtest" på vores MariaDB Cluster med klynge-id 27. Vælg en af databasenoderne som værdien af schema_change_detection_address . For MySQL-replikering skal dette være master-værten eller en hvilken som helst slavevært, der har databaserne (i tilfælde af, at delvis replikering er aktiv). Tilføj derefter de to følgende linjer inde i /etc/cmon.d/cmon_27.cnf:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestGenstart CMON-tjenesten for at indlæse ændringen:
$ systemctl restart cmonFor den første og fremmeste rapport returnerer ClusterControl kun resultatet af metadataindsamling, svarende til nedenfor:
Med den første rapport som udgangspunkt vil de efterfølgende rapporter returnere det output, vi forventer for:
Bemærk kun nye tabeller eller ændrede tabeller udskrives i rapporten. Den første rapport er kun til metadataindsamling til sammenligning i de efterfølgende runder, så vi skal køre den mindst to gange for at se forskellen.
Med denne rapport kan du nu samle databasestrukturens fodspor og forstå, hvordan din database har udviklet sig over tid.
Sidste tanker
Driftsrapport er en omfattende måde at forstå status for din databaseinfrastruktur. Det er bygget til både drifts- eller ledelsespersonale og kan være meget nyttigt til at analysere dine databaseoperationer. Rapporterne kan genereres på stedet eller kan leveres til dig via e-mail, hvilket gør tingene nemt, hvis du har en rapporteringssilo.
Vi vil meget gerne høre din feedback om alt andet, du gerne vil have med i rapporten, hvad der mangler, og hvad der ikke er nødvendigt.