Dans les articles de blog précédents, nous avons couvert des sujets sur la surveillance de votre cluster Galera, qu'il s'agisse de MySQL ou de MariaDB. Bien que les versions technologiques ne diffèrent pas beaucoup, MariaDB Cluster a quelques changements majeurs depuis la version 10.4.2. Dans cette version, il prend en charge Galera Cluster 4 et propose de nouvelles fonctionnalités intéressantes que nous examinerons dans cet article de blog.
Pour les débutants qui ne sont pas encore familiarisés avec MariaDB Cluster, est un cluster multimaître virtuellement synchrone pour MariaDB. Il est disponible uniquement sur Linux et ne prend en charge que les moteurs de stockage XtraDB/InnoDB (bien qu'il existe un support expérimental pour MyISAM - voir la variable système wsrep_replicate_myisam).
Le logiciel est une technologie groupée qui est alimentée par MariaDB Server, le correctif MySQL-wsrep pour MySQL Server et MariaDB Server développé par Codership (prend en charge les systèmes d'exploitation de type Unix) et la bibliothèque du fournisseur Galera wsrep.
Vous pouvez comparer ce produit avec MySQL Group Replication ou avec MySQL InnoDB Cluster, qui vise à fournir une haute disponibilité. (Bien qu'ils diffèrent diversement sur les principes et les approches de la fourniture de la haute disponibilité.)
Maintenant que nous avons couvert les bases, dans ce blog, nous allons fournir des conseils que nous pensons utiles lors de la surveillance de votre cluster MariaDB.
L'essentiel du cluster MariaDB
Lorsque vous commencez à utiliser MariaDB Cluster, vous devez identifier quel est exactement votre objectif et pourquoi vous avez choisi MariaDB Cluster en premier lieu. Vous devez d'abord digérer quelles sont les fonctionnalités et leurs avantages lors de l'utilisation de MariaDB Cluster. La raison de les identifier est que ce sont essentiellement ce qui doit être surveillé et vérifié pour que vous puissiez déterminer les performances, les conditions de santé normales et s'il fonctionne conformément à vos plans.
Essentiellement, il est identifié comme aucun retard d'esclave, aucune transaction perdue, une évolutivité en lecture et des latences client plus petites. Alors des questions peuvent se poser comme, comment cela ne fait-il pas de retard d'esclave, ou de transactions perdues ? Comment cela rend-il la lecture évolutive ou avec des latences plus petites côté client ? Ces zones sont l'un des domaines clés que vous devez examiner et surveiller, en particulier pour une utilisation intensive en production.
Bien que le cluster MariaDB lui-même puisse être personnalisé en conséquence. L'application de modifications au comportement par défaut telles que pc.weight ou pc.ignore_quorum, ou même l'utilisation de la multidiffusion avec UDP pour un grand nombre de nœuds, peut avoir un impact sur la façon dont vous surveillez la nature de votre cluster MariaDB. Mais d'un autre côté, les variables d'état les plus essentielles sont généralement votre doublure argentée ici sachant que l'état et le flux de votre cluster se portent bien ou sa dégradation montrant un problème possible conduisant à une panne catastrophique à l'avance.
Surveillez toujours l'activité de votre serveur (réseau, disque, charge, mémoire et CPU)
Surveiller l'activité de votre serveur peut également être une tâche complexe si vous disposez d'une pile très compliquée entrelacée dans l'architecture de votre base de données. Cependant, pour un cluster MariaDB, il est toujours préférable que vos nœuds soient toujours configurés de manière aussi dédiée et simple que possible. Bien que cela ne vous empêche pas d'utiliser toutes les ressources disponibles, vous trouverez ci-dessous les domaines clés communs que vous devez examiner.
Réseau
Galera Cluster 4 propose la réplication en continu comme l'une des principales fonctionnalités et modifications par rapport à la version précédente. Étant donné que la réplication en continu résout les inconvénients qu'elle avait dans les versions précédentes, mais lui permet de gérer plus de 2 Go d'ensembles d'écriture depuis Galera Cluster 4. Cela permet de fragmenter les grosses transactions et il est fortement recommandé de l'activer uniquement au niveau de la session. Cela signifie que la surveillance de votre activité réseau est très importante et cruciale pour l'activité normale de votre cluster MariaDB. Cela vous aidera à identifier quel nœud a eu le trafic réseau le plus ou le plus élevé en fonction de la période de temps.
Alors, comment cela vous aidera-t-il à améliorer l'identification des nœuds avec le trafic réseau le plus élevé ? Eh bien, cela vous permet d'améliorer la topologie de votre base de données ou la couche architecturale de votre cluster de bases de données. L'utilisation d'équilibreurs de charge ou d'un proxy de base de données vous permet de configurer de manière proactive le trafic de votre base de données, en particulier lors de la détermination des écritures spécifiques devant être dirigées vers un nœud spécifique. Disons que sur les 3 nœuds, l'un d'eux est plus capable de gérer des requêtes volumineuses et volumineuses en raison de différences avec les spécifications matérielles. Cela vous permet de gérer une plus grande partie de vos dépenses d'investissement et d'améliorer votre planification des capacités à mesure que les demandes sur une période donnée changent.
Disque
Comme l'activité du réseau est également importante pour les performances de votre disque, en particulier pendant le temps de vidage. Il est également préférable de déterminer les performances du temps engagé et de la récupération lorsque la charge de pointe élevée est atteinte. Il y a des moments où vous stockez votre hôte de base de données non seulement en étant dédié à une activité Galera Cluster, mais également en mélangeant avec d'autres outils comme Docker, des proxies SQL tels que ProxySQL ou MaxScale. Cela vous donne le contrôle avec des serveurs à faible charge et vous permet d'utiliser les ressources de rechange disponibles qui peuvent être utilisées à d'autres fins bénéfiques, en particulier pour votre pile d'architecture de base de données. Une fois que vous êtes en mesure de déterminer quel nœud, lors de la surveillance, a la charge la plus faible mais est toujours capable de gérer son utilisation des E/S de disque, vous pouvez sélectionner le nœud spécifique tout en surveillant le temps qui passe. Encore une fois, cela vous donne toujours une meilleure gestion de votre capacité de planification.
Activité du processeur, de la mémoire et du chargement
Permettez-moi de présenter brièvement ces trois domaines à prendre en compte lors de la surveillance. Dans cette section, il est toujours préférable d'avoir une meilleure observabilité des domaines suivants à la fois. C'est plus rapide et plus facile à comprendre, en particulier en éliminant un goulot d'étranglement des performances ou en identifiant les bogues qui provoquent le blocage de vos nœuds et qui peuvent également affecter les autres nœuds et la possibilité de descendre du cluster.
Alors, comment l'activité du processeur, de la mémoire et de la charge lors de la surveillance aide-t-elle votre cluster MariaDB ? Eh bien, comme je l'ai mentionné ci-dessus, c'est l'une des rares choses qui reste un facteur important pour les vérifications de routine quotidiennes. Maintenant, cela vous aide également à identifier s'il s'agit d'occurrences périodiques ou aléatoires. S'il est périodique, il peut être lié à des sauvegardes exécutées dans l'un de vos nœuds Galera, ou il s'agit d'une requête massive qui nécessite une optimisation. Par exemple, de mauvaises requêtes sans index appropriés ou une utilisation déséquilibrée de la récupération de données, comme une comparaison de chaînes pour une chaîne aussi grande. Cela peut être indéniablement inapplicable pour les bases de données de type OLTP telles que MariaDB Cluster, surtout si c'est vraiment la nature et les exigences de votre application. Mieux vaut utiliser d'autres outils analytiques tels que MariaDB Columnstore ou d'autres outils de traitement analytique tiers (Apache Spark, Kafka ou MongoDB, etc.) pour la récupération de données de chaînes volumineuses et/ou la correspondance de chaînes.
Donc, avec tous ces domaines clés surveillés, la question est de savoir comment cela doit être surveillé ? Il doit être surveillé au moins par minute. Avec une surveillance raffinée, c'est-à-dire par seconde de métriques collectives, cela peut être gourmand en ressources et très gourmand en termes de ressources. Bien qu'une demi-minute de collectivité soit acceptable, surtout si vos données et votre RPO (objectif de point de récupération) sont très faibles, vous avez donc besoin de métriques de données plus granulaires et en temps réel. Il est très important que vous puissiez superviser l'ensemble de votre cluster de bases de données. En dehors de cela, il est également préférable et important que, quelle que soit la métrique que vous surveillez, vous disposiez du bon outil pour attirer votre attention lorsque les choses sont en danger ou même simplement des avertissements. L'utilisation de l'outil approprié tel que ClusterControl vous aide à gérer ces domaines clés à surveiller. J'utilise ici une version gratuite ou une édition communautaire de ClusterControl et m'aide à surveiller mes nœuds sans tracas depuis l'installation jusqu'à la surveillance des nœuds en quelques clics. Par exemple, voir les captures d'écran ci-dessous :
La vue est un aperçu plus raffiné et rapide de ce qui se passe actuellement. Un graphique plus granulaire peut également être utilisé,
ou avec un modèle de données plus puissant et riche qui prend également en charge le langage de requête peut vous fournir une analyse des performances de votre cluster MariaDB basée sur des données historiques comparant ses performances en temps opportun. Par exemple,
Cela vous fournit simplement des métriques plus visibles. Vous voyez donc à quel point il est vraiment important d'avoir le bon outil lors de la surveillance de votre cluster MariaDB.
Assurez la surveillance collective de vos variables statistiques de cluster MariaDB
De temps en temps, il ne peut pas être inévitable que les versions de MariaDB Cluster produisent de nouvelles statistiques pour surveiller ou améliorer la nature de la surveillance de la base de données en fournissant plus de variables d'état et en affinant les valeurs à examiner. Comme ce que j'ai mentionné ci-dessus, j'utilise ClusterControl pour surveiller mes nœuds dans cet exemple de blog. Cependant, cela ne signifie pas que c'est le meilleur outil qui soit. Je veux dire que PMM de Percona est très riche en matière de surveillance collective pour chaque variable statistique que chaque fois que MariaDB Cluster a de nouvelles variables statistiques à offrir, vous pouvez en tirer parti et également le modifier car PMM est un outil open source. C'est un grand avantage que vous ayez également toute la visibilité de votre cluster MariaDB car chaque aspect compte, en particulier dans une base de données basée sur la production qui répond à des centaines de milliers de requêtes par minute.
Mais soyons plus précis sur le problème ici. Quelles sont ces variables statistiques à examiner ? Il y a beaucoup de choses sur lesquelles compter pour un cluster MariaDB, mais en nous concentrant à nouveau sur les fonctionnalités et les avantages que nous pensons que vous utilisez le cluster MariaDB et ce qu'il a à offrir, nous nous concentrerons là-dessus.
Cluster Galera - Contrôle de flux
Le contrôle de flux de votre cluster MariaDB vous donne un aperçu de la façon dont la santé de la réplication fonctionne sur l'ensemble du cluster. Le processus de réplication dans Galera Cluster utilise un mécanisme de rétroaction, ce qui signifie qu'il signale tous les nœuds de ce cluster et signale si le nœud doit suspendre ou reprendre la réplication en fonction de ses besoins. Cela empêche également un nœud d'être trop en retard pendant que les autres appliquent les transactions entrantes. C'est ainsi que le contrôle de flux remplit sa fonction dans Galera. Maintenant, cela doit être vu et à ne pas négliger lors de la surveillance de votre cluster MariaDB. Ceci, comme mentionné dans l'un des avantages de l'utilisation de MariaDB Cluster, est qu'il évite d'avoir un retard d'esclave. Bien que ce soit trop naïf pour comprendre le contrôle de flux et le décalage esclave, mais avec le contrôle de flux, cela aura un impact sur les performances de votre cluster Galera lorsqu'il y a beaucoup de file d'attente et que les validations ou le vidage des pages sur le disque deviennent très faibles pour de tels problèmes de disque ou c'est juste que la requête en cours d'exécution est une mauvaise requête. Si vous débutez dans le fonctionnement de Galera, vous serez peut-être intéressé par la lecture de cet article externe sur le contrôle de flux dans Galera.
Octets envoyés/reçus
Les octets envoyés ou reçus sont en corrélation avec l'activité réseau et sont même l'un des domaines clés à regarder côte à côte avec le contrôle de flux. Cela vous permet de déterminer quel nœud est le plus impacté ou attribué aux problèmes de performances qui souffrent au sein de votre cluster Galera. C'est très important car vous pouvez vérifier s'il peut y avoir une dégradation en termes de matériel tel que votre périphérique réseau ou le périphérique de stockage sous-jacent pour lequel la synchronisation des pages sales peut prendre trop de temps.
Chargement du cluster
Eh bien, il s'agit davantage de l'activité de la base de données que de la quantité de modifications ou de récupération de données qui ont été interrogées ou effectuées jusqu'à présent depuis la disponibilité du serveur. Il vous aide à exclure les types de requêtes qui affectent principalement les performances de votre cluster de base de données. Cela vous permet d'apporter une marge d'amélioration, notamment sur l'équilibrage de la charge de vos requêtes de base de données. L'utilisation de ProxySQL vous aide ici avec une approche plus raffinée et granulaire pour le routage des requêtes. Bien que MaxScale offre également cette fonctionnalité, ProxySQL a plus de granularité bien qu'il ait également un impact sur les performances ou le coût. L'impact survient lorsque vous n'avez qu'un seul ProxySQL en tant que proxy SQL pour élaborer le routage des requêtes et cela peut avoir des difficultés lorsque le trafic est élevé. Ayant un coût, si vous ajoutez plus de nœuds ProxySQL pour équilibrer davantage le trafic qu'un KeepAlived sous-jacent. Bien qu'il s'agisse d'un combo parfait, il peut être exécuté à faible coût jusqu'à ce que vous en ayez besoin. Cependant, comment pourrez-vous déterminer si nécessaire, n'est-ce pas ? C'est la question qui demeure ici, donc un œil attentif pour surveiller ces domaines clés est très important, non seulement pour l'observabilité, mais aussi pour l'amélioration des performances de votre cluster de base de données au fil du temps.
En tant que tel, il y a des tonnes de variables à examiner dans un cluster MariaDB. La chose la plus importante ici que vous devez prendre en compte est l'outil que vous utilisez pour surveiller votre cluster de bases de données. Comme mentionné précédemment, je préfère utiliser la licence de la version gratuite de ClusterControl (Community Edition) ici dans ce blog car elle me donne plus de flexibilité à regarder dans un Galera Cluster. Voir l'exemple ci-dessous,
J'ai marqué ou entouré en rouge les onglets qui me permettent de surveiller visuellement la santé de mon cluster MariaDB. Disons que si votre application est gourmande en utilisant de temps en temps la réplication en continu et qu'elle envoie un grand nombre de fragments (transfert réseau important) pour l'interactivité du cluster, il est préférable de déterminer dans quelle mesure vos nœuds peuvent gérer le stress. Surtout pendant les tests de résistance avant de pousser des modifications spécifiques dans votre application, il est toujours préférable d'essayer de tester pour déterminer la gestion de la capacité de votre produit d'application et de déterminer si vos nœuds de base de données et votre conception actuels peuvent gérer la charge des exigences de votre application.
Même sur une édition communautaire du ClusterControl, je suis capable de rassembler des résultats granulaires et plus raffinés de la santé de mon cluster MariaDB. Voir ci-dessous,
C'est ainsi que vous aborderez le monitoring de votre cluster MariaDB. Une visualisation parfaite est toujours plus facile et plus rapide à gérer. Lorsque les choses tournent mal, vous ne pouvez pas vous permettre de perdre votre productivité et les temps d'arrêt peuvent également avoir un impact sur votre entreprise. Bien que la gratuité ne vous offre pas le luxe et le confort lors de la gestion de bases de données à fort trafic, le fait d'avoir des alarmes, des notifications et la gestion de bases de données dans une zone est un complément facile à utiliser que ClusterControl peut faire.
Conclusion
MariaDB Cluster n'est pas aussi simple à surveiller que les configurations maître-esclave MySQL/MariaDB asynchrones traditionnelles. Cela fonctionne différemment et vous devez disposer des bons outils pour déterminer ce qui se passe et ce qui se passe dans votre cluster de bases de données. Préparez toujours votre planification de capacité à l'avance avant d'exécuter votre cluster MariaDB sans surveillance appropriée au préalable. Il est toujours préférable que la charge et l'activité de votre base de données soient connues avant un événement catastrophique.
