Analyser et interpréter correctement le journal des erreurs de MariaDB

Rôle et limites du journal des erreurs

Le Journal des erreurs de MariaDB Il s'agit du journal d'activité du processus serveur. Il consigne notamment les opérations de démarrage et d'arrêt, les événements critiques du serveur, ainsi que les indications pouvant suggérer des problèmes liés aux tables ou au moteur de stockage. Le journal est toujours actif, mais son canal de sortie peut être configuré de différentes manières.

On y trouve par exemple des échecs d'initialisation de plugins, des fichiers illisibles, des refus d'accès ou des messages relatifs aux connexions. Une ligne indiquant „ Access denied “ prouve toutefois dans un premier temps uniquement que la connexion n’a pas été acceptée avec les données transmises. Seul le contexte permet de déterminer si la responsabilité incombe au mot de passe, à l’association utilisateur-hôte, à la méthode d’authentification ou à l’application appelante.

Le journal des erreurs ne constitue d'ailleurs pas une archive exhaustive de toutes les erreurs SQL d'une application. C'est à cela que sert le fichier distinct Plugin SQL_ERROR_LOG; il peut enregistrer les erreurs SQL qui surviennent dans un fichier dédié et prend également en compte les erreurs traitées par un gestionnaire de conditions avant qu'elles n'atteignent le client. Ce plugin n’est pas installé par défaut. Ses entrées peuvent contenir des informations relatives aux utilisateurs, aux hôtes, aux bases de données et au langage SQL ; c’est pourquoi la protection des accès et la minimisation des données doivent être définies avant sa mise en œuvre.

Pour Dépannage MySQL C'est pourquoi l'ordre chronologique est plus important qu'une ligne de conclusion prise isolément. Commencez par identifier un extrait cohérent avant et après l’événement. Si un message d’erreur spécifique est suivi de plusieurs entrées consécutives puis d’un arrêt, la première anomalie pertinente est souvent plus proche de la cause que la dernière erreur visible. L’heure, le symptôme observé et les modifications simultanées apportées à l’application ou au système doivent également être pris en compte dans l’évaluation.

Identifier les emplacements de stockage de manière fiable

Un fichier manquant dont l'extension est .err Cela ne signifie pas que MariaDB n'a rien consigné. Le journal des erreurs peut être écrit dans un fichier, sur la sortie d'erreurs par défaut ou via Syslog dans le journal systemd ; sous Windows, l'Observateur d'événements s'y ajoute. La variante active dépend des options du serveur, de la configuration du paquet et du mécanisme de démarrage de l'installation concernée.

L'option log_error détermine la destination en cas de sortie sur fichier. Un nom de fichier relatif est interprété par rapport au répertoire de données, tandis qu'un chemin absolu reste indépendant de celui-ci. Si aucun nom n'est explicitement spécifié, la documentation décrit un fichier selon le modèle « nom d'hôte + » .err dans le répertoire de données. Il ne faut toutefois pas en déduire un chemin d'accès fixe : vérifie toujours la configuration effectivement en vigueur.

Les commandes suivantes lisent uniquement les options contenues dans les fichiers d'options. Elles constituent donc un bon point de départ pour log_error, mais ne reflètent pas nécessairement la configuration complète du processus en cours d'exécution. Des paramètres de démarrage supplémentaires, ainsi que des unit systemd ou des remplacements « drop-in », peuvent compléter ou modifier ces valeurs et doivent être vérifiés séparément.

Dans la documentation actuelle de MariaDB, le processus serveur s'appelle mariadbd; mysqld peut, selon l'installation, continuer à apparaître sous ce nom à des fins de compatibilité. Il ne faut donc pas assimiler ces deux noms sans tenir compte du contexte de la version et de l'installation. Ces commandes ne modifient ni le service ni les données.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

Selon la documentation, la deuxième commande est prévue à partir de MariaDB 10.11 ; la troisième concerne les installations utilisant l'ancienne désignation du programme. Si vous ne trouvez aucune indication pertinente dans les fichiers d'options, vérifiez le journal ou le syslog ainsi que les paramètres du service effectivement lancé, plutôt que de créer un chemin d'accès au journal supposé. Cela évite que le diagnostic et la configuration d'exécution ne divergent.

Bien lire le format des lignes et le contexte

Dans les journaux d'erreurs sous forme de fichiers des versions récentes de MariaDB à partir de la version 10.1.5, chaque ligne suit systématiquement le modèle suivant : horodatage, ID de thread, niveau et message. Le Horodatage classe l'événement ; l'ID du thread permet de le relier à d'autres entrées de la même connexion au serveur, et le niveau décrit la nature du message. Ce n'est qu'en combinaison avec ces champs que le message fournit une base fiable pour le diagnostic.

