Les journaux de base de données constituent une base puissante pour aider les administrateurs de bases de données à suivre et à analyser divers événements survenus dans la base de données. MySQL fournit des journaux d'erreurs et des journaux binlog (binaire. log), journal d'enquête, journal de requêtes lentes. Ici, je cherche à répondre aux questions suivantes : quel est le but de chaque journal ? Comment contrôler ces logs ? Comment utiliser les informations fournies par ces logs ?
Erreur Le journal enregistre des informations sur le démarrage et l'arrêt de MySQL, ainsi que sur toutes les erreurs graves qui se produisent pendant l'exécution du serveur. Lorsque la base de données ne démarre pas en raison d'une panne, par exemple, mysql démarre anormalement, nous pouvons vérifier d'abord ce journal. Dans MySQL, le journal des erreurs (et d'autres journaux) peut non seulement être stocké dans des fichiers, mais bien sûr peut également être stocké dans des tables de données. Quant à la méthode d'implémentation, l'auteur étudie également. .·
Passé log-error=[file-name] pour configurer (dans le fichier de configuration mysql), si file_name n'est pas spécifié, mysqld utilise le nom du journal des erreurs host_name.err (host_name est le nom d'hôte), et la valeur par défaut est Le fichier journal est écrit dans le répertoire spécifié par le paramètre datadir (le répertoire dans lequel les données sont enregistrées).
Par exemple, j'utilise l'environnement intégré WampServer localement
où l'erreur de journalisation = D:/wamp/logs/mysql.log
Comme indiqué ci-dessous
Si je commente log-error (#log-error=D:/wamp/logs/mysql.log ), redémarrez le serveur, vous pouvez afficher le fichier journal des erreurs dans le répertoire spécifié par datadir
Le format du journal des erreurs : heure [niveau d'erreur] message d'erreur
Si vous trouvez difficile de localiser le journal des erreurs via le fichier de configuration MySQL, vous pouvez afficher l'emplacement du journal des erreurs via des commandes sur le client
Utilisez des expressions impératives : affichez des variables telles que 'log_error' ;
Ce qui suit est le journal de démarrage de MySQL
Le journal binaire (également appelé journal binlog) enregistre toutes les instructions DDL (langage de définition de données) et DML (langage de manipulation de données), mais n'inclut pas les instructions de requête de données. Les instructions sont enregistrées sous la forme d'"événements". , qui décrit le processus de modification des données. Les deux fonctions principales de ce journal sont : la récupération des données et la réplication des données.
Récupération de données : MySQL lui-même dispose de fonctions de sauvegarde et de récupération de données. Par exemple, nous sauvegardons les données tous les jours à minuit. Si un jour, à 13h00, la base de données tombe en panne, entraînant la perte du contenu de la base de données. Nous pouvons résoudre ce problème grâce aux journaux binaires. La solution consiste à restaurer d'abord le fichier de sauvegarde des données à minuit la veille dans la base de données, puis à utiliser le journal binaire pour restaurer le de la base de données de minuit la veille à 13h00 aujourd'hui.
Réplication des données : MySQL prend en charge la fonction de réplication des données entre les serveurs maître et esclave, et utilise cette fonction pour implémenter le mécanisme de redondance de la base de données afin d'assurer la disponibilité de la base de données et améliorer les performances de la base de données Virtue. MySQL implémente le transfert de données via des journaux binaires. Le contenu du journal binaire sur le serveur maître sera envoyé à chaque serveur esclave et exécuté sur chaque serveur esclave, garantissant ainsi la cohérence des données entre les serveurs maître et esclave.
Par défaut, MySQL n'enregistre pas les journaux binaires. Comment puis-je activer la fonction de journalisation binaire de MySQL ?
Nous pouvons contrôler MySQL pour démarrer la fonction de journalisation binaire via le fichier de configuration MySQL. Démarrez le journal binaire MySQL en modifiant le paramètre log-bin=[base_name]. mySQL enregistrera les instructions de contenu de la base de données modifiées dans un fichier journal nommé base_name-bin.0000x, où bin représente le binaire et le suffixe 00000x représente l'ordre du fichier journal binaire, à chaque démarrage. Mysql, l'ordre des fichiers journaux augmentera automatiquement de 1. Si base_name n'est pas défini, MySQL utilisera la valeur définie par le paramètre pid-file comme nom de base du fichier journal binaire.
Par exemple, si je nomme le fichier log-bin comme mybinlog, il sera dans D:/wamp/bin/mysql /mysql5 Dans le répertoire .6.17/data, générez le fichier journal binaire mybinlog.00000x.
Le fichier journal binaire est tel qu'indiqué ci-dessous
Vérifiez si le journal bin-log est activé en utilisant des variables d'affichage telles que 'log_bin'.
Le journal binaire MySQL est principalement destiné à un usage interne de MySQL, et non à la lecture et à l'utilisation des administrateurs de base de données. Par conséquent, une différence importante entre le journal binaire et les autres journaux est ce journal binaire. Le format du fichier n'est pas au format texte et son contenu ne peut pas être visualisé directement via le Bloc-notes. Afin de faciliter la gestion de l'administrateur, MySQL fournit l'outil mysqlbinlog pour afficher le contenu du journal binaire.
Par exemple : mysqlbinlog D:wampbinmysqlmysql5.6.17datamybinlog.000003
L'exécution le résultat est le suivant :
Faisons maintenant un test pour voir si le log bin enregistre mon opération de mise à jour de la base de données
Par exemple, je change l'id1 de la ligne avec id2=2 dans le tableau de données t2 en 5. Ensuite, j'interroge le fichier journal binaire pour voir si mes opérations sont enregistrées.
Les résultats sont évidents. Le fichier binaire enregistre mon opération de modification de la base de données, et enregistre également que j'ai modifié les données dans la base de données. Quant à mon instruction de requête, elle n'est pas enregistrée.
Pour un système relativement chargé, en raison du grand nombre de logs générés chaque jour, si de nos jours sont longs. Si l'heure n'est pas claire (ou transférée), cela entraînera un gaspillage important d'espace disque. Par conséquent, la suppression régulière des journaux est une partie importante de la maintenance de la base de données MYSQL par l'administrateur de base de données.
, qui supprimera tous les journaux binlog. Les nouveaux numéros de fichiers journaux commencent à 000001.
'Tous les journaux avant le numéro. Ci-dessous, je supprimerai tous les journaux avant mybinlog.000003.
Comme indiqué ci-dessous :
pour exécuter purge master logs avant 'time' signifie supprimer tous les journaux avant ' temps' . Par exemple, pour supprimer tous les journaux avant le 01/04/2016 00:00:00, la commande est la suivante :
purger les journaux principaux avant '2016 -04-01 00:00:00';
Spécifiez le nombre de jours d'expiration du journal en définissant le paramètre expire_logs_days=# Après le nombre de jours spécifié, le journal sera automatiquement supprimé. méthode. Par exemple, définir expire_logs_day=3 signifie qu'il sera automatiquement supprimé après 3 jours.
max_binlog_size : Spécifie la valeur maximale d'un seul fichier journal binaire. S'il dépasse Cette valeur générera un nouveau fichier journal binaire avec un suffixe de 1 et l'enregistrera dans le fichier .index.
binlog_cache_size : taille de la zone de cache
sync_binlog : Indique que le cache sera synchronisé sur le disque sans écrire plusieurs fois sur le cache. Si N est défini sur 1, cela signifie que le fichier binaire sera écrit sur le disque de manière synchrone. Le paramètre système par défaut dans MySQL est sync_binlog=0, ce qui signifie qu'aucune instruction d'actualisation obligatoire du disque n'est effectuée. Les performances à l'heure actuelle sont les meilleures, mais le risque est également le plus grand. Parce qu'une fois le système crashé, toutes les informations binlog dans binlog_cache seront perdues. Lorsqu'il est réglé sur "1", il s'agit du paramètre le plus sûr mais celui-ci entraîne la plus grande perte de performances. Parce que lorsqu'il est défini sur 1, même si le système tombe en panne, au plus une transaction inachevée dans binlog_cache sera perdue, sans aucun impact substantiel sur les données réelles.
binlog-do-db : Quels jours de base de données doivent être enregistrés, la valeur par défaut est vide, indiquant que tous les journaux de la bibliothèque sont synchronisés avec le journal binaire.
binlog-ignore-db : jours pendant lesquels les bases de données doivent être ignorées
log-slave-update : doit être configuré lorsque construire la base de données maître-esclave
binglog_format : les valeurs facultatives incluent l'instruction (enregistrement des instructions SQL logiques), la ligne (enregistrement des modifications de ligne du tableau), mixte
Comme indiqué précédemment, si les données sont anormales et que vous souhaitez les restaurer aux données à un moment donné, les données binaires seules ne suffisent souvent pas. . Ce qui est également nécessaire, ce sont les données sauvegardées avant ce moment.
Afin de faciliter l'observation de l'effet, j'ai maintenant sauvegardé ma base de données. À ce moment, les données du tableau de données t1 sont les suivantes :
Désormais, je dois effectuer certaines opérations sur les données, comme des opérations de mise à jour ou d'insertion. Après l'opération, le. Les données t1 sont présentées ci-dessous
À l'heure actuelle, si quelque chose de très malheureux se produit et un pirate informatique s'introduit par effraction. Toutes les données de ma table t1 ont été supprimées, alors comment puis-je obtenir les données avant que le pirate informatique ne les supprime ?
Étape 1 : Je dois restaurer mes données données que j'ai sauvegardées, le résultat après restauration est le suivant :
Étape 2 : Je dois utiliser mon fichier journal binaire pour restaurer toutes les opérations de données depuis le moment de la sauvegarde des données jusqu'au moment avant le piratage
Exécuter : mysqlbinlog D:wampbinmysqlmysql5.6.17data
mybinlog.000004
En analysant le journal binaire, nous avons découvert qu'à la ligne 'à 637', nos données ont été attaquées par des pirates informatiques, nous n'avons donc besoin que de restaurer Toutes les opérations antérieures à la ligne 637 peuvent être ignorées.
Nous pouvons donc exécuter la commande suivante pour récupérer nos données :
mysqlbinlog D:wampbinmysqlmysql5.6.17datamybinlog.000004 --stop-pos=637|mysql -uroot -p**dequan
Vérifions ensuite les données de notre table t1
Enfin, c'est fait, mais cela nous rappelle aussi que pour faciliter la récupération des données, nous devons non seulement activer le journal binaire, mais aussi sauvegarder les données régulièrement.
1. commande show binaire logs Quels autres journaux binaires existe-t-il ?
2. Nous pouvons enregistrer les événements enregistrés par show binlog events
show binlog events affiche tous les événements enregistrés. Si vous souhaitez interroger un certain événement d'enregistrement de journal binaire, vous pouvez ajouter le « nom du journal » à la fin, comme indiqué ci-dessous :
1 . Description de la fonction
Le journal des requêtes enregistre toutes les déclarations du client. Vous pouvez spécifier son emplacement via log=[file_name]. Comme les autres journaux, si la valeur file_name n'est pas spécifiée, le journal sera écrit dans le répertoire où se trouve datadir. Le nom de fichier par défaut est host_name.log. un impact plus important sur les performances du système. En général, il ne sera pas activé, je n'entrerai donc pas dans les détails ici.
Le journal des requêtes lentes est Enregistrez tous les journaux d'instructions SQL dont le temps d'exécution dépasse le paramètre long_query_time (unité : secondes). Le temps passé à attendre l'obtention du verrou de table n'est pas compté comme temps d'exécution. Nous pouvons activer la fonction de journal des requêtes lentes via l'option log-slow-queries=[file_name] . Comme pour le journal précédent, si file_name n'est pas spécifié, le répertoire du journal se trouve dans le répertoire datedir et le nom par défaut est host_name-slow.log.
Interroger l'état d'ouverture de la requête lente
Ajoutez le code suivant dans le fichier de configuration , Activer la requête lente
#Activer la requête lente
slow_query_log=ON
slow_query_log_file=D:/wamp/logs/myslowquery.log
long_query_time=1.5
(Certains endroits disent que le journal des requêtes lentes est spécifié via log-slow-queries=[file_name], mais je l'ai essayé, et une erreur sera signalée lors du démarrage de MySQL dans ce Il se peut que je sois en mode Win Operate sous le système, ou peut-être que mon MySQL local est installé à l'aide de l'environnement intégré WampServer, ou peut-être que la version utilisée est différente)
Vérifiez le paramètre de temps de requête lent
Si vous modifiez le temps de requête lent, vous pouvez utiliser set long_query_time=1.5;
Afin de faciliter la visualisation de l'effet, nous allons modifier la limite de temps de requête lente à 0,15, puis nous écrirons un SQL avec un temps supérieur à 0,15 et enfin vérifier le journal pour voir si l'instruction SQL est enregistrée.
Définissez le temps de requête lent et exécutez l'instruction SQL correspondante
J'ai exécuté un total de 3 instructions SQL ci-dessus. Jetons maintenant un coup d'œil. Le journal des requêtes lentes est le suivant
Il enregistre uniquement l'instruction SQL dont l'interrogation prend beaucoup de temps.
Ce qui précède est l'introduction du journal des erreurs, du journal binlog, du journal des requêtes et du journal des requêtes lentes dans Mysql . Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !