Le journal d’erreurs de MySQL

16 avril 2010 par stephane

Les informations recueillies dans le journal d’erreurs sont très intéressantes à examiner, non seulement en cas de crash, mais aussi de façon périodique pour détecter d’éventuels problèmes. Ce billet va vous rappeler le rôle de ce journal, vous indiquer quelles sont les options de configuration et vous donner quelques bonnes pratiques pour éviter les pièges les plus fréquents.

Commençons par le plus simple : que contient ce journal ? Facile : toutes les erreurs rencontrées par le serveur. Mais vous y trouverez également d’autres informations, comme par exemple les arrêts et démarrages du serveur. Par défaut, l’option log_warnings est activée (valeur à 1), ce qui signifie que les messages d’avertissement sont également présents. Si vous ne souhaitez pas avoir les message d’avertissement, il vous suffit de positionner cette variable à 0. A l’inverse, si vous voulez avoir des informations supplémentaires, telles que les problèmes réseaux, vous pouvez positionner cette variable à 2.
Pour les utilisateurs de Windows, sachez que certaines données sont reprises dans le journal des événements.

Voilà pour la partie facile. Les choses se compliquent déjà un peu plus quand on cherche à savoir où se trouve le fichier d’erreur… A priori pourtant, ce n’est pas difficile, il suffit de regarder du côté de la variable log_error. Celle-ci peut prendre 3 valeurs :

  • chaîne vide (par défaut), le journal d’erreurs s’appelle alors [hostname].err et se trouve dans le répertoire de données
  • un nom d’un fichier, dans ce cas, le journal se trouve dans le répertoire de données et porte le nom indiqué
  • le chemin absolu d’un fichier, alors le journal se trouve à l’emplacement indiqué

Cela signifie que dans les deux premiers cas, il faut également regarder la variable datadir pour connaître l’emplacement du répertoire de données.

Deux petites remarques au passage :

  • il n’est pas possible de désactiver le journal d’erreurs
  • le journal est toujours écrit dans un fichier et jamais dans une table comme vous pouvez le faire pour la general log et la slow log à partir de la version 5.1

En réalité, c’est encore un peu plus compliqué. Dans certaines distributions Linux, comme Debian ou Ubuntu par exemple, le journal passe par syslog. Les événements ont alors un tag mysqld_safe ou mysqld selon leur origine. La raison en est une petite variable bien cachée dans un fichier … lui aussi bien caché : si vous regardez dans le répertoire /etc/mysql/conf.d/, vous y trouverez un fichier mysld_safe_syslog.cnf qui contient simplement la directive suivante :
[mysqld_safe]
syslog

A partir de la version 5.1, la variable syslog est disponible en standard (mais pas pour Windows bien sûr !).

Est-ce un bon choix d’utiliser cette variable syslog ? La réponse va sans doute dépendre de votre manière de surveiller les logs : si vous ne vous intéressez qu’à MySQL, devoir retrouver les événements liés à MySQL parmi tous les autres événements va être laborieux, mais au contraire, si MySQL n’est qu’une application parmi tant d’autres, il vous sera bien agréable d’avoir un journal d’erreurs dans un format standard.

Subtilité ou complication supplémentaire, vous pouvez même avoir votre journal d’erreur en double, une première fois via syslog et une deuxième fois dans le fichier d’erreur classique. Comment faire ? Il vous faut activer en même temps la variable syslog et la variable log_error :
[mysqld_safe]
syslog


[mysqld]
log_error = error.log

Quel est l’intérêt ? A vrai dire, je n’en vois pas vraiment … :)

Voyons maintenant quelques bonnes pratiques.

La première question à vous poser, en supposant que vous êtes sous Linux et que votre version ou votre distribution vous en donne la possibilité, est de savoir si vous souhaitez utiliser syslog ou pas.

Si oui, il vous suffit de positionner la variable syslog dans la section [mysqld_safe] du fichier my.cnf et la configuration est terminée.

Sinon, si vous laissez la variable à vide ou si vous mettez un nom de fichier, votre journal d’erreurs va se trouver dans le répertoire de données, ce qui n’est pas souhaitable. Même s’il existe peu de chances que le journal d’erreurs remplisse tout l’espace disque disponible dans le répertoire de données (c’est plus plausible avec les logs bins), il est en effet toujours mieux de ne pas mélanger les torchons et les serviettes : les données avec les données et les logs avec les logs ! De plus, vous risquez d’avoir des problèmes de droit : dans le répertoire de données, seul les utilisateurs du groupe mysql ont le droit d’accéder à ce fichier, alors que vous aurez peut-être besoin de donner des accès à d’autres utilisateurs sans pour autant leur laisser un accès aux données. Il est donc conseillé de saisir un chemin absolu vers un fichier, par exemple :
[mysqld]
log_error = /var/log/mysql/error.log

Un autre aspect à prendre en compte est celui de la rotation. En effet, si vous n’y faites pas attention, la rotation des logs risque de vous faire perdre une grande partie des informations du journal d’erreurs !
Le premier point à constater est que la rotation du journal d’erreurs ne se fait pas automatiquement au démarrage du serveur ou lorsque la taille du fichier dépasse une certaine limite. La seule possibilité consiste à exécuter la commande FLUSH LOGS (qui affecte également les autres logs).

Quand vous utilisez syslog, par défaut, votre système fait une rotation tous les jours, et les logs sont purgées après 7 jours. Sauf si vous prenez des mesures pour sauvegarder les logs après leur rotation, vous avez donc seulement le journal des erreurs des 7 derniers jours à votre disposition.

Mais quand vous utilisez un journal d’erreurs classique, la situation est beaucoup plus dangereuse ! En effet, l’appel de la commande FLUSH LOGS créé un nouveau journal d’erreurs et sauvegarde l’ancien dans un fichier avec le suffixe -old. Et si vous aviez déjà un fichier -old, celui-ci est purement et simplement supprimé !

Petite démo :
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log
-rw-rw---- 1 ... 939 2010-04-16 10:45 error.log-old

J’ai bien un journal d’erreurs ainsi qu’un journal en -old. J’exécute FLUSH LOGS pour voir l’effet :

stephane@cilaos:/var/lib/mysql$ mysql -uroot -p -e "FLUSH LOGS"
Enter password:
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 0 2010-04-16 10:47 error.log
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log-old

Et voilà, mes anciennes erreurs sont perdues à tout jamais…

Conclusion : mieux vaut sauvegarder régulièrement son journal d’erreurs car nul n’est à l’abri d’un FLUSH LOGS non prévu.

Notre exploration du journal d’erreurs est terminée, et nous reviendrons bientôt sur un autre journal extrêmement important : le journal des requêtes lentes.

Mots-clefs : ,

2 commentaires sur “Le journal d’erreurs de MySQL”

  1. au-pair dit :

    Y a-t-il des informations sur ce sujet dans d’autres langues ?

  2. stephane dit :

    Il y a toujours la doc officielle qui est intéressante à lire

Laisser une réponse