Proaktiv overvågning af din MySQL-database er bydende nødvendigt i dag. Det spiller en afgørende og væsentlig rolle for styring og kontrol af din database, især for dine klynger i produktionskvalitet. Manglende specifik information, der ville være gavnlig for at forbedre din database eller undlade at identificere årsagen til problemer, der kan opstå, kan give ekstreme vanskeligheder med at rette op på eller komme tilbage fra dens storhedsdage.
Proaktiv overvågning i din MySQL-database giver dit team mulighed for at forstå, hvordan dine databasetjenester fungerer. Fungerer og leverer den baseret på den arbejdsbyrde, den forventes at bære? Har du nok ressourcer til, at serveren kan fungere, baseret på den arbejdsbyrde, den håndterer i øjeblikket? Proaktiv overvågning anvender ting, der skal forhindre katastrofe eller skade din database, som skal underrette dig på forhånd. Således at tillade DBA'er eller administratorer at udføre vigtige opgaver for at undgå at støde på funktionsfejl, datakorruption, sikkerhedsudnyttelse og angreb eller uventet afvisning af trafik i din databaseklynge. Ved at disse bliver overværet med det samme, skal proaktiv overvågning af MySQL automatiseres og skal fungere 24/7 uden afbrydelser, og det er op til DBA'er, Devops, administratorer at beslutte, om det er baseret på prioritering af opgaver, og hvor afgørende det er, om det kræver vedligeholdelse eller bare et typisk dagligt rutinearbejde.
Proaktiv overvågning med ClusterControl
ClusterControl tilbyder en forskelligartet stil til overvågning af dine MySQL-databaseservere. Dens tilgang kan sammenlignes med andre virksomhedsovervågningsværktøjer og med cloud-løsninger i virksomhedsklasse. ClusterControl har en tendens til at anvende alle de bedste praksisser for styring og overvågning af databaser, men med fleksibiliteten til at konfigurere for at opnå den ønskede opsætning baseret i dit miljø.
Når det kommer til alarmer og notifikationer, har ClusterControl en blandet tilgang, hvor der er indbyggede alarmer, og så er der rådgiverne, som vi vil diskutere mere om på denne blog.
ClusterControl Alarmer til MySQL
Alarmer indikerer problemer, der kan påvirke eller forringe klyngen som helhed. Denne grænseflade giver en detaljeret forklaring på problemet sammen med den anbefalede handling (hvis tilgængelig) for at løse problemet. Hver alarm er kategoriseret som:
-
Klynge
-
Klyngendannelse
-
Databasesundhed
-
Databaseydelse
-
Vært
-
Knude
-
Netværk
En alarm kan bekræftes ved at markere Ignorer? afkrydsningsfelt. Når ignoreret, vil der ikke blive sendt nogen meddelelse via e-mail. En alarm kan ikke slettes eller afvises, selvom du kan skjule den fra listen ved at klikke på knappen Skjul ignorerede alarmer.
Se eksempel på skærmbillede nedenfor,
Proaktivitet med ClusterControl
ClusterControl understøtter automatisk gendannelse, som reagerer, når der er opstået en fejlregistrering. Automatisk gendannelse med ClusterControl er en af de mest proaktive funktioner, der spiller en afgørende rolle i tilfælde af katastrofer.
Aktivering af automatisk gendannelse er påkrævet for denne proaktive overvågning, som reagerer i forskellige situationer, for eksempel hvis den primære MySQL-node svigter.
I ClusterControl vil dette blive registreret med det samme, når det lytter til forbindelsen med databaseserveren, eller i dette tilfælde den primære server. ClusterControl vil reagere ASAP og anvende en failover.
Failoveren er en del af den aktiverede Cluster-gendannelse. Da begge knapper Cluster og Node er aktiveret, følger det nodegendannelsen, som du ser nedenfor.
Afhængigt af nodernes tilgængelighed vil ClusterControl forsøge løbende at opretter forbindelse gennem SSH og prøv at nå noden og forsøg at gendanne ved at begynde at bruge sysvinit eller systemd. Det er klart, at du måske tror, at den anvender en failover, og ClusterControl forsøger at starte den mislykkede primære. Det kunne betyde, at to databasenoder er tilgængelige, ikke? Selvom det er sandt, vil ClusterControl tage den mislykkede primære til en skrivebeskyttet tilstand, mens den gendannes. Se nedenfor,
Selvom der er visse indstillinger, du kan indstille til at administrere failover-mekanismen, kan du bør henvise til vores dokumentation for dette, da det ikke er fokus på denne blog.
Brug af rådgivere til proaktivitet med ClusterControl
I ClusterControl vil rådgivere blive lokaliseret ved at gå til
Mens den er i en Galera-klynge, tilføjer den de Galera-specifikke rådgivere som vist nedenfor ,
Tilpasning af dine ClusterControl MySQL-rådgivere
Rådgivere kan tilpasses og kan ændres i overensstemmelse med dine behov. I Advisors' skærmbillede ovenfor skal du blot klikke på Rediger, og du vil blive omdirigeret til den simple IDE, vi har indbygget i ClusterControl.
Du kan også oprette dine egne ClusterControl Advisors. Du kan henvise dig selv til at lære mere om at skabe ved at læse Skriv din første rådgiver eller tage serien i 2 dele for at oprette din egen ved hjælp af Meltdown/Spectre-detektionsscript.
Hvordan er ClusterControl-rådgivere proaktive?
Teknisk fungerer ClusterControl-rådgivere for det meste som underretter og bogstaveligt talt dine rådgivere. ClusterControl Advisors vil give dig besked, hvis den opdager usædvanlig adfærd, hvis den når over de basistærskler, der er angivet som standard af ClusterControl. Normalt er de anvendte tærskler generiske værdier. Disse generiske værdier er baseret på bedste praksis og på den mest almindelige og acceptable arbejdsbyrde eller miljøopsætning. De fleste af rådgivernes standard giver ikke alarmer eller advarselsmekanismer i ClusterControl UI. Den giver dig besked via brugergrænsefladen (se eksempel på skærmbillede af Binlog Storage Location-rådgiveren nedenfor).
Som tidligere nævnt kan Advisors modificeres og kan redigeres via vores simple editor eller IDE. For eksempel i en MySQL-replikeringsklynge tilbyder ClusterControl en Binlog Storage Location-rådgiver. Den registrerer, at binlogs er gemt i databiblioteket, hvor det meddeler, at det skal være uden for databiblioteket.
Lad os tage et eksempel fra listen over rådgivere og vælge Connections aktuelt brugte rådgiver . Lad os redigere dette som vist nedenfor,
eller alternativt kan du gå over til
Ved at gøre det mere proaktivt ved at sende alarmer, kan du ændre det og tilføje følgende funktioner ligesom nedenfor,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Hvorimod, indstil tærsklen til 20 og tilføj derefter disse linjer under lige inden for if-betingelsen, hvor tærskelværdien nås over den givne tærskelværdi.
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
Here's the complete script with my modifications in bold,
#include "common/mysql_helper.js"
var DESCRIPTION="This advisor calculates the percentage of threads_connected over max_connections,"
" if the percentage is higher than 20% you will be notified,"
" preventing your database server from becoming unstable.";
var WARNING_THRESHOLD=20;
var TITLE="Connections currently used";
var ADVICE_WARNING="You are using more than " + WARNING_THRESHOLD +
"% of the max_connections."
" Consider regulating load, e.g by using HAProxy. Using up all connections"
" may render the database server unusable.";
var ADVICE_OK="The percentage of currently used connections is satisfactory." ;
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}
function main()
{
var hosts = cluster::mySqlNodes();
var advisorMap = {};
for (idx = 0; idx < hosts.size(); ++idx)
{
host = hosts[idx];
map = host.toMap();
connected = map["connected"];
var advice = new CmonAdvice();
print(" ");
print(host);
print("==========================");
if (!connected)
{
print("Not connected");
continue;
}
var Threads_connected = host.sqlStatusVariable("Threads_connected");
var Max_connections = host.sqlSystemVariable("Max_connections");
if (Threads_connected.isError() || Max_connections.isError())
{
justification = "";
msg = "Not enough data to calculate";
}
else
{
var used = round(100 * Threads_connected / Max_connections,1);
if (used > WARNING_THRESHOLD)
{
advice.setSeverity(1);
msg = ADVICE_WARNING;
justification = used + "% of the connections is currently used,"
" which is > " + WARNING_THRESHOLD + "% of max_connections.";
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
}
else
{
justification = used + "% of the connections is currently used,"
" which is < 90% of max_connections.";
advice.setSeverity(0);
msg = ADVICE_OK;
}
}
advice.setHost(host);
advice.setTitle(TITLE);
advice.setJustification(justification);
advice.setAdvice(msg);
advisorMap[idx]= advice;
print(advice.toString("%E"));
}
return advisorMap;
}Du kan bruge sysbench til at teste det. I min test bliver jeg proaktivt underrettet ved at sende alarmen. Dette skal også sendes til mig via e-mail eller kan få besked, hvis du har integreret tredjepartsmeddelelser. Se skærmbilledet nedenfor,
ClusterControls advisors advarsler
Ændring eller redigering af en eksisterende rådgiver i ClusterControl anvendes på alle klynger. Det betyder, at du skal tjekke dit script ind, om det har en specifik betingelse, der kun gælder for din eksisterende klynge (enten MySQL eller andre understøttede databaser af ClusterControl). Dette skyldes, at ClusterControl-rådgiverne kun er gemt i en enkelt kilde via vores cmon DB. Disse trækkes eller hentes af alle klynger, du har oprettet i ClusterControl.
Du kan f.eks. gøre dette i et script:
var hosts =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Dette script vil udskrive klynge-id'et. Når du har fået værdien, skal du tildele den til en variabel og bruge denne variabel til at evaluere, om det er sandt, at dette specifikke klynge-id er acceptabelt eller ikke, baseret på din ønskede opgave, der skal udføres af din rådgiver. Lad os sige,
function main()
{
var hosts = cluster::mySqlNodes();
var advisorMap = {};
for (idx = 0; idx < hosts.size(); ++idx)
{
host = hosts[idx];
map = host.toMap();
connected = map["connected"];
var advice = new CmonAdvice();
print(" ");
print(host);
print("==========================");
if (host.clusterId() == 15)
{
print("Not applicable for cluster id == 15");
continue;
}
…
….
…..hvilket betyder, at hvis det er cluster_id ==15, så spring eller fortsæt til næste løkke.
Konklusion
Oprettelse eller ændring af ClusterControl Advisors er en god mulighed for at udnytte den skjulte funktionalitet, som ClusterControl kan give dig. Det ser måske ud til at være skjult, men det er der - det er bare, at funktionen bruges mindre. Det giver en enkel, men en kraftfuld funktion kaldet ClusterControl Domain Specific Language (CDSL), som kan bruges til ekstremt vanskelige opgaver, som ClusterControl mangler. Bare sørg for, at du kender alle forbeholdene, og test også alt først, før du endelig anvender det på dit produktionsmiljø.