Mysql
 sql >> Base de données >  >> RDS >> Mysql

Quoi surveiller dans MySQL 8.0

La surveillance est indispensable dans tous les environnements, et les bases de données ne font pas exception. Une fois que votre infrastructure de base de données est opérationnelle, vous devrez garder un œil sur ce qui se passe. La surveillance est indispensable si vous voulez être sûr que tout va bien, mais aussi si vous faites les ajustements nécessaires pendant que votre système grandit et évolue. Cela vous permettra d'identifier les tendances, de planifier des mises à niveau ou des améliorations, ou de réagir de manière adéquate à tout problème ou erreur pouvant survenir avec de nouvelles versions, des objectifs différents, etc.

Pour chaque technologie de base de données, il y a différentes choses à surveiller. Certains d'entre eux sont spécifiques au moteur de base de données, au fournisseur ou même à la version particulière que vous utilisez. Les clusters de bases de données dépendent fortement de l'infrastructure sous-jacente, de sorte que les statistiques de réseau et d'exploitation sont également intéressantes à voir par les administrateurs de base de données.

Lors de l'exécution de plusieurs systèmes de bases de données, la surveillance de ces systèmes peut devenir une véritable corvée.

Dans ce blog, nous examinerons ce dont vous avez besoin pour surveiller un environnement MySQL 8.0. Nous examinerons également les fonctionnalités de surveillance du contrôle des clusters, qui peuvent vous aider à suivre gratuitement l'état de vos bases de données.

Surveillance du système d'exploitation et de la base de données

Lors de l'observation d'un cluster ou d'un nœud de base de données, il y a deux points principaux à prendre en compte :le système d'exploitation et l'instance MySQL elle-même. Vous devrez définir les métriques que vous allez surveiller des deux côtés et comment vous allez le faire. Vous devez toujours suivre le paramètre dans le sens de votre système, et vous devez rechercher des modifications sur le modèle de comportement.

Gardez à l'esprit que lorsqu'un de vos paramètres est affecté, cela peut également en affecter d'autres, ce qui complique le dépannage du problème. Avoir un bon système de surveillance et d'alerte est essentiel pour rendre cette tâche aussi simple que possible.

Dans la plupart des cas, vous devrez utiliser certains outils, car il est difficile d'en trouver un pour couvrir toutes les métriques souhaitées.

Surveillance du système d'exploitation

Une chose importante (qui est commune à tous les moteurs de base de données et même à tous les systèmes) est de surveiller le comportement du système d'exploitation. Voici quelques points à vérifier ici. Vous trouverez ci-dessous les principales ressources système à surveiller sur un serveur de base de données. C'est en fait aussi la liste des toutes premières choses à vérifier.

Utilisation du processeur

Une utilisation élevée du processeur n'est pas une mauvaise chose tant que vous n'atteignez pas la limite. Un pourcentage excessif d'utilisation du processeur peut être un problème s'il ne s'agit pas d'un comportement habituel. Dans ce cas, il est essentiel d'identifier le ou les processus qui génèrent ce problème. Si le problème vient du processus de la base de données, vous devrez vérifier ce qui se passe dans la base de données.

Utilisation de la mémoire RAM ou SWAP

Idéalement, toute votre base de données devrait être stockée en mémoire, mais ce n'est pas toujours possible. Donnez à MySQL autant que vous pouvez vous le permettre, mais laissez-en suffisamment pour que les autres processus fonctionnent.

Si vous voyez une valeur élevée pour cette métrique et que rien n'a changé dans votre système, vous devez probablement vérifier la configuration de votre base de données. Des paramètres tels que shared_buffers et work_mem peuvent affecter cela directement car ils définissent la quantité de mémoire à utiliser pour la base de données MySQL. L'échange est réservé aux urgences et ne doit pas être utilisé. Assurez-vous également que votre système d'exploitation est configuré pour laisser MySQL décider de l'utilisation de l'échange.

Utilisation du disque 

