Il monitoraggio proattivo del database MySQL è fondamentale al giorno d'oggi. Svolge un ruolo cruciale e significativo per la gestione e il controllo del database, in particolare per i cluster di livello produttivo. La mancanza di informazioni specifiche che sarebbero utili per migliorare il database o la mancata identificazione della causa principale dei problemi che si possono incontrare potrebbe causare difficoltà estreme da risolvere o recuperare dai suoi giorni di gloria.
Il monitoraggio proattivo nel tuo database MySQL consente al tuo team di comprendere le prestazioni dei tuoi servizi di database. Funziona e fornisce in base al carico di lavoro che dovrebbe sostenere? Disponi di risorse sufficienti affinché il server sia performante in base al carico di lavoro che sta attualmente gestendo? Il monitoraggio proattivo applica le cose che impediranno il disastro o danneggeranno il tuo database che ti avviserà in anticipo. Pertanto, consentendo ai DBA o agli amministratori di eseguire attività importanti per evitare malfunzionamenti, danneggiamento dei dati, exploit e attacchi di sicurezza o rimbalzi imprevisti del traffico nel cluster di database. Dato che questi sono presi immediatamente in considerazione, il monitoraggio proattivo per MySQL deve essere automatizzato e deve funzionare 24 ore su 24, 7 giorni su 7 senza interruzioni e spetta ai DBA, Devops e amministratori decidere se in base alla priorità delle attività e quanto sia cruciale se richiede manutenzione o solo un tipico lavoro di routine quotidiana.
Monitoraggio proattivo con ClusterControl
ClusterControl offre uno stile diversificato per il monitoraggio dei server di database MySQL. Il suo approccio è paragonabile ad altri strumenti di monitoraggio aziendale e alle soluzioni cloud di livello aziendale. ClusterControl tende ad applicare tutte le migliori pratiche per la gestione e il monitoraggio dei database, ma con la flessibilità di configurazione per ottenere la configurazione desiderata in base al proprio ambiente.
Quando si tratta di allarmi e notifiche, ClusterControl ha un approccio misto per il quale ci sono allarmi incorporati, e poi ci sono gli Advisor di cui parleremo più avanti in questo blog.
Allarmi ClusterControl per MySQL
Gli allarmi indicano problemi che potrebbero influenzare o degradare il cluster nel suo insieme. Questa interfaccia fornisce una spiegazione dettagliata del problema, insieme all'azione consigliata (se disponibile) per risolvere il problema. Ogni allarme è classificato come:
-
Cluster
-
Recupero del cluster
-
Stato del database
-
Prestazioni del database
-
Ospite
-
Nodo
-
Rete
Un allarme può essere riconosciuto selezionando Ignora? casella di controllo. Se ignorato, non verrà inviata alcuna notifica via e-mail. Un avviso non può essere eliminato o ignorato, anche se puoi nasconderlo dall'elenco facendo clic sul pulsante Nascondi avvisi ignorati.
Vedi screenshot di esempio qui sotto,
Proattività con ClusterControl
ClusterControl supporta il ripristino automatico che reagisce ogni volta che si verifica un rilevamento di errore. Il ripristino automatico con ClusterControl è una delle funzionalità più proattive che svolge un ruolo cruciale in caso di disastri.
L'abilitazione del ripristino automatico è necessaria per questo monitoraggio proattivo che reagisce in varie situazioni, ad esempio, se il nodo MySQL primario si guasta.
In ClusterControl, questo verrà rilevato immediatamente mentre ascolta la connessione con il server del database, o in questo caso il server primario. ClusterControl reagirà al più presto e applicherà un failover.
Il failover fa parte del ripristino del cluster abilitato. Poiché entrambi i pulsanti Cluster e Node sono abilitati, segue il ripristino del nodo come mostrato di seguito.
A seconda della raggiungibilità dei nodi, ClusterControl proverà a tentare continuamente di connettersi tramite SSH e provare a raggiungere il nodo e tentare di ripristinare iniziando a utilizzare sysvinit o systemd. Ovviamente, potresti pensare che applichi un failover e ClusterControl tenti di avviare il primario non riuscito. Ciò potrebbe significare che sono disponibili due nodi di database, giusto? Sebbene true, ClusterControl porterà il primario non riuscito a uno stato di sola lettura durante il ripristino. Vedi sotto,
Sebbene ci siano alcune opzioni che puoi impostare per gestire il meccanismo di failover, tu dovrebbe fare riferimento alla nostra documentazione per questo poiché non è l'obiettivo di questo blog.
Utilizzo di Advisor per la proattività con ClusterControl
In ClusterControl, gli Advisor verranno individuati andando su
Mentre si trova in un cluster Galera, aggiunge i consulenti Galera specifici come mostrato di seguito ,
Personalizzazione di ClusterControl MySQL Advisor
Gli advisor sono personalizzabili e possono essere modificati in base alle tue esigenze. Nella schermata degli Advisor sopra, fai semplicemente clic su Modifica e verrai reindirizzato al semplice IDE che abbiamo integrato in ClusterControl.
Puoi anche creare i tuoi ClusterControl Advisors. Puoi fare riferimento a te stesso per saperne di più sulla creazione leggendo Scrivi il tuo primo consigliere o prendi la serie in 2 parti per crearne una tua usando lo script di rilevamento Meltdown/Spectre.
In che modo i consulenti ClusterControl sono proattivi?
Tecnicamente, i consulenti ClusterControl agiscono principalmente come notificanti e letteralmente tuoi consulenti. ClusterControl Advisors ti avviserà se rileva un comportamento insolito se supera le soglie di base impostate per impostazione predefinita da ClusterControl. Solitamente le soglie applicate sono valori generici. Questi valori generici si basano sulle procedure consigliate e sul carico di lavoro o sulla configurazione dell'ambiente più comuni e accettabili. La maggior parte dell'impostazione predefinita degli advisor non fornisce allarmi o meccanismi di avviso nell'interfaccia utente di ClusterControl. Ti avvisa tramite l'interfaccia utente (vedi screenshot di esempio dell'advisor Posizione di archiviazione Binlog di seguito).
Come accennato in precedenza, gli Advisor possono essere modificati e sono modificabili tramite il nostro semplice editor o IDE. Ad esempio, in un cluster di replica MySQL, ClusterControl fornisce un advisor di posizione di archiviazione Binlog. Rileva che i binlog sono archiviati nella directory dei dati, dove avverte che devono essere al di fuori della directory dei dati.
Facciamo un esempio dall'elenco degli advisor e selezioniamo Connessioni attualmente utilizzate advisor . Modifichiamolo come mostrato di seguito,
o in alternativa, puoi andare su
Rendendolo più proattivo inviando allarmi, puoi modificarlo e aggiungere le seguenti funzioni proprio come di seguito,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Mentre, impostando la soglia su 20, aggiungi queste righe sotto appena all'interno dell'istruzione della condizione if in cui la soglia viene raggiunta al di sopra del valore di soglia specificato.
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;
}Puoi usare sysbench per testarlo. Nel mio test, vengo avvisato in modo proattivo inviando l'allarme. Questo mi verrà anche inviato via e-mail o può essere notificato se hai integrato notifiche di terze parti. Vedi lo screenshot qui sotto,
Avvertenze dei consulenti di ClusterControl
La modifica o la modifica di un advisor esistente in ClusterControl viene applicata a tutti i cluster. Ciò significa che devi controllare il tuo script se ha una condizione specifica applicabile solo al tuo cluster esistente (o MySQL o altri database supportati da ClusterControl). Questo perché gli advisor ClusterControl sono archiviati in un'unica fonte solo tramite il nostro DB cmon. Questi vengono estratti o recuperati da tutti i cluster che hai creato in ClusterControl.
Ad esempio, puoi farlo in uno script:
var hosts =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Questo script stamperà l'ID del cluster. Una volta ottenuto il valore, assegnalo a una variabile e utilizza tale variabile per valutare se è vero che questo ID cluster specifico è accettabile o meno in base all'attività desiderata che deve essere eseguita dal tuo consulente. Diciamo,
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;
}
…
….
…..che significa che se è cluster_id ==15, salta semplicemente o continua al ciclo successivo.
Conclusione
La creazione o la modifica di ClusterControl Advisor è una buona opportunità per sfruttare le funzionalità nascoste che ClusterControl può fornire. Potrebbe sembrare nascosto ma è lì:è solo che la funzione viene utilizzata di meno. Fornisce una funzionalità semplice ma potente chiamata ClusterControl Domain Specific Language (CDSL) che può essere utilizzata per compiti estremamente difficili che mancano a ClusterControl. Assicurati solo di conoscere tutte le avvertenze e di testare tutto prima di applicarlo finalmente al tuo ambiente di produzione.
