Introduction
Dans ce laboratoire, vous découvrirez les principes fondamentaux de la gestion des erreurs et de la journalisation dans MySQL. Une gestion efficace des erreurs est essentielle pour créer des applications de base de données robustes et faciles à maintenir : elle vous aide à diagnostiquer les problèmes, à comprendre l’exécution des requêtes et à garantir l’intégrité des données.
Vous commencerez par activer le journal général des requêtes, qui enregistre toutes les instructions SQL envoyées au serveur. C’est un outil précieux pour le débogage et l’audit. Vous apprendrez ensuite à gérer les erreurs dans une procédure stockée à l’aide de DECLARE HANDLER, afin de traiter correctement les erreurs inattendues. Vous découvrirez également comment créer et déclencher des conditions d’erreur personnalisées avec l’instruction SIGNAL pour faire respecter des règles métier. Enfin, vous consulterez le journal des erreurs MySQL, qui contient des informations importantes sur les opérations du serveur et les problèmes critiques.
À la fin de ce laboratoire, vous maîtriserez les bases de la gestion des erreurs et de la journalisation dans MySQL. Vous pourrez ainsi créer des solutions de base de données plus fiables.
Activer et consulter le journal général des requêtes
Le journal général enregistre chaque instruction SQL reçue des clients. C’est un outil précieux pour le débogage et l’audit, mais il est préférable de ne l’utiliser que temporairement, car il peut réduire les performances et occuper beaucoup d’espace disque. Dans cette étape, vous allez activer le journal, générer quelques activités, puis consulter le fichier journal.
Commencez par ouvrir le terminal depuis le bureau.
Connectez-vous au serveur MySQL en tant qu’utilisateur root. Dans cet environnement de laboratoire, vous pouvez utiliser sudo pour vous connecter sans mot de passe.
sudo mysql -u root
Lorsque l’invite mysql> s’affiche, activez le journal général à l’échelle globale.
SET GLOBAL general_log = 'ON';
Par défaut, le fichier journal se trouve dans le répertoire de données de MySQL. Pour y accéder plus facilement, déplacez-le dans le répertoire /tmp.
SET GLOBAL general_log_file = '/tmp/mysql_general.log';
Vérifiez le nouvel emplacement en exécutant la commande suivante :
SHOW VARIABLES LIKE 'general_log_file';
Le résultat doit confirmer le chemin que vous venez de définir.
+------------------+-------------------------+
| Variable_name | Value |
+------------------+-------------------------+
| general_log_file | /tmp/mysql_general.log |
+------------------+-------------------------+
1 row in set (0.01 sec)
Exécutez maintenant quelques commandes pour générer des entrées dans le journal.
CREATE DATABASE IF NOT EXISTS testdb;
USE testdb;
SELECT 'Logging this query' AS message;
Après avoir exécuté ces commandes, quittez le shell MySQL.
exit
De retour dans le terminal, affichez le contenu du fichier journal.
sudo cat /tmp/mysql_general.log
Vous verrez les commandes exécutées, ainsi que des informations de connexion et des horodatages. Cela confirme que le journal général fonctionne correctement.
/usr/sbin/mariadbd, Version: 10.6.18-MariaDB-0ubuntu0.22.04.1 (Ubuntu 22.04). started with:
Tcp port: 3306 Unix socket: /run/mysqld/mysqld.sock
Time Id Command Argument
250728 14:12:46 33 Query SHOW VARIABLES LIKE 'general_log_file'
250728 14:12:50 33 Query CREATE DATABASE IF NOT EXISTS testdb
33 Query SELECT DATABASE()
33 Init DB testdb
33 Query show databases
33 Query show tables
33 Query SELECT 'Logging this query' AS message
250728 14:12:56 33 Quit
Enfin, pensez à désactiver le journal lorsque vous avez terminé. Vous pouvez le faire directement depuis le terminal.
sudo mysql -u root -e "SET GLOBAL general_log = 'OFF';"
Vous éviterez ainsi que le journal continue de grossir et nuise aux performances du serveur.
Gérer les erreurs dans une procédure stockée
Une procédure stockée peut échouer pour de nombreuses raisons, par exemple si elle tente d’insérer une valeur en double dans une colonne de clé primaire. Un gestionnaire d’erreurs permet d’intercepter ces erreurs et de les traiter correctement, au lieu de laisser la procédure échouer brutalement. Dans cette étape, vous allez créer une procédure stockée qui gère les erreurs de clé en double.
Commencez par vous connecter au serveur MySQL.
sudo mysql -u root
Créez la base de données testdb si elle n’existe pas encore, puis sélectionnez-la. Créez ensuite une table products.
CREATE DATABASE IF NOT EXISTS testdb;
USE testdb;
CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(255),
quantity INT
);
Créez maintenant une procédure stockée qui insère un nouveau produit. Cette version comprend un gestionnaire DECLARE HANDLER qui intercepte les erreurs de clé en double (SQLSTATE 23000) et renvoie un message personnalisé.
La commande DELIMITER remplace le terminateur d’instruction ; par //. Le point-virgule dans le corps de la procédure peut ainsi être traité correctement.
DELIMITER //
CREATE PROCEDURE insert_product(IN p_id INT, IN p_name VARCHAR(255))
BEGIN
-- Declare an EXIT handler for duplicate key errors
DECLARE EXIT HANDLER FOR SQLSTATE '23000'
BEGIN
SELECT 'Error: Product with this ID already exists.' AS message;
END;
-- Attempt to insert the product
INSERT INTO products (id, name, quantity) VALUES (p_id, p_name, 0);
SELECT 'Product inserted successfully.' AS message;
END //
DELIMITER ;
Testez la procédure. Commencez par insérer un nouveau produit.
CALL insert_product(1, 'Laptop');
L’opération doit réussir et renvoyer un message de confirmation.
+--------------------------------+
| message |
+--------------------------------+
| Product inserted successfully. |
+--------------------------------+
1 row in set (0.00 sec)
Essayez maintenant d’insérer un produit avec le même id.
CALL insert_product(1, 'Desktop');
Cette fois, le gestionnaire d’erreurs est déclenché et renvoie le message personnalisé au lieu d’une erreur MySQL générique.
+-----------------------------------------------+
| message |
+-----------------------------------------------+
| Error: Product with this ID already exists. |
+-----------------------------------------------+
1 row in set (0.00 sec)
Cet exemple montre comment les gestionnaires d’erreurs peuvent rendre vos procédures stockées plus faciles à utiliser et plus robustes.
Déclencher des erreurs personnalisées avec SIGNAL
Les gestionnaires interceptent les erreurs, tandis que l’instruction SIGNAL permet de les déclencher. Elle est utile pour faire respecter des règles métier qui ne sont pas couvertes par les contraintes standard de la base de données. Dans cette étape, vous allez créer une procédure qui utilise SIGNAL pour empêcher la saisie d’une quantité négative pour un produit.
Vous devriez toujours être dans le shell MySQL. Si vous l’avez quitté, reconnectez-vous.
sudo mysql -u root
Vérifiez que la base de données sélectionnée est testdb.
USE testdb;
Créez maintenant une procédure stockée qui met à jour la quantité d’un produit. Elle vérifiera si la nouvelle quantité est négative. Si c’est le cas, elle déclenchera une erreur personnalisée avec SIGNAL.
DELIMITER //
CREATE PROCEDURE update_quantity(IN p_id INT, IN p_quantity INT)
BEGIN
-- Check if the quantity is negative
IF p_quantity < 0 THEN
-- Raise a custom error
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Error: Quantity cannot be negative.';
END IF;
-- Update the quantity if the check passes
UPDATE products SET quantity = p_quantity WHERE id = p_id;
SELECT 'Quantity updated successfully.' AS message;
END //
DELIMITER ;
Ici, SQLSTATE '45000' est un code d’état générique pour les erreurs définies par l’utilisateur. MESSAGE_TEXT définit le message d’erreur que le client verra.
Testez la procédure. Commencez par mettre à jour la quantité du produit « Laptop » créé à l’étape précédente avec une valeur valide.
CALL update_quantity(1, 50);
L’opération doit s’exécuter correctement.
+--------------------------------+
| message |
+--------------------------------+
| Quantity updated successfully. |
+--------------------------------+
1 row in set (0.00 sec)
Essayez maintenant de mettre à jour la quantité en indiquant un nombre négatif.
CALL update_quantity(1, -10);
Cet appel déclenchera l’instruction SIGNAL et la procédure s’arrêtera en renvoyant l’erreur personnalisée.
ERROR 1644 (45000): Error: Quantity cannot be negative.
Vous avez ainsi vérifié que SIGNAL permet d’appliquer une logique métier personnalisée dans votre base de données.
Consulter le journal des erreurs MySQL
Le journal des erreurs MySQL est la principale ressource pour diagnostiquer les problèmes liés au serveur. Il enregistre les démarrages et arrêts du serveur, les erreurs critiques et les avertissements. Dans cette étape, vous allez vérifier la configuration du journal des erreurs et comparer la journalisation dans des environnements conteneurisés et traditionnels.
Vous devriez toujours être dans le shell MySQL. Commencez par rechercher l’emplacement du fichier du journal des erreurs en interrogeant la variable log_error.
SHOW VARIABLES LIKE 'log_error';
Dans cet environnement de machine virtuelle LabEx (conteneur Docker), la valeur indiquant le chemin du journal des erreurs peut être vide :
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error | |
+---------------+-------+
1 row in set (0.001 sec)
Remarque : dans les environnements conteneurisés comme cette machine virtuelle LabEx, la journalisation des erreurs de MySQL/MariaDB est souvent configurée pour écrire dans le flux d’erreur standard du conteneur plutôt que dans un fichier journal traditionnel. C’est une pratique courante dans les conteneurs Docker, conforme à la méthodologie des « applications 12 facteurs » (« 12-factor app »).
Pour illustrer la gestion des erreurs, essayez d’accéder à une base de données inexistante :
USE non_existent_database;
Comme prévu, cette commande échoue côté client.
ERROR 1049 (42000): Unknown database 'non_existent_database'
Quittez maintenant le shell MySQL pour revenir au terminal.
exit
Dans un environnement de production équipé d’une installation MySQL traditionnelle, le journal des erreurs se trouve généralement dans /var/log/mysql/error.log sur les systèmes Ubuntu. Vérifiez si le fichier journal traditionnel existe :
sudo ls -la /var/log/mysql/ 2> /dev/null || echo "MySQL log directory not found (normal in containerized environments)"
Comprendre la journalisation des erreurs selon l’environnement :
- Installations traditionnelles : les journaux des erreurs sont écrits dans des fichiers tels que
/var/log/mysql/error.log - Environnements conteneurisés : les erreurs sont souvent envoyées vers stdout/stderr et récupérées par le moteur d’exécution des conteneurs
- Bases de données dans le cloud : les journaux des erreurs sont généralement accessibles depuis l’interface de gestion du fournisseur cloud
En production, vous consulteriez régulièrement les journaux des erreurs à l’aide de commandes telles que :
sudo tail -f /var/log/mysql/error.log(pour suivre les journaux en temps réel)sudo grep -i error /var/log/mysql/error.log(pour rechercher des erreurs précises)
Cette pratique est essentielle pour surveiller l’état du serveur et diagnostiquer des problèmes tels que les échecs de démarrage, les tables corrompues ou les problèmes d’autorisation.
Résumé
Dans ce laboratoire, vous avez découvert les techniques fondamentales de gestion des erreurs et de journalisation dans MySQL. Vous avez commencé par activer et configurer le journal général afin de suivre les instructions SQL, une compétence importante pour le débogage. Vous avez ensuite mis en place une gestion robuste des erreurs dans une procédure stockée à l’aide de DECLARE HANDLER, afin de traiter correctement certaines erreurs.
Vous avez également appris à faire respecter des règles métier en déclenchant des erreurs personnalisées avec l’instruction SIGNAL, qui fournit des messages clairs et précis. Enfin, vous avez découvert les principes de la journalisation des erreurs dans MySQL, notamment les différences entre les installations traditionnelles et les environnements conteneurisés comme les conteneurs Docker.
Vous avez appris que les installations MySQL traditionnelles écrivent les journaux des erreurs dans des fichiers comme /var/log/mysql/error.log, tandis que les environnements conteneurisés redirigent souvent les erreurs vers stdout/stderr pour mieux s’intégrer aux plateformes d’orchestration de conteneurs. Cette distinction est importante lorsque vous travaillez avec des environnements de déploiement modernes.
Grâce à ces techniques, vous êtes désormais mieux préparé à créer des applications de base de données fiables, à diagnostiquer efficacement les problèmes et à garantir l’intégrité de vos bases de données MySQL dans différents environnements de déploiement.