L'utilisation du disque est l'une des mesures clés à surveiller et à alerter. Assurez-vous d'avoir toujours de l'espace libre pour les nouvelles données, les fichiers temporaires, les instantanés ou les sauvegardes.

La surveillance des valeurs de métriques strictes n'est pas suffisante. Une augmentation anormale de l'utilisation de l'espace disque ou une consommation excessive d'accès disque sont des éléments essentiels à surveiller car vous pourriez avoir un nombre élevé d'erreurs enregistrées dans le fichier journal MySQL ou une configuration de cache moche qui pourrait générer une consommation d'accès disque vitale au lieu de utiliser la mémoire pour traiter les requêtes. Assurez-vous de pouvoir détecter les comportements anormaux même si vos métriques d'avertissement et critiques ne sont pas encore atteintes.

Avec la surveillance de l'espace, nous devons également surveiller l'activité du disque. Les principales valeurs à surveiller sont :

  • Requêtes de lecture/écriture
  • Longueur de la file d'attente d'E/S
  • Attente moyenne des E/S
  • Temps moyen de lecture/écriture
  • Bande passante en lecture/écriture

Vous pouvez utiliser iostat ou pt-diskstats de Percona pour voir tous ces détails.

Les choses qui peuvent affecter les performances de votre disque sont souvent liées au transfert de données depuis et vers votre disque. Surveillez donc les processus anormaux qui peuvent être lancés par d'autres utilisateurs.

Moyenne de charge

Une mesure de performance tout-en-un. Comprendre Linux Load est essentiel pour surveiller les systèmes dépendants du système d'exploitation et de la base de données.

Moyenne de charge liée aux trois points mentionnés ci-dessus. Une charge moyenne élevée peut être générée par une utilisation excessive du processeur, de la RAM ou du disque.

Réseau

À moins de faire des sauvegardes ou de transférer de grandes quantités de données, cela ne devrait pas être le goulot d'étranglement.

Un problème de réseau peut affecter tous les systèmes car l'application ne peut pas se connecter (ou connecter les paquets perdants) à la base de données, il s'agit donc d'une métrique importante à surveiller en effet. Vous pouvez surveiller la latence ou la perte de paquets, et le problème principal peut être une saturation du réseau, un problème matériel ou simplement une mauvaise configuration réseau.

Surveillance de la base de données

Bien que la surveillance soit indispensable, elle n'est généralement pas gratuite. Il y a toujours un coût sur les performances de la base de données, en fonction de ce que vous surveillez, vous devez donc éviter de surveiller des choses que vous n'utiliserez pas.

En général, il existe deux façons de surveiller vos bases de données, à partir des journaux ou du côté de la base de données en interrogeant.

Dans le cas des journaux, pour pouvoir les utiliser, vous devez avoir un niveau de journalisation élevé, ce qui génère un accès disque élevé et peut affecter les performances de votre base de données.

Pour le mode d'interrogation, chaque connexion à la base de données utilise des ressources, donc en fonction de l'activité de votre base de données et des ressources affectées, cela peut également affecter les performances.

Bien sûr, il existe de nombreuses métriques dans MySQL. Ici, nous allons nous concentrer sur le plus important.

Surveillance des sessions actives

Vous devez également suivre le nombre de sessions actives et le statut DB up down. Souvent, pour comprendre le problème, vous devez voir combien de temps la base de données fonctionne. afin que nous puissions l'utiliser pour détecter les réapparitions.

La prochaine chose serait un certain nombre de sessions. Si vous êtes proche de la limite, vous devez vérifier si quelque chose ne va pas ou si vous avez juste besoin d'incrémenter la valeur max_connections. La différence de nombre peut être une augmentation ou une diminution des connexions. Une mauvaise utilisation du regroupement de connexions, des problèmes de verrouillage ou de réseau sont les problèmes les plus courants liés au nombre de connexions.

Les valeurs clés ici sont

  • Temps de disponibilité
  • Threads_connectés
  • Max_used_connections
  • Aborted_connects

Verrous de base de données

