Majoriteten av DBA:s utför hälsokontroller på sina databaser då och då. Vanligtvis skulle det ske dagligen eller veckovis. Vi har tidigare diskuterat varför sådana kontroller är viktiga och vad de bör innehålla.
För att se till att dina system är i gott skick, skulle du behöva gå igenom en hel del information - värdstatistik, MySQL-statistik, arbetsbelastningsstatistik, tillstånd för säkerhetskopior, databaspaket, loggar och så vidare. Sådan data bör vara tillgänglig i alla korrekt övervakade miljöer, även om de ibland är utspridda över flera platser - du kan ha ett verktyg för att övervaka MySQL-tillstånd, ett annat verktyg för att samla in systemstatistik, kanske en uppsättning skript, t.ex. dina säkerhetskopior. Detta gör hälsokontroller mycket mer tidskrävande än de borde vara - DBA måste sätta ihop de olika delarna för att förstå tillståndet i systemet.
Integrerade verktyg som ClusterControl har en fördel att alla bitar är placerade på samma plats (eller i samma applikation). Det betyder fortfarande inte att de är placerade bredvid varandra - de kan vara placerade i olika delar av användargränssnittet och en DBA kan behöva lägga lite tid på att klicka sig igenom användargränssnittet för att nå all intressant information.
Hela idén bakom att skapa verksamhetsrapporter är att lägga alla de viktigaste uppgifterna i ett enda dokument, som snabbt kan granskas för att få en förståelse för databasernas tillstånd.
Driftsrapporter är tillgängliga från menyn Sidomeny -> Driftsrapporter:
När du går dit kommer du att presenteras med en lista över rapporter som skapats manuellt eller automatiskt, baserat på ett fördefinierat schema:
Om du vill skapa en ny rapport manuellt använder du alternativet "Skapa". Välj typ av rapport, klusternamn (för rapport per kluster), e-postmottagare (valfritt – om du vill att rapporten ska levereras till dig), så är du i stort sett klar:
Rapporterna kan också schemaläggas för att skapas regelbundet:
För närvarande finns 5 typer av rapporter tillgängliga:
- Tillgänglighetsrapport – Alla kluster.
- Säkerhetskopieringsrapport – Alla kluster.
- Schemaändringsrapport - endast MySQL/MariaDB-baserat kluster.
- Daglig systemrapport – per kluster.
- Paketuppgraderingsrapport – per kluster.
Tillgänglighetsrapport
Tillgänglighetsrapporter fokuserar på, ja, tillgänglighet. Den innehåller tre sektioner. Först, tillgänglighetsöversikt:
Du kan se information om tillgänglighetsstatistik för dina databaser, klustertyp, total drifttid och driftstopp, aktuellt tillstånd för klustret och när det tillståndet senast ändrades.
Ett annat avsnitt ger mer information om tillgänglighet för varje kluster. Skärmdumpen nedan visar bara en av databasklustret:
Vi kan se när en nod bytte tillstånd och vad övergången var. Det är ett trevligt ställe att kontrollera om det har varit några nya problem med klustret. Liknande data visas i det tredje avsnittet av den här rapporten, där du kan gå igenom historiken över förändringar i klustertillstånd.
Säkerhetskopieringsrapport
Den andra typen av rapporten är en som täcker säkerhetskopior av alla kluster. Den innehåller två sektioner - säkerhetskopieringssammanfattning och säkerhetskopieringsdetaljer, där den förra i princip ger dig en kort sammanfattning av när den senaste säkerhetskopian skapades, om den slutfördes framgångsrikt eller misslyckades, säkerhetskopieringsverifieringsstatus, framgångsfrekvens och lagringsperiod:
ClusterControl ger också exempel på säkerhetskopieringspolicy om den hittar något av de övervakade databasklustret som körs utan att någon schemalagd säkerhetskopiering eller fördröjd slav har konfigurerats. Nästa är säkerhetskopieringsinformationen:
Du kan också kontrollera listan över säkerhetskopior som körs på klustret med deras tillstånd, typ och storlek inom det angivna intervallet. Detta är så nära du kan komma för att vara säker på att säkerhetskopior fungerar korrekt utan att köra ett fullständigt återställningstest. Vi rekommenderar definitivt att sådana tester görs då och då. Goda nyheter är att ClusterControl stöder MySQL-baserad återställning och verifiering på en fristående värd under Säkerhetskopiering -> Återställ säkerhetskopia.
Daglig systemrapport
Denna typ av rapport innehåller detaljerad information om ett visst kluster. Det börjar med en sammanfattning av olika varningar som är relaterade till klustret:
Nästa avsnitt handlar om tillståndet för noderna som är en del av klustret:
Du har en lista över noderna i klustret, deras typ, roll (master eller slav), nodens status, drifttid och OS.
En annan del av rapporten är säkerhetskopieringssammanfattningen, samma som vi diskuterade ovan. Nästa presenterar en sammanfattning av de vanligaste frågorna i klustret:
Slutligen ser vi en "Nodstatusöversikt" där du kommer att presenteras med grafer relaterade till OS- och MySQL-statistik för varje nod.
Som du kan se har vi här grafer som täcker alla aspekter av belastningen på värden - CPU, minne, nätverk, disk, CPU-belastning och diskfri. Detta räcker för att få en uppfattning om huruvida något konstigt hände nyligen eller inte. Du kan också se en del detaljer om MySQL-arbetsbelastning - hur många frågor kördes, vilken typ av fråga, hur åtkomst till data (via vilken hanterare)? Detta, å andra sidan, borde vara tillräckligt för att välja de flesta problem på MySQL-sidan. Det du vill titta på är alla toppar och fall som du inte har sett tidigare. Kanske har en ny fråga lagts till i mixen och, som ett resultat, handler_read_rnd_next skjutit i höjden? Kanske har det skett en ökning av CPU-belastningen och ett stort antal anslutningar kan peka på ökad belastning på MySQL, men också på någon form av konflikt. Ett oväntat mönster kan vara bra att undersöka, så att du vet vad som händer.
Paketuppgraderingsrapport
Den här rapporten ger en sammanfattning av paket som är tillgängliga för uppgradering av förvarshanteraren på de övervakade värdarna. För en korrekt rapportering, se till att du alltid använder stabila och pålitliga arkiv på varje värd. I vissa oönskade tillfällen kan de övervakade värdarna konfigureras med ett föråldrat arkiv efter en uppgradering (t.ex. varje MariaDB-huvudversion använder olika arkiv), ofullständigt internt arkiv (t.ex. delvis speglat från uppströms) eller bleeding edge-förråd (vanligtvis för instabilt arkiv). nattliga paket).
Det första avsnittet är uppgraderingssammanfattningen:
Den sammanfattar det totala antalet paket som är tillgängliga för uppgradering samt den relaterade hanterade tjänsten för klustret som lastbalanserare, virtuell IP-adress och medlare. Därefter tillhandahåller ClusterControl en detaljerad paketlista, grupperad efter pakettyp för varje värd:
Den här rapporten tillhandahåller den tillgängliga versionen och kan i hög grad hjälpa oss att planera vårt underhållsfönster effektivt. För kritiska uppgraderingar som säkerhet och databaspaket kan vi prioritera det framför icke-kritiska uppgraderingar, som kan konsolideras med andra mindre prioriterade underhållsfönster.
Schemaändringsrapport
Denna rapport jämför de valda MySQL/MariaDB-databasförändringarna i tabellstruktur som hände mellan två olika genererade rapporter. I de äldre versionerna av MySQL/MariaDB är DDL-operation en icke-atomär operation (före 8.0) och kräver fullständig tabellkopia (före 5.6 för de flesta operationer) - blockerar andra transaktioner tills den slutförs. Schemaändringar kan bli en enorm smärta när dina tabeller får en betydande mängd data och måste planeras noggrant, särskilt i en klustrad installation. I en utvecklingsmiljö med flera nivåer har vi sett många fall där utvecklare tyst modifierar tabellstrukturen, vilket resulterar i betydande inverkan på frågeprestanda.
För att ClusterControl ska kunna producera en korrekt rapport måste speciella alternativ konfigureras i CMON-konfigurationsfilen för respektive kluster:
- schema_change_detection_address - Kontroller kommer att utföras med hjälp av VISA TABELLER/VISA SKAPA TABELL för att avgöra om schemat har ändrats. Kontrollerna utförs på den angivna adressen och har formatet HOSTNAME:PORT. schema_change_detection_databases måste också ställas in. En differential för en ändrad tabell skapas (med diff).
- schema_change_detection_databases - Kommaseparerad lista över databaser att övervaka för schemaändringar. Om den är tom görs inga kontroller.
I det här exemplet skulle vi vilja övervaka schemaändringar för databasen "myapp" och "sbtest" på vårt MariaDB-kluster med kluster-ID 27. Välj en av databasnoderna som värdet för schema_change_detection_address . För MySQL-replikering bör detta vara mastervärden, eller vilken slavvärd som helst som håller databaserna (om partiell replikering är aktiv). Lägg sedan till de två följande raderna i /etc/cmon.d/cmon_27.cnf:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestStarta om CMON-tjänsten för att ladda ändringen:
$ systemctl restart cmonFör den första och främsta rapporten returnerar ClusterControl endast resultatet av metadatainsamling, liknande nedan:
Med den första rapporten som utgångspunkt kommer de efterföljande rapporterna att returnera resultatet som vi förväntar oss för:
Notera att endast nya tabeller eller ändrade tabeller skrivs ut i rapporten. Den första rapporten är endast till för insamling av metadata för jämförelse i de efterföljande omgångarna, så vi måste köra den minst två gånger för att se skillnaden.
Med den här rapporten kan du nu samla databasstrukturens fotspår och förstå hur din databas har utvecklats över tid.
Sluta tankar
Driftsrapport är ett heltäckande sätt att förstå tillståndet för din databasinfrastruktur. Den är byggd för både drift- och chefspersonal och kan vara mycket användbar för att analysera din databasverksamhet. Rapporterna kan genereras på plats eller kan levereras till dig via e-post, vilket gör det enkelt om du har en rapporteringssilo.
Vi vill gärna höra din feedback om allt annat du vill ha med i rapporten, vad som saknas och vad som inte behövs.