Dans MariaDB jusqu'à la version 10.1.4 incluse, le format de date est plus court et la représentation diffère du schéma plus récent. Un analyseur syntaxique ou une recherche qui s'attend à des positions de champs fixes dans le format actuel peut donc analyser de manière erronée les journaux plus anciens. De plus, dans les environnements Galera, des scripts SST externes peuvent écrire des lignes dans lesquelles l'ID de thread et le niveau sont manquants. Ces lignes particulières ne constituent pas automatiquement des données de journal endommagées.

L'extrait suivant n'est qu'un exemple schématique illustrant le déroulement d'une séquence de démarrage ayant échoué. Il ne repose sur aucun cas réel et ne remplace ni la sortie complète du démarrage, ni la vérification des options actives. Ce qui est déterminant, c'est que l'écart de configuration précède le message d'abandon final.

2026-09-23 08:14:02 0 [Note] Starting MariaDB
2026-09-23 08:14:02 0 [ERROR] unknown variable 'example_option=1'
2026-09-23 08:14:02 0 [ERROR] Aborting

Voici unknown variable Premier élément à examiner : l'option peut être mal orthographiée, indisponible dans cette version ou placée dans le mauvais fichier de configuration. Aborting décrit en revanche le point final de la séquence de démarrage. Recherche donc en remontant jusqu'au premier message pertinent, puis note les lignes suivantes. Tu peux ainsi distinguer la cause probable, la réaction du serveur et les effets visibles de la erreurs de base de données bien séparés les uns des autres.

Première prise en charge sans modifications risquées

Avant d'interpréter un message ou de modifier des paramètres, sauvegardez le Contexte opérationnel: la version complète de MariaDB, y compris les ajouts liés aux paquets ou à la distribution, le système d'exploitation, le mécanisme de démarrage, l'heure et le symptôme observable. Un redémarrage, une connexion infructueuse ou un arrêt de la réplication constituent des événements distincts. Sans ces informations, il n'est pas possible d'évaluer de manière fiable une même ligne de journal.

Ne copiez pas non plus un seul résultat, mais un extrait cohérent comprenant la partie avant et après le premier événement notable. Notez à quel moment le problème a commencé pour les utilisateurs ou les applications, et si des modifications de configuration, de déploiement ou de réseau ont eu lieu en parallèle. Cela permet de distinguer dans le temps les déclencheurs, les erreurs consécutives et la séquence normale de démarrage ou d'arrêt.

Les commandes suivantes se contentent de lire les informations contenues dans les fichiers d'options et ne modifient ni le service ni les données. Elles sont particulièrement utiles pour vérifier une option qui y est définie log_error . Cependant, ils n'affichent pas automatiquement toutes les valeurs avec lesquelles le service a effectivement été lancé : tu dois vérifier séparément les paramètres de démarrage supplémentaires, les fichiers d'unité systemd et les « drop-ins ».

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

À partir de la version 10.11, MariaDB documente my_print_defaults --mariadbd pour cette requête. Le nom mariadbd désigne le processus serveur actuel ; mysqld Dans de nombreuses installations, l'ancienne désignation ou la mention de compatibilité est conservée. Ne considérez donc pas ces deux noms comme désignant la même version de serveur ou le même nom de service.

Si le journal se trouve dans le journal systemd, délimite la plage horaire à l'aide du nom d'unité vérifié sur le système. Si nécessaire, vérifiez également le fichier de l'unité et les drop-ins existants afin de ne pas négliger d'éventuels paramètres de démarrage supplémentaires. Ajoutez ensuite à cet extrait le journal de l'application correspondant à la même période, si le symptôme se manifeste au niveau d'une application.

journalctl -u <geprüfte-mariadb-unit> --since "2026-09-23 08:00" --until "2026-09-23 09:00"

Classer les niveaux et les erreurs de démarrage

Les balises permettent de structurer le journal d'erreurs de MariaDB, mais ne remplacent pas une analyse des causes. Une Gravité décrit la classification d'une ligne, mais ne détermine pas automatiquement la gravité ou l'urgence. C'est justement en cas de problème au démarrage que l'ordre est déterminant : un message d'erreur concret apparaissant plus tôt explique souvent un message ultérieur Aborting, tandis que les remarques qui précèdent peuvent également concerner une initialisation normale.

Si MariaDB ne démarre pas, identifiez d'abord la dernière séquence de démarrage dans le journal, puis relisez-le à rebours. Recherchez en particulier unknown variable, fichiers manquants ou illisibles, problèmes d'autorisation et erreurs lors de l'initialisation des plugins. MariaDB recommande de consulter en priorité le journal d'erreurs en cas d'échec du démarrage ; en cas de démarrage manuel, la cause peut également s'afficher sur la console.

