Het is tegenwoordig absoluut noodzakelijk om uw MySQL-database proactief te bewaken. Het speelt een cruciale en belangrijke rol bij het beheren en controleren van uw database, met name voor uw clusters van productiekwaliteit. Ontbrekende specifieke informatie die nuttig zou zijn voor het verbeteren van uw database of het niet identificeren van de hoofdoorzaak van problemen die kunnen optreden, kan tot extreme moeilijkheden leiden om deze op te lossen of te herstellen van zijn gloriedagen.
Proactieve monitoring in uw MySQL-database stelt uw team in staat te begrijpen hoe uw databaseservices presteren. Functioneert en levert het op basis van de verwachte werklast? Beschikt u over voldoende middelen om de server te laten presteren op basis van de werkbelasting die deze momenteel verwerkt? Proactieve monitoring past zaken toe die rampen voorkomen of schade toebrengen aan uw database, die u van tevoren op de hoogte stellen. Zodat de DBA's of beheerders belangrijke taken kunnen uitvoeren om storingen, gegevenscorruptie, beveiligingsaanvallen en -aanvallen of onverwachte bounce van verkeer in uw databasecluster te voorkomen. Door deze onmiddellijk bij te wonen, moet proactieve monitoring voor MySQL worden geautomatiseerd en 24/7 zonder onderbreking werken en het is aan de DBA's, Devops, beheerders om te beslissen of op basis van de prioriteit van taken en hoe cruciaal het is of er onderhoud of gewoon een typisch dagelijks routinewerk.
Proactieve monitoring met ClusterControl
ClusterControl biedt een diverse stijl voor het bewaken van uw MySQL-databaseservers. De aanpak is vergelijkbaar met andere enterprise monitoring tools en enterprise-grade cloudoplossingen. ClusterControl heeft de neiging om alle best practices toe te passen voor het beheren en bewaken van de databases, maar met de flexibiliteit om te configureren om de gewenste setup te bereiken op basis van uw omgeving.
Als het gaat om alarmen en meldingen, heeft ClusterControl een gemengde aanpak waarvoor er ingebouwde alarmen zijn, en dan zijn er de Adviseurs waarover we in deze blog meer zullen bespreken.
ClusterControl-alarmen voor MySQL
Alarmen duiden op problemen die het cluster als geheel kunnen beïnvloeden of verslechteren. Deze interface geeft een gedetailleerde uitleg over het probleem, samen met de aanbevolen actie (indien beschikbaar) om het probleem op te lossen. Elk alarm is gecategoriseerd als:
-
Cluster
-
Clusterherstel
-
Databasestatus
-
Databaseprestaties
-
Host
-
Knooppunt
-
Netwerk
Een alarm kan worden bevestigd door Negeren? selectievakje. Bij negeren wordt er geen melding per e-mail verzonden. Een alarm kan niet worden verwijderd of gesloten, maar u kunt het in de lijst verbergen door op de knop Genegeerde alarmen verbergen te klikken.
Zie voorbeeld screenshot hieronder,
Proactiviteit met ClusterControl
ClusterControl ondersteunt automatisch herstel dat reageert wanneer er een storing is gedetecteerd. Auto Recovery met ClusterControl is een van de meest proactieve functionaliteiten die een cruciale rol speelt bij calamiteiten.
Het inschakelen van automatisch herstel is vereist voor deze proactieve bewaking die in verschillende situaties reageert, bijvoorbeeld als de primaire MySQL-node uitvalt.
In ClusterControl wordt dit meteen gedetecteerd terwijl het naar de verbinding luistert met de databaseserver, of in dit geval de primaire server. ClusterControl zal zo snel mogelijk reageren en een failover toepassen.
De failover maakt deel uit van het ingeschakelde clusterherstel. Aangezien beide knoppen Cluster en Node zijn ingeschakeld, volgt het het herstel van de node zoals je hieronder ziet.
Afhankelijk van de bereikbaarheid van de knooppunten, zal ClusterControl continu proberen verbinding maken via SSH en proberen het knooppunt te bereiken en proberen te herstellen door sysvinit of system te gebruiken. Vanzelfsprekend zou je kunnen denken dat het een failover toepast en ClusterControl probeert de mislukte primaire te starten. Dat zou kunnen betekenen dat er twee databaseknooppunten beschikbaar zijn, toch? Hoewel waar, zal ClusterControl de mislukte primaire naar een alleen-lezen status brengen terwijl deze wordt hersteld. Zie hieronder,
Hoewel er bepaalde opties zijn die u kunt instellen om het failover-mechanisme te beheren, zou hiervoor onze documentatie moeten raadplegen, aangezien dit niet de focus van deze blog is.
Adviseurs gebruiken voor proactiviteit met ClusterControl
In ClusterControl kunnen adviseurs worden gevonden door naar
In een Galera-cluster voegt het de Galera-specifieke adviseurs toe, zoals hieronder weergegeven ,
Uw ClusterControl MySQL-adviseurs aanpassen
Advisors zijn aanpasbaar en kunnen worden aangepast aan uw behoeften. Klik in de schermafbeelding van Advisors hierboven op Bewerken en u wordt doorgestuurd naar de eenvoudige IDE die we hebben ingebouwd in ClusterControl.
U kunt ook uw eigen ClusterControl-adviseurs maken. Je kunt jezelf raadplegen voor meer informatie over creëren door Write Your First Advisor te lezen of de tweedelige serie te gebruiken om je eigen serie te maken met behulp van Meltdown/Spectre-detectiescript.
Hoe zijn ClusterControl-adviseurs proactief?
Technisch gezien fungeren ClusterControl-adviseurs meestal als melder en letterlijk uw adviseurs. ClusterControl Advisors zal u op de hoogte stellen als het ongebruikelijk gedrag detecteert als het de basisdrempels overschrijdt die standaard door ClusterControl zijn ingesteld. Meestal zijn de toegepaste drempels generieke waarden. Deze generieke waarden zijn gebaseerd op best practices en op de meest voorkomende en acceptabele workload of omgevingsinstellingen. De meeste standaardinstellingen van adviseurs bieden geen alarmen of waarschuwingsmechanismen in de gebruikersinterface van ClusterControl. Het stelt je wel op de hoogte via de gebruikersinterface (zie voorbeeldscreenshot van de Binlog Storage Location-adviseur hieronder).
Zoals eerder vermeld, kunnen adviseurs worden gewijzigd en bewerkt via onze eenvoudige editor of IDE. In een MySQL-replicatiecluster biedt ClusterControl bijvoorbeeld een Binlog Storage Location-adviseur. Het detecteert dat binlogs zijn opgeslagen in de datadirectory waar het aangeeft dat het buiten de datadirectory moet staan.
Laten we een voorbeeld nemen uit de lijst met adviseurs en Verbindingen selecteren die momenteel worden gebruikt adviseur . Laten we dit bewerken zoals hieronder weergegeven,
of je kunt ook naar
Door het proactiever te maken door alarmen te verzenden, kunt u het wijzigen en toevoegen de volgende functies zoals hieronder,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Terwijl, door de drempel in te stellen op 20, deze regels eronder worden toegevoegd, net binnen de if-voorwaarde-instructie waar de drempel wordt bereikt boven de gegeven drempelwaarde.
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;
}Je kunt sysbench gebruiken om het te testen. In mijn test word ik proactief op de hoogte gebracht door het alarm te sturen. Dit wordt ook per e-mail naar mij verzonden of kan worden gemeld als u meldingen van derden hebt geïntegreerd. Zie de onderstaande schermafbeelding,
ClusterControl's waarschuwingen voor adviseurs
Het wijzigen of bewerken van een bestaande adviseur in ClusterControl wordt toegepast op alle clusters. Dat betekent dat u uw script moet inchecken als het een specifieke voorwaarde heeft die alleen van toepassing is op uw bestaande cluster (ofwel MySQL of andere ondersteunde databases door ClusterControl). Dit komt omdat de ClusterControl-adviseurs alleen via onze cmon DB in één bron worden opgeslagen. Deze worden opgehaald of opgehaald door alle clusters die u in ClusterControl hebt gemaakt.
U kunt dit bijvoorbeeld in een script doen:
var hosts =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Dit script drukt de cluster-ID af. Zodra u de waarde hebt gekregen, wijst u deze toe aan een variabele en gebruikt u die variabele om te evalueren of het waar is dat deze specifieke cluster-ID acceptabel is of niet op basis van de door uw adviseur gewenste taak. Laten we zeggen,
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;
}
…
….
…..wat betekent dat als het cluster_id ==15 is, dan gewoon overslaan of doorgaan naar de volgende lus.
Conclusie
Het maken of wijzigen van de ClusterControl-adviseurs is een goede gelegenheid om gebruik te maken van de verborgen functionaliteit die ClusterControl u kan bieden. Het lijkt misschien verborgen, maar het is er - het is alleen dat de functie minder wordt gebruikt. Het biedt een eenvoudige maar krachtige functie genaamd ClusterControl Domain Specific Language (CDSL), die kan worden gebruikt voor extreem moeilijke taken die ClusterControl niet heeft. Zorg ervoor dat u alle waarschuwingen kent en test ook alles eerst voordat u het uiteindelijk toepast op uw productieomgeving.