La majorité des administrateurs de bases de données effectuent de temps en temps des vérifications de l'état de leurs bases de données. Habituellement, cela se produisait sur une base quotidienne ou hebdomadaire. Nous avons précédemment expliqué pourquoi ces contrôles sont importants et ce qu'ils doivent inclure.
Pour vous assurer que vos systèmes sont en bon état, vous devez parcourir un grand nombre d'informations - statistiques d'hôte, statistiques MySQL, statistiques de charge de travail, état des sauvegardes, packages de base de données, journaux, etc. De telles données devraient être disponibles dans chaque environnement correctement surveillé, bien qu'elles soient parfois dispersées sur plusieurs emplacements - vous pouvez avoir un outil pour surveiller l'état de MySQL, un autre outil pour collecter des statistiques système, peut-être un ensemble de scripts, par exemple, pour vérifier l'état de vos sauvegardes. Cela rend les vérifications de l'état beaucoup plus chronophages qu'elles ne le devraient - le DBA doit assembler les différentes pièces pour comprendre l'état du système.
Les outils intégrés comme ClusterControl ont l'avantage que tous les bits sont situés au même endroit (ou dans la même application). Cela ne signifie toujours pas qu'ils sont situés les uns à côté des autres - ils peuvent être situés dans différentes sections de l'interface utilisateur et un administrateur de base de données peut devoir passer un certain temps à cliquer sur l'interface utilisateur pour accéder à toutes les données intéressantes.
L'idée derrière la création de rapports opérationnels est de mettre toutes les données les plus importantes dans un seul document, qui peut être rapidement examiné pour comprendre l'état des bases de données.
Les Rapports Opérationnels sont disponibles depuis le menu Menu Latéral -> Rapports Opérationnels :
Une fois sur place, une liste de rapports créés manuellement ou automatiquement, selon un calendrier prédéfini, vous sera présentée :
Si vous souhaitez créer un nouveau rapport manuellement, vous utiliserez l'option "Créer". Choisissez le type de rapport, le nom du cluster (pour un rapport par cluster), les destinataires de l'e-mail (facultatif - si vous souhaitez que le rapport vous soit envoyé), et vous avez pratiquement terminé :
Les rapports peuvent également être programmés pour être créés régulièrement :
À l'heure actuelle, 5 types de rapports sont disponibles :
- Rapport de disponibilité - Tous les clusters.
- Rapport de sauvegarde - Tous les clusters.
- Rapport sur les modifications de schéma :cluster basé sur MySQL/MariaDB uniquement.
- Rapport système quotidien - Par cluster.
- Rapport de mise à niveau de package - Par cluster.
Rapport de disponibilité
Les rapports de disponibilité se concentrent sur la disponibilité. Il comprend trois sections. Tout d'abord, récapitulatif des disponibilités :
Vous pouvez voir des informations sur les statistiques de disponibilité de vos bases de données, le type de cluster, le temps de fonctionnement et les temps d'arrêt totaux, l'état actuel du cluster et la dernière modification de cet état.
Une autre section donne plus de détails sur la disponibilité de chaque cluster. La capture d'écran ci-dessous ne montre qu'un des clusters de bases de données :
Nous pouvons voir quand un nœud a changé d'état et quelle a été la transition. C'est un bon endroit pour vérifier s'il y a eu des problèmes récents avec le cluster. Des données similaires sont présentées dans la troisième section de ce rapport, où vous pouvez parcourir l'historique des modifications de l'état du cluster.
Rapport de sauvegarde
Le deuxième type de rapport est celui qui couvre les sauvegardes de tous les clusters. Il contient deux sections - résumé de la sauvegarde et détails de la sauvegarde, où la première vous donne essentiellement un bref résumé de la date de création de la dernière sauvegarde, si elle a réussi ou échoué, l'état de vérification de la sauvegarde, le taux de réussite et la période de rétention :
ClusterControl fournit également des exemples de politique de sauvegarde s'il trouve l'un des clusters de bases de données surveillés en cours d'exécution sans aucune sauvegarde planifiée ou esclave retardé configuré. Viennent ensuite les détails de la sauvegarde :
Vous pouvez également consulter la liste des sauvegardes exécutées sur le cluster avec leur état, leur type et leur taille dans l'intervalle spécifié. C'est aussi près que possible d'être certain que les sauvegardes fonctionnent correctement sans exécuter un test de récupération complet. Nous recommandons vivement que de tels tests soient effectués de temps en temps. La bonne nouvelle est que ClusterControl prend en charge la restauration et la vérification basées sur MySQL sur un hôte autonome sous Sauvegarde -> Restaurer la sauvegarde.
Rapport système quotidien
Ce type de rapport contient des informations détaillées sur un cluster particulier. Il commence par un récapitulatif des différentes alertes liées au cluster :
La section suivante concerne l'état des nœuds qui font partie du cluster :
Vous disposez d'une liste des nœuds du cluster, de leur type, de leur rôle (maître ou esclave), de l'état du nœud, de la disponibilité et de l'OS.
Une autre section du rapport est le résumé de la sauvegarde, comme nous l'avons vu ci-dessus. La suivante présente un résumé des principales requêtes du cluster :
Enfin, nous voyons un "Aperçu de l'état des nœuds" dans lequel vous seront présentés des graphiques liés aux métriques du système d'exploitation et de MySQL pour chaque nœud.
Comme vous pouvez le voir, nous avons ici des graphiques couvrant tous les aspects de la charge sur l'hôte - CPU, mémoire, réseau, disque, charge CPU et disque libre. C'est suffisant pour avoir une idée si quelque chose de bizarre s'est produit récemment ou non. Vous pouvez également voir quelques détails sur la charge de travail MySQL :combien de requêtes ont été exécutées, quel type de requête, comment les données ont été accédées (via quel gestionnaire) ? Ceci, en revanche, devrait suffire à résoudre la plupart des problèmes du côté de MySQL. Ce que vous voulez regarder, ce sont tous les pics et creux que vous n'avez pas vus dans le passé. Peut-être qu'une nouvelle requête a été ajoutée au mélange et, par conséquent, handler_read_rnd_next monté en flèche? Il y a peut-être eu une augmentation de la charge du processeur et un nombre élevé de connexions pourrait indiquer une charge accrue sur MySQL, mais aussi une sorte de conflit. Il peut être bon d'étudier un modèle inattendu, afin que vous sachiez ce qui se passe.
Rapport de mise à niveau du package
Ce rapport donne un résumé des packages disponibles pour la mise à niveau par le gestionnaire de référentiel sur les hôtes surveillés. Pour un reporting précis, assurez-vous de toujours utiliser des référentiels stables et fiables sur chaque hôte. Dans certaines occasions indésirables, les hôtes surveillés peuvent être configurés avec un référentiel obsolète après une mise à niveau (par exemple, chaque version majeure de MariaDB utilise un référentiel différent), un référentiel interne incomplet (par exemple, une mise en miroir partielle de l'amont) ou un référentiel à la pointe de la technologie (généralement pour les versions instables). packages de construction nocturne).
La première section est le résumé de la mise à jour :
Il résume le nombre total de packages disponibles pour la mise à niveau ainsi que le service géré associé pour le cluster, comme l'équilibreur de charge, l'adresse IP virtuelle et l'arbitre. Ensuite, ClusterControl fournit une liste détaillée de packages, regroupés par type de package pour chaque hôte :
Ce rapport fournit la version disponible et peut grandement nous aider à planifier efficacement notre fenêtre de maintenance. Pour les mises à niveau critiques telles que les packages de sécurité et de base de données, nous pourrions les privilégier par rapport aux mises à niveau non critiques, qui pourraient être consolidées avec d'autres fenêtres de maintenance moins prioritaires.
Rapport de modification de schéma
Ce rapport compare les modifications de la base de données MySQL/MariaDB sélectionnées dans la structure de la table qui se sont produites entre deux rapports générés différents. Dans les anciennes versions de MySQL/MariaDB, l'opération DDL est une opération non atomique (avant 8.0) et nécessite une copie complète de la table (avant 5.6 pour la plupart des opérations) - bloquant les autres transactions jusqu'à ce qu'elle se termine. Les modifications de schéma peuvent devenir très pénibles une fois que vos tables reçoivent une quantité importante de données et doivent être soigneusement planifiées, en particulier dans une configuration en cluster. Dans un environnement de développement à plusieurs niveaux, nous avons vu de nombreux cas où les développeurs modifient silencieusement la structure de la table, ce qui a un impact significatif sur les performances des requêtes.
Pour que ClusterControl produise un rapport précis, des options spéciales doivent être configurées dans le fichier de configuration CMON pour le cluster respectif :
- schema_change_detection_address - Des vérifications seront exécutées à l'aide de SHOW TABLES/SHOW CREATE TABLE pour déterminer si le schéma a changé. Les vérifications sont exécutées sur l'adresse spécifiée et est au format HOSTNAME:PORT. Les schema_change_detection_databases doit également être défini. Un différentiel d'une table modifiée est créé (à l'aide de diff).
- schema_change_detection_databases - Liste séparée par des virgules des bases de données à surveiller pour les changements de schéma. Si vide, aucune vérification n'est effectuée.
Dans cet exemple, nous aimerions surveiller les modifications de schéma pour la base de données "myapp" et "sbtest" sur notre cluster MariaDB avec l'ID de cluster 27. Choisissez l'un des nœuds de base de données comme valeur de schema_change_detection_address . Pour la réplication MySQL, il doit s'agir de l'hôte maître ou de tout hôte esclave contenant les bases de données (au cas où la réplication partielle est active). Ensuite, dans /etc/cmon.d/cmon_27.cnf, ajoutez les deux lignes suivantes :
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestRedémarrez le service CMON pour charger la modification :
$ systemctl restart cmonPour le premier et principal rapport, ClusterControl ne renvoie que le résultat de la collecte des métadonnées, comme ci-dessous :
Avec le premier rapport comme ligne de base, les rapports suivants renverront la sortie que nous attendons pour :
Notez que seuls les nouveaux tableaux ou les tableaux modifiés sont imprimés dans le rapport. Le premier rapport est uniquement destiné à la collecte de métadonnées à des fins de comparaison dans les cycles suivants, nous devons donc l'exécuter au moins deux fois pour voir la différence.
Avec ce rapport, vous pouvez désormais rassembler les empreintes de la structure de la base de données et comprendre comment votre base de données a évolué au fil du temps.
Réflexions finales
Le rapport opérationnel est un moyen complet de comprendre l'état de votre infrastructure de base de données. Il est conçu pour le personnel opérationnel ou de gestion et peut être très utile pour analyser les opérations de votre base de données. Les rapports peuvent être générés sur place ou vous être envoyés par e-mail, ce qui facilite les choses si vous disposez d'un silo de rapports.
Nous serions ravis d'entendre vos commentaires sur tout ce que vous aimeriez voir inclus dans le rapport, ce qui manque et ce qui n'est pas nécessaire.