A Erreur de configuration Cela concerne généralement une option inconnue, une orthographe incorrecte ou une valeur inappropriée dans un fichier importé. Vérifie d'abord les options actives et la correspondance de version, plutôt que de modifier les données. En revanche, une erreur lors de l'ouverture d'un fichier de données ou un message InnoDB peut concerner les autorisations, les chemins d'accès, la mémoire ou l'état des données, et nécessite une analyse nettement plus prudente.

Ne modifiez pas plusieurs paramètres à la fois pour forcer le démarrage. Sauvegardez l'extrait du journal et notez quelle modification a précédé l'erreur. Ce n'est qu'une fois que le premier message pertinent a été associé à un paramètre ou à une ressource vérifiée qu'il est possible de planifier une correction ciblée et traçable.

Évaluation diagnostique des messages fréquents

Les formulations récurrentes permettent de raccourcir la recherche, mais fournissent rarement à elles seules un diagnostic. Associez chaque message à un intervalle de temps, à l'hôte ou au thread concerné et au symptôme observé. Le tableau ne mentionne délibérément que les prochaines étapes diagnostiques : il évite ainsi de conclure hâtivement à une cause liée au serveur de base de données à partir d’une simple référence à des connexions, des fichiers ou la réplication.

À l'adresse suivante : Accès refusé Il est tout d'abord essentiel de déterminer pour quel utilisateur et quel hôte client la connexion a été refusée. Vérifie la configuration de l'application utilisée et l'heure à laquelle cela s'est produit, et ne te limite pas uniquement au mot de passe. Ce message peut être dû à des identifiants erronés, à une référence d'hôte incorrecte ou à une authentification non valide ; il ne prouve pas que la base de données soit endommagée.

A Connexion interrompue Cela peut être dû à un délai d'expiration de l'application, à une connexion réseau interrompue, à un proxy ou à une communication de paquets défectueuse. Comparez l'hôte client et l'ID de thread avec le journal de l'application. Pour les compteurs, utilisez des valeurs globales plutôt que des valeurs liées à la session ; sinon, une session réinitialisée peut afficher des valeurs faussement basses.

SHOW GLOBAL STATUS LIKE 'Aborted%';

La requête affiche des compteurs, mais ne fournit pas de cause complète ni d'attribution à un client spécifique. Évaluez donc les changements sur une période appropriée, en les croisant avec des extraits de journaux. En cas d’indications relatives à la réplication ou au GTID, documentez également les lignes suivantes et vérifiez l’état de la réplication à l’aide des informations de statut prévues à cet effet ; la ligne du journal d’erreurs ne suffit pas à elle seule pour établir un diagnostic complet de la réplication.

Évaluer la récupération InnoDB sans risque pour les données

Après un arrêt imprévu, des messages tels que „ Recovering after a crash “, „ Starting crash recovery “ et un message indiquant que l'opération s'est terminée avec succès peuvent s'afficher. Ils décrivent dans un premier temps une récupération automatique après un plantage lors du démarrage du serveur. En ce qui concerne le journal binaire ou tc.log elles peuvent également contenir des informations relatives à la coordination des transactions. Ces lignes ne constituent pas à elles seules une preuve de tables endommagées ou de perte de données.

L'évaluation change si, lors de la restauration, un [ERREUR] si le démarrage s'interrompt ou si des messages signalent des fichiers illisibles ou endommagés. Lisez alors l'intégralité de la séquence de démarrage dans l'ordre chronologique et notez la version, l'heure de la panne ainsi que l'extrait complet. Une référence au fichier « Binary Log » ou « tc.log » ne constitue pas en soi une demande de réparation s'il n'y a pas d'erreurs consécutives.

En cas de problème présumé lié aux données, il ne faut pas procéder à des suppressions de fichiers ni à d'autres interventions visant uniquement à forcer le démarrage. Déterminez d'abord l'objectif de l'intervention : circonscrire l'erreur, extraire de manière contrôlée les données accessibles ou restaurer une instance de production. Pour ce faire, consignez séparément l'extrait du journal, les sauvegardes existantes et l'état de l'instance concernée.

Si une lecture contrôlée est possible, le transfert vers une instance cible « propre » doit être prévu, au lieu de considérer l'environnement concerné comme rétabli. Pour mieux comprendre les mécanismes transactionnels en jeu, l'article consacré à Les journaux d'annulation MariaDB pour les administrateurs. En cas de plantages répétés ou d'erreurs de fichiers difficiles à cerner, il est préférable de faire appel à un service de récupération spécialisé plutôt que de multiplier les tentatives de démarrage.

Distinguer les erreurs de réplication des erreurs SQL

