De meeste DBA's voeren af en toe gezondheidscontroles uit op hun databases. Meestal zou het dagelijks of wekelijks gebeuren. We hebben eerder besproken waarom dergelijke controles belangrijk zijn en wat ze moeten bevatten.
Om ervoor te zorgen dat uw systemen in goede staat verkeren, moet u heel wat informatie doornemen - hoststatistieken, MySQL-statistieken, werkbelastingstatistieken, status van back-ups, databasepakketten, logbestanden enzovoort. Dergelijke gegevens zouden beschikbaar moeten zijn in elke goed gecontroleerde omgeving, hoewel ze soms over meerdere locaties verspreid zijn - u hebt misschien een tool om de MySQL-status te controleren, een andere tool om systeemstatistieken te verzamelen, misschien een set scripts, bijvoorbeeld om de status van uw back-ups. Dit maakt gezondheidscontroles veel tijdrovender dan ze zouden moeten zijn - de DBA moet de verschillende onderdelen samenstellen om de toestand van het systeem te begrijpen.
Geïntegreerde tools zoals ClusterControl hebben als voordeel dat alle bits zich op dezelfde plaats (of in dezelfde applicatie) bevinden. Het betekent nog steeds niet dat ze naast elkaar staan - ze kunnen zich in verschillende secties van de gebruikersinterface bevinden en een DBA kan enige tijd nodig hebben om door de gebruikersinterface te klikken om alle interessante gegevens te bereiken.
Het hele idee achter het maken van operationele rapporten is om alle belangrijkste gegevens in één document te plaatsen, dat snel kan worden herzien om inzicht te krijgen in de status van de databases.
Operationele rapporten zijn beschikbaar via het menu Zijmenu -> Operationele rapporten:
Als je daar eenmaal bent, krijg je een lijst met rapporten te zien die handmatig of automatisch zijn gemaakt, op basis van een vooraf gedefinieerd schema:
Als u handmatig een nieuw rapport wilt maken, gebruikt u de optie 'Maken'. Kies het type rapport, clusternaam (voor rapport per cluster), e-mailontvangers (optioneel - als u wilt dat het rapport bij u wordt afgeleverd), en u bent zo goed als klaar:
De rapporten kunnen ook worden gepland om regelmatig te worden gemaakt:
Op dit moment zijn er 5 soorten rapporten beschikbaar:
- Beschikbaarheidsrapport - Alle clusters.
- Back-uprapport - Alle clusters.
- Schemawijzigingsrapport - alleen op MySQL/MariaDB gebaseerde cluster.
- Dagelijks systeemrapport - per cluster.
- Pakketupgraderapport - Per cluster.
Beschikbaarheidsrapport
Beschikbaarheidsrapporten richten zich op, nou ja, beschikbaarheid. Het omvat drie secties. Ten eerste, beschikbaarheidsoverzicht:
U kunt informatie zien over beschikbaarheidsstatistieken van uw databases, het clustertype, de totale uptime en downtime, de huidige status van het cluster en wanneer die status voor het laatst is gewijzigd.
Een andere sectie geeft meer details over de beschikbaarheid voor elk cluster. De onderstaande schermafbeelding toont slechts één van de databaseclusters:
We kunnen zien wanneer een knooppunt van status is veranderd en wat de overgang was. Het is een goede plek om te controleren of er recente problemen met het cluster zijn geweest. Vergelijkbare gegevens worden weergegeven in het derde deel van dit rapport, waar u de geschiedenis van wijzigingen in de clusterstatus kunt bekijken.
Back-uprapport
Het tweede type rapport is een rapport dat back-ups van alle clusters omvat. Het bevat twee secties - back-upoverzicht en back-updetails, waarbij de eerste u in feite een korte samenvatting geeft van wanneer de laatste back-up is gemaakt, of deze succesvol of mislukt is, back-upverificatiestatus, succespercentage en bewaarperiode:
ClusterControl biedt ook voorbeelden van back-upbeleid als een van de bewaakte databaseclusters wordt uitgevoerd zonder dat een geplande back-up of vertraagde slave is geconfigureerd. Hierna volgen de back-updetails:
U kunt ook de lijst met back-ups die op het cluster zijn uitgevoerd, controleren met hun status, type en grootte binnen het opgegeven interval. Dit komt zo dicht mogelijk bij u om er zeker van te zijn dat back-ups correct werken zonder een volledige hersteltest uit te voeren. We raden zeker aan om zo nu en dan dergelijke tests uit te voeren. Goed nieuws is dat ClusterControl MySQL-gebaseerd herstel en verificatie ondersteunt op een zelfstandige host onder Back-up -> Back-up herstellen.
Dagelijks systeemrapport
Dit type rapport bevat gedetailleerde informatie over een bepaald cluster. Het begint met een samenvatting van verschillende waarschuwingen die betrekking hebben op het cluster:
De volgende sectie gaat over de status van de knooppunten die deel uitmaken van het cluster:
Je hebt een lijst van de nodes in het cluster, hun type, rol (master of slave), status van de node, uptime en het besturingssysteem.
Een ander deel van het rapport is het back-upoverzicht, zoals we hierboven hebben besproken. De volgende geeft een samenvatting van de meest voorkomende zoekopdrachten in het cluster:
Ten slotte zien we een 'Overzicht van de knooppuntstatus' waarin u voor elk knooppunt grafieken te zien krijgt met betrekking tot OS- en MySQL-statistieken.
Zoals je kunt zien, hebben we hier grafieken die alle aspecten van de belasting van de host bestrijken - CPU, geheugen, netwerk, schijf, CPU-belasting en schijfvrij. Dit is voldoende om een idee te krijgen of er recentelijk iets vreemds is gebeurd of niet. U kunt ook enkele details zien over de MySQL-workload - hoeveel query's zijn uitgevoerd, welk type query, hoe toegang tot de gegevens (via welke handler)? Dit zou daarentegen voldoende moeten zijn om de meeste problemen aan de MySQL-kant te kiezen. Waar je naar wilt kijken zijn allemaal pieken en dalen die je in het verleden niet hebt gezien. Misschien is er een nieuwe zoekopdracht aan de mix toegevoegd en als resultaat handler_read_rnd_next omhooggeschoten? Misschien was er een toename van de CPU-belasting en een groot aantal verbindingen zou kunnen wijzen op een verhoogde belasting van MySQL, maar ook op een soort twist. Een onverwacht patroon is misschien goed om te onderzoeken, zodat je weet wat er aan de hand is.
Pakketupgraderapport
Dit rapport geeft een overzicht van de pakketten die beschikbaar zijn voor upgrade door de repositorymanager op de bewaakte hosts. Zorg ervoor dat u voor een nauwkeurige rapportage altijd stabiele en vertrouwde repositories op elke host gebruikt. In sommige ongewenste gevallen kunnen de bewaakte hosts worden geconfigureerd met een verouderde repository na een upgrade (bijv. elke hoofdversie van MariaDB gebruikt een andere repository), onvolledige interne repository (bijv. nachtelijk samengestelde pakketten).
Het eerste gedeelte is het upgradeoverzicht:
Het geeft een overzicht van het totale aantal pakketten dat beschikbaar is voor upgrade, evenals de gerelateerde beheerde service voor het cluster, zoals load balancer, virtueel IP-adres en arbiter. Vervolgens biedt ClusterControl een gedetailleerde pakketlijst, gegroepeerd op pakkettype voor elke host:
Dit rapport biedt de beschikbare versie en kan ons enorm helpen bij het efficiënt plannen van ons onderhoudsvenster. Voor kritieke upgrades, zoals beveiligings- en databasepakketten, kunnen we prioriteit geven aan niet-kritieke upgrades, die kunnen worden geconsolideerd met andere onderhoudsperiodes met minder prioriteit.
Schemawijzigingsrapport
Dit rapport vergelijkt de geselecteerde MySQL/MariaDB-databasewijzigingen in de tabelstructuur die plaatsvonden tussen twee verschillende gegenereerde rapporten. In de oudere versies van MySQL/MariaDB is DDL-bewerking een niet-atomaire bewerking (vóór 8.0) en vereist een volledige tabelkopie (pre 5.6 voor de meeste bewerkingen) - het blokkeren van andere transacties totdat deze is voltooid. Schemawijzigingen kunnen een enorme last worden zodra uw tabellen een aanzienlijke hoeveelheid gegevens krijgen en zorgvuldig moeten worden gepland, vooral in een geclusterde opstelling. In een ontwikkelomgeving met meerdere niveaus hebben we veel gevallen gezien waarin ontwikkelaars de tabelstructuur stilletjes wijzigen, wat een aanzienlijke impact heeft op de queryprestaties.
Om ervoor te zorgen dat ClusterControl een nauwkeurig rapport kan produceren, moeten er speciale opties worden geconfigureerd in het CMON-configuratiebestand voor het betreffende cluster:
- schema_change_detection_address - Er worden controles uitgevoerd met behulp van SHOW TABLES/SHOW CREATE TABLE om te bepalen of het schema is gewijzigd. De controles worden uitgevoerd op het opgegeven adres en hebben het formaat HOSTNAME:PORT. De schema_change_detection_databases moet ook worden ingesteld. Er wordt een differentiaal van een gewijzigde tabel gemaakt (met diff).
- schema_change_detection_databases - Door komma's gescheiden lijst van databases om te controleren op schemawijzigingen. Indien leeg, worden er geen controles uitgevoerd.
In dit voorbeeld willen we schemawijzigingen bewaken voor database "myapp" en "sbtest" op ons MariaDB-cluster met cluster-ID 27. Kies een van de databaseknooppunten als de waarde van schema_change_detection_address . Voor MySQL-replicatie moet dit de masterhost zijn, of een andere slave-host die de databases bevat (in het geval dat gedeeltelijke replicatie actief is). Voeg vervolgens in /etc/cmon.d/cmon_27.cnf de volgende twee regels toe:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestStart de CMON-service opnieuw om de wijziging te laden:
$ systemctl restart cmonVoor het eerste en belangrijkste rapport retourneert ClusterControl alleen het resultaat van het verzamelen van metagegevens, zoals hieronder:
Met het eerste rapport als baseline, zullen de volgende rapporten de output opleveren die we verwachten voor:
Let op alleen nieuwe tabellen of gewijzigde tabellen worden in het rapport afgedrukt. Het eerste rapport is alleen bedoeld voor het verzamelen van metagegevens ter vergelijking in de volgende rondes, dus we moeten het minstens twee keer uitvoeren om het verschil te zien.
Met dit rapport kunt u nu de voetafdrukken van de databasestructuur verzamelen en begrijpen hoe uw database zich in de loop van de tijd heeft ontwikkeld.
Laatste gedachten
Operationeel rapport is een uitgebreide manier om inzicht te krijgen in de staat van uw database-infrastructuur. Het is gebouwd voor zowel operationeel als leidinggevend personeel en kan erg handig zijn bij het analyseren van uw databasebewerkingen. De rapporten kunnen ter plaatse worden gegenereerd of via e-mail aan u worden bezorgd, wat het gemakkelijk maakt als u een rapportagesilo heeft.
We horen graag uw feedback over al het andere dat u in het rapport zou willen opnemen, wat er ontbreekt en wat niet nodig is.