Surveiller votre base de données MySQL de manière proactive est impératif de nos jours. Il joue un rôle crucial et significatif dans la gestion et le contrôle de votre base de données, en particulier pour vos clusters de production. Manquer des informations spécifiques qui seraient bénéfiques pour améliorer votre base de données ou ne pas identifier la cause première des problèmes qui peuvent être rencontrés peut entraîner des difficultés extrêmes à résoudre ou à récupérer après ses jours de gloire.
La surveillance proactive de votre base de données MySQL permet à votre équipe de comprendre les performances de vos services de base de données. Fonctionne-t-il et livre-t-il en fonction de la charge de travail qu'il est censé supporter ? Disposez-vous de suffisamment de ressources pour que le serveur soit performant en fonction de la charge de travail qu'il gère actuellement ? La surveillance proactive applique des éléments qui doivent empêcher un désastre ou nuire à votre base de données qui vous en informera à l'avance. Ainsi, permettant aux DBA ou aux administrateurs d'effectuer des tâches importantes pour éviter de rencontrer des dysfonctionnements, une corruption des données, des exploits et des attaques de sécurité, ou un rebond inattendu du trafic dans votre cluster de bases de données. En y participant immédiatement, la surveillance proactive de MySQL doit être automatisée et doit fonctionner 24 heures sur 24, 7 jours sur 7, sans interruption et il appartient aux DBA, Devops, administrateurs de décider s'il est basé sur la priorité des tâches et à quel point il est crucial s'il nécessite une maintenance ou juste un travail de routine quotidien typique.
Surveillance proactive avec ClusterControl
ClusterControl offre un style varié pour surveiller vos serveurs de base de données MySQL. Son approche est comparable à d'autres outils de surveillance d'entreprise et à des solutions cloud d'entreprise. ClusterControl a tendance à appliquer toutes les meilleures pratiques de gestion et de surveillance des bases de données, mais avec la flexibilité de configuration afin d'obtenir la configuration souhaitée en fonction de votre environnement.
En ce qui concerne les alarmes et les notifications, ClusterControl a une approche mixte pour laquelle il existe des alarmes intégrées, puis il y a les conseillers dont nous discuterons plus en détail sur ce blog.
Alarmes ClusterControl pour MySQL
Les alarmes indiquent des problèmes susceptibles d'affecter ou de dégrader le cluster dans son ensemble. Cette interface fournit une explication détaillée du problème, ainsi que l'action recommandée (le cas échéant) pour résoudre le problème. Chaque alarme est classée comme :
-
Cluster
-
Récupération de cluster
-
Santé de la base de données
-
Performances de la base de données
-
Hôte
-
Nœud
-
Réseau
Une alarme peut être acquittée en cochant la case Ignorer ? case à cocher. Lorsqu'il est ignoré, aucune notification ne sera envoyée par e-mail. Une alarme ne peut pas être supprimée ou rejetée, mais vous pouvez la masquer de la liste en cliquant sur le bouton Masquer les alarmes ignorées.
Voir l'exemple de capture d'écran ci-dessous,
Proactivité avec ClusterControl
ClusterControl prend en charge la récupération automatique qui réagit chaque fois qu'une défaillance est détectée. La récupération automatique avec ClusterControl est l'une des fonctionnalités les plus proactives qui joue un rôle crucial en cas de sinistre.
L'activation de la récupération automatique est requise pour cette surveillance proactive qui réagit dans diverses situations, par exemple, si le nœud MySQL principal tombe en panne.
Dans ClusterControl, cela sera détecté immédiatement car il écoute la connexion avec le serveur de base de données, ou dans ce cas le serveur primaire. ClusterControl réagira dès que possible et appliquera un basculement.
Le basculement fait partie de la récupération de cluster activée. Étant donné que les deux boutons Cluster et Node sont activés, il suit la récupération du nœud comme vous le voyez ci-dessous.
En fonction de l'accessibilité des nœuds, ClusterControl essaiera de tenter en permanence en connectez-vous via SSH et essayez d'atteindre le nœud et essayez de récupérer en commençant à utiliser sysvinit ou systemd. Évidemment, vous pourriez penser qu'il applique un basculement et que ClusterControl essaie de démarrer le primaire défaillant. Cela pourrait signifier que deux nœuds de base de données sont disponibles, n'est-ce pas ? Bien que vrai, ClusterControl placera le principal défaillant dans un état de lecture seule lors de sa récupération. Voir ci-dessous,
Bien qu'il existe certaines options que vous pouvez définir pour gérer le mécanisme de basculement, vous devrait se référer à notre documentation pour cela car ce n'est pas l'objet de ce blog.
Utilisation des conseillers pour la proactivité avec ClusterControl
Dans ClusterControl, les conseillers seront localisés en allant dans
Dans un cluster Galera, il ajoute les conseillers spécifiques Galera comme indiqué ci-dessous ,
Personnalisation de vos conseillers MySQL ClusterControl
Les conseillers sont personnalisables et peuvent être modifiés selon vos besoins. Dans la capture d'écran des conseillers ci-dessus, cliquez simplement sur Modifier et vous serez redirigé vers l'IDE simple que nous avons intégré dans ClusterControl.
Vous pouvez également créer vos propres conseillers ClusterControl. Vous pouvez vous référer pour en savoir plus sur la création en lisant Write Your First Advisor ou prendre la série en 2 parties pour créer le vôtre en utilisant le script de détection Meltdown/Spectre.
Comment les conseillers ClusterControl sont-ils proactifs ?
Techniquement, les conseillers de ClusterControl agissent principalement en tant que notificateurs et littéralement vos conseillers. ClusterControl Advisors vous avertira s'il détecte un comportement inhabituel s'il dépasse les seuils de base définis par défaut par ClusterControl. Habituellement, les seuils appliqués sont des valeurs génériques. Ces valeurs génériques sont basées sur les meilleures pratiques et sur la configuration de charge de travail ou d'environnement la plus courante et la plus acceptable. La plupart des conseillers par défaut ne fournissent pas d'alarmes ou de mécanismes d'alerte dans l'interface utilisateur de ClusterControl. Il vous avertit via l'interface utilisateur (voir l'exemple de capture d'écran du conseiller d'emplacement de stockage Binlog ci-dessous).
Comme mentionné précédemment, les conseillers peuvent être modifiés et sont modifiables via notre simple éditeur ou IDE. Par exemple, dans un cluster de réplication MySQL, ClusterControl fournit un conseiller d'emplacement de stockage Binlog. Il détecte que les binlogs sont stockés dans le répertoire de données où il indique qu'il doit être en dehors du répertoire de données.
Prenons un exemple dans la liste des conseillers et sélectionnons le conseiller Connections actuellement utilisé . Modifions ceci comme indiqué ci-dessous,
ou bien, vous pouvez aller sur
En le rendant plus proactif en envoyant des alarmes, vous pouvez le modifier et ajouter les fonctions suivantes comme ci-dessous,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Alors que, en définissant le seuil sur 20, ajoutez ces lignes ci-dessous juste dans l'instruction de condition if où le seuil est atteint au-dessus de sa valeur de seuil donnée.
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;
}Vous pouvez utiliser sysbench pour le tester. Dans mon test, je suis averti de manière proactive en envoyant l'alarme. Cela me sera également envoyé par e-mail ou peut être notifié si vous avez intégré des notifications de tiers. Voir la capture d'écran ci-dessous,
Mises en garde des conseillers de ClusterControl
La modification ou l'édition d'un conseiller existant dans ClusterControl s'applique à tous les clusters. Cela signifie que vous devez vérifier dans votre script s'il a une condition spécifique applicable uniquement pour votre cluster existant (soit MySQL ou d'autres bases de données prises en charge par ClusterControl). En effet, les conseillers ClusterControl sont stockés dans une seule source uniquement via notre base de données cmon. Ceux-ci sont extraits ou récupérés par tous les clusters que vous avez créés dans ClusterControl.
Par exemple, vous pouvez le faire dans un script :
hôtes var =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Ce script imprimera l'ID du cluster. Une fois que vous obtenez la valeur, attribuez-la à une variable et utilisez cette variable pour évaluer s'il est vrai que cet ID de cluster spécifique est acceptable ou non en fonction de la tâche que vous souhaitez que votre conseiller effectue. Disons,
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;
}
…
….
…..ce qui signifie que si c'est le cluster_id ==15, alors sautez ou continuez jusqu'à la boucle suivante.
Conclusion
La création ou la modification des conseillers ClusterControl est une bonne occasion de tirer parti des fonctionnalités cachées que ClusterControl peut vous fournir. Il peut sembler caché, mais il est là - c'est juste que la fonctionnalité est moins utilisée. Il fournit une fonctionnalité simple mais puissante appelée ClusterControl Domain Specific Language (CDSL) qui peut être utilisée pour des tâches extrêmement difficiles qui manquent à ClusterControl. Assurez-vous simplement de connaître toutes les mises en garde et de tout tester avant de finalement l'appliquer à votre environnement de production.
