Att övervaka din MySQL-databas proaktivt är absolut nödvändigt nuförtiden. Det spelar en avgörande och betydande roll för att hantera och kontrollera din databas, särskilt för dina produktionsklassade kluster. Att sakna specifik information som skulle vara till nytta för att förbättra din databas eller att misslyckas med att identifiera grundorsaken till problem som kan uppstå kan orsaka extrema svårigheter att fixa eller återhämta sig från dess glansdagar.
Proaktiv övervakning i din MySQL-databas gör att ditt team kan förstå hur dina databastjänster fungerar. Fungerar och levererar den baserat på den arbetsbelastning den förväntas bära? Har du tillräckligt med resurser för att servern ska fungera baserat på den arbetsbelastning som den hanterar för närvarande? Proaktiv övervakning tillämpar saker som ska förhindra katastrofer eller skada din databas som ska meddela dig i förväg. Sålunda tillåter DBA:er eller administratörer att utföra viktiga uppgifter för att undvika att stöta på funktionsfel, datakorruption, säkerhetsexploateringar och attacker eller oväntad studs av trafik i ditt databaskluster. Genom att dessa tas tillvara omedelbart måste proaktiv övervakning för MySQL automatiseras och ska fungera 24/7 utan avbrott och det är upp till DBA:er, Devops, administratörer att bestämma om baserat på prioritering av uppgifter och hur avgörande det är om det kräver underhåll eller bara ett typiskt dagligt rutinarbete.
Proaktiv övervakning med ClusterControl
ClusterControl erbjuder en mångsidig stil för att övervaka dina MySQL-databasservrar. Dess tillvägagångssätt är jämförbart med andra företagsövervakningsverktyg och med molnlösningar av företagsklass. ClusterControl tenderar att tillämpa alla de bästa metoderna för att hantera och övervaka databaserna men med flexibiliteten att konfigurera för att uppnå önskad installation baserat på din miljö.
När det kommer till larm och aviseringar har ClusterControl ett blandat tillvägagångssätt där det finns inbyggda larm, och sedan finns det rådgivarna som vi kommer att diskutera mer om på den här bloggen.
ClusterControl Alarms for MySQL
Larm indikerar problem som kan påverka eller försämra klustret som helhet. Detta gränssnitt ger en detaljerad förklaring av problemet, tillsammans med den rekommenderade åtgärden (om tillgänglig) för att lösa problemet. Varje larm kategoriseras som:
-
Kluster
-
Klusteråterställning
-
Databashälsa
-
Databasprestanda
-
Värd
-
Nod
-
Nätverk
Ett larm kan kvitteras genom att markera Ignorera? kryssruta. När det ignoreras kommer inget meddelande att skickas via e-post. Ett larm kan inte tas bort eller avvisas, men du kan dölja det från listan genom att klicka på knappen Dölj ignorerade larm.
Se exempel på skärmdump nedan,
Proaktivitet med ClusterControl
ClusterControl stöder automatisk återställning som reagerar när en felupptäckt har inträffat. Automatisk återställning med ClusterControl är en av de mest proaktiva funktionerna som spelar en avgörande roll i händelse av katastrofer.
Att aktivera den automatiska återställningen krävs för denna proaktiva övervakning som reagerar i olika situationer, till exempel om den primära MySQL-noden misslyckas.
I ClusterControl kommer detta att upptäckas direkt när det lyssnar på anslutningen med databasservern, eller i detta fall den primära servern. ClusterControl kommer att reagera ASAP och tillämpa en failover.
Failoveren är en del av den aktiverade klusteråterställningen. Eftersom båda knapparna Cluster och Node är aktiverade, följer det nodåterställningen som du ser nedan.
Beroende på nodernas nåbarhet kommer ClusterControl att försöka kontinuerligt ansluta via SSH och försöka nå noden och försöka återställa genom att börja använda sysvinit eller systemd. Uppenbarligen kan du tro att den tillämpar en failover och ClusterControl försöker starta den misslyckade primära. Det kan betyda att två databasnoder är tillgängliga, eller hur? Även om det är sant, kommer ClusterControl att ta den misslyckade primära till ett skrivskyddat läge medan den återställs. Se nedan,
Även om det finns vissa alternativ du kan ställa in för att hantera failover-mekanismen, bör hänvisa till vår dokumentation för detta eftersom det inte är i fokus för denna blogg.
Använda rådgivare för proaktivitet med ClusterControl
I ClusterControl kommer rådgivare att hittas genom att gå till
Medan den är i ett Galera-kluster lägger den till Galera-specifika rådgivare som visas nedan ,
Anpassa dina ClusterControl MySQL Advisors
Rådgivare är anpassningsbara och kan modifieras efter dina behov. I rådgivarnas skärmdump ovan klickar du bara på Redigera så omdirigeras du till den enkla IDE som vi har inbyggt i ClusterControl.
Du kan också skapa dina egna ClusterControl Advisors. Du kan hänvisa till dig själv för att lära dig mer om att skapa genom att läsa Write Your First Advisor eller ta den tvådelade serien för att skapa din egen med hjälp av Meltdown/Spectre-detektionsskript.
Hur är ClusterControl-rådgivare proaktiva?
Tekniskt sett fungerar ClusterControl-rådgivare mest som en anmälare och bokstavligen dina rådgivare. ClusterControl Advisors kommer att meddela dig om det upptäcker ovanligt beteende om det når över baströskelvärdena som ställts in som standard av ClusterControl. Vanligtvis är de använda tröskelvärdena generiska värden. Dessa generiska värden är baserade på bästa praxis och på den vanligaste och mest acceptabla arbetsbelastningen eller miljöinställningen. De flesta av rådgivarnas standard tillhandahåller inte larm eller varningsmekanismer i ClusterControl UI. Den meddelar dig via användargränssnittet (se exempel på skärmdump av Binlog Storage Location rådgivare nedan).
Som nämnts tidigare kan Advisors modifieras och är redigerbara via vår enkla editor eller IDE. Till exempel i ett MySQL-replikeringskluster tillhandahåller ClusterControl en Binlog Storage Location-rådgivare. Den upptäcker att binloggar lagras i datakatalogen där den meddelar att den måste vara utanför datakatalogen.
Låt oss ta ett exempel från listan över rådgivare och välja Connections now used advisor . Låt oss redigera detta som visas nedan,
eller alternativt kan du gå över till
Genom att göra det mer proaktivt genom att skicka larm kan du ändra det och lägga till följande funktioner precis som nedan,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Om du ställer in tröskeln till 20, lägg sedan till dessa rader nedanför precis inom if condition-satsen där tröskeln nås över det givna tröskelvärdet.
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 använda sysbench för att testa det. I mitt test blir jag proaktivt aviserad genom att skicka larmet. Detta ska också skickas till mig via e-post eller kan meddelas om du har integrerade aviseringar från tredje part. Se skärmdumpen nedan,
ClusterControls rådgivare varningar
Ändra eller redigera en befintlig rådgivare i ClusterControl tillämpas på alla kluster. Det betyder att du måste kontrollera ditt skript om det har ett specifikt villkor som endast gäller för ditt befintliga kluster (antingen MySQL eller andra databaser som stöds av ClusterControl). Detta beror på att ClusterControl-rådgivarna lagras i en enda källa via vår cmon DB. Dessa hämtas eller hämtas av alla kluster du har skapat i ClusterControl.
Du kan till exempel göra detta i ett skript:
var hosts =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Detta skript kommer att skriva ut kluster-ID:t. När du har fått värdet, tilldela det till en variabel och använd den variabeln för att utvärdera om det är sant att detta specifika kluster-ID är acceptabelt eller inte baserat på din önskade uppgift som ska utföras av din rådgivare. Låt säga,
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;
}
…
….
…..vilket betyder att om det är cluster_id ==15, hoppa över eller fortsätt till nästa loop.
Slutsats
Att skapa eller ändra ClusterControl Advisors är ett bra tillfälle att utnyttja den dolda funktionalitet som ClusterControl kan ge dig. Det kan tyckas vara dold men det finns där - det är bara det att funktionen används mindre. Det ger en enkel men kraftfull funktion som kallas ClusterControl Domain Specific Language (CDSL) som kan användas för extremt svåra uppgifter som ClusterControl saknar. Se bara till att du känner till alla varningar och testa också allt först innan du slutligen tillämpar det på din produktionsmiljö.