Dans le journal des erreurs, des threads, des positions, des GTID ou des journaux de relais peuvent apparaître lors des opérations de réplication. Ces informations fournissent dans un premier temps un contexte pour la période concernée, mais ne constituent pas encore un diagnostic complet de l'erreur. Sauvegardez les lignes situées avant et après l'entrée et vérifiez séparément l'état de la réplication. Il n'est pas possible de déterminer de manière fiable, à partir d'une ligne de journal isolée, si un thread s'est terminé normalement ou s'il y a eu une interruption.

Actualités concernant opérations préparées En revanche, après un plantage, il convient de faire preuve d'une prudence particulière. Une récupération heuristique prend, selon l'option choisie, une décision de validation (commit) ou d'annulation (rollback), en ignorant les informations issues de la coordination des transactions. Il ne s'agit pas d'une étape du dépannage général de MySQL, mais d'un cas particulier dont les conséquences sur les répliques et les données métier doivent être évaluées au préalable.

Le journal des erreurs (Error Log) enregistre les événements du serveur, mais ne constitue pas un journal exhaustif de toutes les instructions SQL ayant généré des erreurs. Les journaux binaires (Binary Logs) servent principalement à enregistrer les modifications et à assurer la réplication ; leur rôle est expliqué dans l'article consacré à Les journaux binaires MariaDB et leur logique de performance. Le journal des requêtes lentes (Slow Query Log) est utile en cas de requêtes lentes, le journal général des requêtes (General Query Log) permet une surveillance complète des connexions et des requêtes, tandis que le journal d'audit (Audit Log) sert à d'autres fins de contrôle.

Pour les erreurs SQL qui surviennent, il existe le fichier séparé Plugin SQL_ERROR_LOG. Il peut également enregistrer les erreurs traitées par un gestionnaire de conditions et qui, de ce fait, ne sont techniquement pas transmises au client. Le plugin n'est pas installé automatiquement ; à partir de MariaDB 10.11.5, les avertissements peuvent également être enregistrés si le paramétrage approprié est activé. Ses entrées peuvent contenir des données relatives aux utilisateurs et aux hôtes, des noms de bases de données ainsi que du code SQL. Prévoyez donc des droits d’accès restrictifs, une politique de conservation et une rotation des fichiers avant d’activer la journalisation supplémentaire dans un environnement de production.

Exploitation, escalade et prochaines étapes

En cas de comportement suspect, erreurs de base de données Commencez par extraire un extrait de journal cohérent comportant des horodatages, et pas seulement la dernière ligne. Notez également la version de MariaDB ainsi que l’identifiant du paquet, le mécanisme de démarrage, le symptôme observé et la corrélation temporelle avec les déploiements, les redémarrages ou les événements liés à l’infrastructure. Ces données permettent de distinguer une cause potentielle de ses conséquences et de comparer conjointement les indications provenant de l’application, du système d’exploitation et de la base de données.

Comparez ensuite les options effectivement lues avec la configuration souhaitée, plutôt que de modifier les valeurs par défaut supposées. Ceci est particulièrement important, car le paquetage, la version de MariaDB et les noms de compatibilité peuvent influencer les options de différentes manières. En cas d’erreur de configuration, celle-ci peut être gérée différemment d’un éventuel dommage au niveau de la mémoire ou d’InnoDB.

Avant tout redémarrage, toute tentative de récupération ou toute modification de configuration, il est recommandé, par mesure de sécurité, de vérifier les sauvegardes disponibles et leur état de fonctionnement. Documentez également la modification prévue et un plan de secours. Cela ne remplace pas une analyse des causes, mais réduit le risque qu’une mesure de diagnostic masque l’état initial ou complique la restauration.

Un seul refus d'accès ou une seule connexion interrompue peut dans un premier temps être pris en compte s'il ne se reproduit pas et si l'application ainsi que le service restent stables. Si de tels événements se multiplient, examinez l'hôte client, l'application, le proxy et le réseau. En revanche, des échecs répétés au démarrage, des fichiers de données illisibles, des échecs de récupération après panne ou des indications de transactions en attente constituent des cas nécessitant une escalade rapide, accompagnée des données d'origine sauvegardées.

Même un journal de bord qui fonctionne correctement nécessite des règles d'exploitation. Surveillez Rotation du logo et la consommation de mémoire, car une verbosité plus élevée ou des journaux d'erreurs SQL supplémentaires peuvent rapidement augmenter la taille des fichiers. Limitez l'accès aux journaux, car ils contiennent des détails techniques et, le cas échéant, le contenu confidentiel des requêtes. Les modifications permanentes ne sont justifiables qu’après avoir établi une cause documentée, élaboré un plan de secours et évalué leur impact sur la protection des données et la capacité.