Si vous avez une requête en attente d'une autre requête, vous devez vérifier si cette autre requête est un processus normal ou quelque chose de nouveau. Dans certains cas, si quelqu'un fait une mise à jour sur une grande table, par exemple, cette action peut affecter le comportement normal de votre base de données, générant un nombre élevé de verrous.

Surveillance de la réplication

Les mesures clés à surveiller pour la réplication sont le décalage et l'état de la réplication. Non seulement l'état up down mais aussi le lag car une augmentation continue de cette valeur n'est pas très bon signe car cela signifie que l'esclave n'est pas capable de rattraper son maître.

Les problèmes les plus courants sont les problèmes de réseau, les problèmes de ressources matérielles ou les problèmes de sous-dimensionnement. Si vous rencontrez un problème de réplication, vous devrez le savoir dès que possible car vous devrez le résoudre pour garantir l'environnement de haute disponibilité.

La réplication est mieux surveillée en vérifiant SLAVE STATUS et les paramètres suivants :

  • SLAVE_RUNNING
  • SLAVE_IO_Running
  • SLAVE_SQL_RUNNING
  • LAST_SQL_ERRNO
  • SECONDS_BEHIND_MASTER

Sauvegardes

Malheureusement, l'édition communautaire vanille n'est pas livrée avec le gestionnaire de sauvegarde. Vous devez savoir si la sauvegarde est terminée et si elle est utilisable. Habituellement, ce dernier point n'est pas pris en compte, mais c'est probablement la vérification la plus critique dans un processus de sauvegarde. Ici, nous devrions utiliser des outils externes comme percona-xtrabackup ou ClusterControl.

Journaux de la base de données

Vous devez surveiller le journal de votre base de données pour détecter des erreurs telles que FATAL ou un blocage, ou même des erreurs courantes telles que des problèmes d'authentification ou des requêtes de longue durée. La plupart des erreurs sont écrites dans le fichier journal avec des informations utiles détaillées pour y remédier. Les points de défaillance courants que vous devez surveiller sont les erreurs et la taille des fichiers journaux. L'emplacement du journal des erreurs se trouve sous la variable log_error.

Outils externes

Enfin, vous pouvez trouver une liste d'outils utiles pour surveiller l'activité de votre base de données.

Percona Toolkit - est l'ensemble d'outils Linux de Percona pour analyser les activités de MySQL et du système d'exploitation. Vous pouvez le trouver ici. Il prend en charge les distributions Linux 64 bits les plus populaires telles que Debian, Ubuntu et Redhat.

mysqladmin - mysqladmin est un programme d'administration pour le démon MySQL. Il peut être utilisé pour vérifier la santé du serveur (ping), répertorier les processus, voir les valeurs des variables, mais également effectuer des tâches administratives telles que créer/supprimer des bases de données, vider (réinitialiser) les journaux, les statistiques et les tables, tuer les requêtes en cours d'exécution, arrêter le serveur et contrôler la réplication.

innotop - offre une vue étendue des instructions SHOW. Il est très puissant et peut réduire considérablement le temps d'investigation. Parmi le support MySQL vanille, vous pouvez voir la vue Galera et les détails de la réplication maître-esclave.

mtop - surveille un serveur MySQL en affichant les requêtes qui prennent le plus de temps à se terminer. Les fonctionnalités incluent le "zoom" sur un processus pour afficher la requête complète, "l'explication" des informations de l'optimiseur de requête pour une requête et les requêtes "tuées". En outre, des statistiques de performances du serveur, des informations de configuration et des conseils de réglage sont fournis.

Mytop - s'exécute dans un terminal et affiche des statistiques sur les threads, les requêtes, les requêtes lentes, la disponibilité, la charge, etc. sous forme de tableau, très similaire à Linux

Conclusion

Ce blog n'est pas destiné à être un guide exhaustif sur la façon d'améliorer la surveillance de la base de données, mais il donne, espérons-le, une image plus claire de ce qui peut devenir essentiel et de certains des paramètres de base qui peuvent être surveillés. N'hésitez pas à nous faire savoir si nous avons oublié des éléments importants dans les commentaires ci-dessous.