Fichiers journaux de base de données MariaDB - Amazon Relational Database Service

Fichiers journaux de base de données MariaDB

Vous pouvez contrôler le journal des erreurs, le journal des requêtes lentes et le journal général MariaDB. Le fichier journal des erreurs MariaDB est généré par défaut ; vous pouvez générer les journaux des requêtes lentes et général en définissant des paramètres dans votre groupe de paramètres de base de données. Amazon RDS fait tourner tous les fichiers de journaux MariaDB. Les intervalles pour chaque type sont indiquées ci-après.

Vous pouvez contrôler les journaux MariaDB directement via la console Amazon RDS, l'API Amazon RDS, l'interface en ligne de commande Amazon RDS ou les kits SDK AWS. Vous pouvez également accéder aux journaux MariaDB en dirigeant les journaux vers une table de base de données de la base de données principale et interroger cette table. Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger un journal binaire.

Pour plus d'informations sur l'affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez Fichiers journaux de base de données Amazon RDS.

Accès aux journaux des erreurs MariaDB

Le journal des erreurs MariaDB est écrit dans le fichier <host-name>.err. Vous pouvez afficher ce fichier à l'aide de la console Amazon RDS ou en récupérant le journal à l'aide de l'API Amazon RDS, de l'interface de ligne de commande Amazon RDS ou des kits SDK AWS. Le fichier <host-name>.err est vidé toutes les 5 minutes, et son contenu est ajouté à mysql-error-running.log. Le fichier mysql-error-running.log fait ensuite l'objet d'une rotation toutes les heures et les fichiers générés toutes les heures au cours des 24 dernières heures sont conservés. Le nom du fichier journal comporte l'heure à laquelle le fichier a été généré (au format UTC). Les fichiers journaux comportent également un horodatage permettant de déterminer le moment où les entrées du journal ont été écrites.

MariaDB écrit des informations dans le fichier des erreurs uniquement au moment du démarrage, de l'arrêt et lorsqu'une erreur survient. Une instance de base de données peut fonctionner pendant des heures ou des jours sans qu'aucune nouvelle entrée soit écrite dans le journal des erreurs. Si aucune entrée récente ne figure, cela signifie que le serveur n'a pas rencontré d'erreur justifiant une entrée de journal.

Accès au journal des requêtes lentes et au journal général MariaDB

Le journal des requêtes lentes et le journal général MariaDB peuvent être écrits dans un fichier ou dans une table de base de données en définissant les paramètres nécessaires dans votre groupe de paramètres DB. Pour plus d'informations sur la création et la modification d'un groupe de paramètres DB, consultez Utilisation de groupes de paramètres de base de données. Vous devez définir ces paramètres avant de pouvoir consulter le journal des requêtes lentes ou le journal général dans la console Amazon RDS ou à l'aide de l'API Amazon RDS, de l'AWS CLI ou des kits SDK AWS.

Vous pouvez contrôler la journalisation MariaDB à l'aide des paramètres de cette liste :

  • slow_query_log : Pour créer le journal des requêtes lentes, définir sur 1. La valeur par défaut est 0.

  • general_log : Pour créer le journal général, définir sur 1. La valeur par défaut est 0.

  • long_query_time : Pour empêcher l'enregistrement des requêtes rapides dans le journal des requêtes lentes, indiquez la valeur de la durée d'exécution de requête la plus courte devant être enregistrée, en secondes. La valeur par défaut est de 10 secondes et la valeur minimum est 0. Si log_output = FILE, vous pouvez indiquer une valeur à virgule flottante avec une résolution en microseconde. Si log_output = TABLE, vous devez indiquer un nombre entier avec une résolution en seconde. Seules les requêtes dont la durée d'exécution dépasse la valeur long_query_time sont enregistrées. Par exemple, si vous définissez long_query_time sur 0,1, les requêtes s'exécutant pendant moins de 100 millisecondes ne sont pas enregistrées.

  • log_queries_not_using_indexes : Pour enregistrer toutes les requêtes n'utilisant pas d'index dans le journal des requêtes lentes, définir ce paramètre sur 1. La valeur par défaut est 0. Les requêtes n'utilisant pas d'index sont enregistrées même si la durée de leur exécution est inférieure à la valeur du paramètre long_query_time.

  • log_output option : Vous pouvez spécifier l'une des options suivantes pour le paramètre log_output :

    • TABLEAU (par défaut) – Écrit les requêtes générales dans le tableau mysql.general_log et les requêtes lentes dans le tableau mysql.slow_log.

    • FILE (FICHIER) – Écrit les fichiers des requêtes générales et lentes dans le fichier système. Les fichiers journaux font l'objet d'une rotation horaire.

    • NONE (AUCUNE)– Désactive la journalisation.

Lorsque la journalisation est activée, Amazon RDS effectue une rotation des journaux des tables ou supprime les fichiers journaux à intervalles réguliers. Cette précaution permet de limiter la possibilité qu'un fichier journal volumineux ne bloque l'utilisation de la base de données ou n'affecte les performances. Rotation et suppression de l'approche de journalisation FILE et TABLE comme suit :

  • Lorsque la journalisation FILE est activée, les fichiers journaux sont examinés toutes les heures et ceux dont l'ancienneté est supérieure à 24 heures sont supprimés. Dans certains cas, la taille des fichiers journaux combinés restant après la suppression peut dépasser le seuil de 2 % de l'espace alloué à une instance de base de données. Dans ces cas, les fichiers journaux les plus volumineux sont supprimés jusqu'à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.

  • Lorsque la journalisation de TABLE est activée, les journaux des tables font dans certains cas l'objet d'une rotation toutes les 24 heures. Cette rotation se produit si l'espace utilisé par les journaux des tables est supérieur à 20 % de l'espace de stockage alloué ou si la taille de l'ensemble des journaux est supérieure à 10 Go. Si l'espace utilisé pour une instance de base de données est supérieur à 90 % de l'espace de stockage alloué à l'instance de base de données, alors les seuils correspondant à la rotation des journaux est réduite. Les tables de journaux font alors l'objet d'une rotation si l'espace utilisé par les journaux des tables est supérieur à 10 % de l'espace de stockage alloué ou si la taille de l'ensemble des journaux est supérieure à 5 Go.

    Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table de journal de sauvegarde existe déjà, elle est supprimée avant que la table de journal actuelle ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table mysql.general_log est nommée mysql.general_log_backup. La table de journal de sauvegarde de la table mysql.slow_log est nommée mysql.slow_log_backup.

    Vous pouvez effectuer une rotation de la table mysql.general_log en appelant la procédure mysql.rds_rotate_general_log. Vous pouvez effectuer une rotation de la table mysql.slow_log en appelant la procédure mysql.rds_rotate_slow_log.

    La rotation des journaux des tables est effectuée pendant la mise à niveau de la version d'une base de données.

Amazon RDS enregistre la rotation des journaux TABLE et FILE dans un événement Amazon RDS et vous envoie une notification.

Pour utiliser les journaux depuis la console Amazon RDS, l'API Amazon RDS, la CLI Amazon RDS ou les kits SDK AWS, définissez le paramètre log_output sur FILE. A l'instar du journal des erreurs MariaDB, ces fichiers journaux font l'objet d'une rotation horaire. Les fichiers journaux qui ont été générés au cours des dernières 24 heures sont conservés.

Pour plus d'informations sur le journal des requêtes lentes et le journal général, accédez aux rubriques suivantes dans la documentation MariaDB :

Publication des journaux MariaDB dans Amazon CloudWatch Logs

Vous pouvez configurer votre instance de base de données MariaDB Amazon RDS de sorte à publier des données de journaux dans un groupe de journaux dans Amazon CloudWatch Logs. CloudWatch Logs vous permet d'effectuer une analyse en temps réel des données de journaux et d'utiliser CloudWatch pour créer des alarmes et afficher des métriques. CloudWatch Logs permet de conserver les enregistrements des journaux dans une solution de stockage hautement durable.

Amazon RDS publie chaque journal de base de données MariaDB sous la forme d'un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous configurez la fonction d'exportation de sorte à inclure le journal de requêtes lentes, les données de requêtes lentes sont stockées dans un flux de journal de requêtes lentes dans le groupe de journaux /aws/rds/instance/my_instance/slowquery.

Le journal d'erreurs est activé par défaut. Le tableau ci-dessous récapitule les conditions requises pour les autres journaux MariaDB.

Log Exigence

Journal d'audit

L'instance de base de données doit disposer d'un groupe d'options personnalisées avec l'option MARIADB_AUDIT_PLUGIN.

Journal général

L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre general_log = 1 pour autoriser la journalisation générale.

Journal des requêtes lentes

L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre slow_query_log = 1 pour autoriser la journalisation de requête lente.

Sortie de journal

L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre log_output = FILE pour écrire de journaux dans le système de fichier et les publier dans CloudWatch Logs.

Pour publier des journaux MariaDB dans CloudWatch Logs à partir de la console

  1. Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Bases de données, puis l'instance de base de données que vous souhaitez modifier.

  3. Sélectionnez Modify.

  4. Dans la section Exportations des journaux, choisissez les journaux que vous voulez commencer à publier dans CloudWatch Logs.

  5. Choisissez Continuer, puis Modifier l'instance de base de données sur la page récapitulative.

Vous pouvez publier un journal MariaDB avec l'interface de ligne de commande AWS. Vous pouvez appeler la commande modify-db-instance avec les paramètres suivants :

  • --db-instance-identifier

  • --cloudwatch-logs-export-configuration

Note

Une modification apportée à l'option --cloudwatch-logs-export-configuration est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, les options --apply-immediately et --no-apply-immediately sont sans effet.

Vous pouvez également publier des journaux MariaDB en appelant les commandes de l'interface de ligne de commande AWS suivantes :

Exécutez l'une de ces commandes de l'interface de ligne de commande AWS avec les options suivantes :

  • --db-instance-identifier

  • --enable-cloudwatch-logs-exports

  • --db-instance-class

  • --engine

D'autres options peuvent être requises en fonction de la commande de l'AWS CLI que vous exécutez.

Exemple

L'exemple suivant modifie une instance de base de données MariaDB existante pour publier les fichiers journaux dans CloudWatch Logs. La valeur --cloudwatch-logs-export-configuration n'est pas un objet JSON. La clé pour cet objet est EnableLogTypes et sa valeur est un tableau de chaînes avec une combinaison quelconque de audit, error, general et slowquery.

Pour Linux, macOS ou Unix :

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'

Pour Windows :

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'

Exemple

La commande suivante crée une instance de base de données MariaDB et publie les fichiers journaux dans CloudWatch Logs. La valeur --enable-cloudwatch-logs-exports est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison de audit, error, general et slowquery.

Pour Linux, macOS ou Unix :

aws rds create-db-instance \ --db-instance-identifier mydbinstance \ --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' \ --db-instance-class db.m4.large \ --engine mariadb

Pour Windows :

aws rds create-db-instance ^ --db-instance-identifier mydbinstance ^ --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' ^ --db-instance-class db.m4.large ^ --engine mariadb

Vous pouvez publier des journaux MariaDB avec l'API RDS. Vous pouvez appeler l'opération ModifyDBInstance avec les paramètres suivants :

  • DBInstanceIdentifier

  • CloudwatchLogsExportConfiguration

Note

Une modification apportée au paramètre CloudwatchLogsExportConfiguration est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, le paramètre ApplyImmediately est sans effet.

Vous pouvez également publier des journaux MariaDB en appelant les opérations d'API RDS suivantes :

Exécutez l'une de ces opérations d'API RDS avec les paramètres suivants :

  • DBInstanceIdentifier

  • EnableCloudwatchLogsExports

  • Engine

  • DBInstanceClass

D'autres paramètres peuvent être requis en fonction de la commande d'interface de ligne de commande AWS que vous exécutez.

Taille des fichiers journaux

Les tailles du journal des requêtes lentes, du journal des erreurs et du journal général MariaDB sont limitées à 2 %maximum de l'espace de stockage alloué à une instance de base de données. Pour respecter ce seuil, les journaux font l'objet d'une rotation automatique toutes les heures et les fichiers dont l'ancienneté est supérieure à 24 heures sont supprimés. Si la taille de l'ensemble des fichiers journaux après la suppression dépasse le seuil, les fichiers journaux les plus volumineux sont supprimés jusqu'à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.

Gestion des journaux MariaDB sous forme de table

Vous pouvez diriger le journal des requêtes lentes et le journal général vers des tables sur l'instance de base de données en créant un groupe de paramètres DB et en définissant le paramètre du serveur log_output sur TABLE. Les requêtes générales sont ensuite enregistrées dans la table mysql.general_log et les requêtes lentes dans la table mysql.slow_log. Vous pouvez interroger les tables pour accéder aux informations des journaux. L'activation de cette journalisation augmente le volume de données écrites dans la base de données, ce qui peut dégrader les performances.

Par défaut, le journal général et le journal des requêtes lentes sont désactivés. Afin d'activer la journalisation dans les tables, vous devez également définir les paramètres general_log et slow_query_log sur 1.

Les tables de journaux continuent de grossir jusqu'à ce que les activités de journalisation correspondantes soient désactivées en redéfinissant le paramètre approprié sur 0. Avec le temps, une grande quantité de données s'accumule et risque d'utiliser une part considérable de l'espace de stockage alloué. Amazon RDS ne vous permet pas de tronquer les tableaux de journaux, mais vous pouvez déplacer leurs contenus. Lorsque vous procédez à la rotation d'une table, son contenu est enregistré dans une table de sauvegarde et une nouvelle table de journal vide est créée. Vous pouvez effectuer une rotation manuelle des tables de journaux avec les procédures de ligne de commande suivantes, dans lesquelles l'invite de commande est indiquée par PROMPT> :

PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log;

Pour supprimer totalement les anciennes données et récupérer l'espace de disque, appelez deux fois à la suite la procédure appropriée.

Format de journalisation binaire

MariaDB sur Amazon RDS prend en charge les formats de journalisation binaire basés sur les lignes, basés sur les instructions et mixtes. Le format de journalisation binaire par défaut est mixte. Pour plus de détails sur les différents formats de journalisation binaire MariaDB, consultez Formats de journalisation binaire dans la documentation MariaDB.

Si vous prévoyez d'utiliser la réplication, le format de journalisation binaire est important car il détermine le dossier de modifications de données qui est enregistré dans la source et envoyés aux cibles de réplication. Pour de plus amples informations sur les avantages et les inconvénients des différents formats de journalisation binaire pour la réplication, veuillez consulter la section Advantages and Disadvantages of Statement-Based and Row-Based Replication de la documentation MySQL.

Important

Lorsque vous définissez le format de journalisation binaire sur « basé sur les lignes », vous risquez de générer des fichiers journaux binaires très volumineux. Ces derniers réduisent le stockage disponible pour une instance de base de données et peuvent augmenter la durée nécessaire pour effectuer une opération de restauration d'une instance de base de données.

La réplication basée sur les instructions peut provoquer des incohérences entre l'instance de base de données source et un réplica en lecture. Pour plus d'informations, consultez la section Unsafe Statements for Statement-based Replication dans la documentation MariaDB.

Pour définir le format de journalisation binaire MariaDB :

  1. Connectez-vous au AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le volet de navigation, choisissez Groupes de paramètres.

  3. Choisissez le groupe de paramètres utilisé par l'instance de base de données que vous souhaitez modifier.

    Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si l'instance de base de données utilise un groupe de paramètres par défaut, créez un nouveau groupe et associez-le à l'instance.

    Pour plus d'informations sur les groupes de paramètres de base de données, consultez Utilisation de groupes de paramètres de base de données.

  4. Sous Parameter group actions (Actions de groupe de paramètres), choisissez Edit (Modifier).

  5. Définissez le paramètre binlog_format au format de journalisation binaire de votre choix (ROW, STATEMENT ou MIXED).

  6. Choisissez Enregistrer les modifications pour enregistrer les mises à jour apportées au groupe de paramètres de base de données.

Accès aux journaux binaires MariaDB

Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger les journaux binaires au format texte à partir d'instances de base de données MariaDB. Le journal binaire est téléchargé dans votre ordinateur local. Pour plus d'informations sur l'utilisation de l'utilitaire mysqlbinlog, accédez à Utilisation de mysqlbinlog dans la documentation MariaDB.

Pour exécuter à nouveau l'utilitaire mysqlbinlog sur une instance Amazon RDS, utilisez les options suivantes :

  • Spécifiez l'option --read-from-remote-server.

  • --host : Spécifiez le nom DNS du point de terminaison de l'instance.

  • --port : Spécifiez le port utilisé par l'instance.

  • --user : Spécifiez un utilisateur MariaDB ayant l'autorisation de réplication esclave.

  • --password : Spécifiez le mot de passe de l'utilisateur ou omettez la valeur de mot de passe pour que l'utilitaire vous invite à saisir un mot de passe.

  • --result-file : Spécifiez le fichier local qui recevra la sortie.

  • Spécifiez les noms pour un ou plusieurs fichiers journaux binaires. Pour obtenir la liste des journaux disponibles, utilisez la commande SQL SHOW BINARY LOGS.

Pour plus d'informations sur les options mysqlbinlog, accédez aux Options mysqlbinlog dans la documentation MariaDB.

Voici un exemple :

Pour Linux, macOS ou Unix :

mysqlbinlog \ --read-from-remote-server \ --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password <password> \ --result-file=/tmp/binlog.txt

Pour Windows :

mysqlbinlog ^ --read-from-remote-server ^ --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password <password> ^ --result-file=/tmp/binlog.txt

Amazon RDS purge normalement un journal binaire dès que possible, mais le journal binaire doit toujours être disponible sur l'instance afin que mysqlbinlog puisse y accéder. Pour spécifier le nombre d'heures pendant lesquelles RDS conservera les journaux binaires, utilisez la procédure stockée mysql.rds_set_configuration et spécifiez une période suffisamment longue pour pouvoir télécharger les journaux. Après avoir défini la période de rétention, surveillez l'utilisation du stockage pour l'instance de bases de données afin de garantir que les journaux binaires conservés n'utilisent pas trop d'espace de stockage.

L'exemple suivant définit la période de rétention sur 1 jour :

call mysql.rds_set_configuration('binlog retention hours', 24);

Pour afficher les paramètres actuels, utilisez la procédure stockée mysql.rds_show_configuration :

call mysql.rds_show_configuration;

Annotation des journaux binaires

Dans une instance de base de données MariaDB, vous pouvez utiliser l'événement Annotate_rows pour annoter un événement de ligne avec une copie de la requête SQL ayant provoqué cet événement. Cette approche offre une fonctionnalité similaire à l'activation du paramètre binlog_rows_query_log_events sur une instance de base de données sur une version MySQL 5.6 ou ultérieure.

Vous pouvez activer globalement les annotations des journaux binaires en créant un groupe de paramètres personnalisé et en définissant le paramètre binlog_annotate_row_events sur 1. Vous pouvez également activer les annotations au niveau de la session, en appelant SET SESSION binlog_annotate_row_events = 1. Utilisez replicate_annotate_row_events pour répliquer les annotations des journaux binaires dans l'instance esclave si la journalisation binaire est activée pour cette instance. Aucun privilège spécial n'est nécessaire pour utiliser ces paramètres.

L'exemple suivant illustre une transaction basée sur les lignes dans MariaDB. L'utilisation de la journalisation basée sur les lignes est déclenchée en définissant le niveau d'isolement des transactions sur read-committed.

CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN INSERT INTO square(x, y) VALUES(5, 5 * 5); COMMIT;

Sans les annotations, les entrées du journal binaire pour la transaction ressemblent à :

BEGIN /*!*/; # at 1163 # at 1209 #150922 7:55:57 server id 1855786460 end_log_pos 1209 Table_map: `test`.`square` mapped to number 76 #150922 7:55:57 server id 1855786460 end_log_pos 1247 Write_rows: table id 76 flags: STMT_END_F ### INSERT INTO `test`.`square` ### SET ### @1=5 ### @2=25 # at 1247 #150922 7:56:01 server id 1855786460 end_log_pos 1274 Xid = 62 COMMIT/*!*/;

L'instruction suivante active les annotations au niveau de la session pour cette même transaction, et les désactive après validation de la transaction :

CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SET SESSION binlog_annotate_row_events = 1; BEGIN; INSERT INTO square(x, y) VALUES(5, 5 * 5); COMMIT; SET SESSION binlog_annotate_row_events = 0;

Avec les annotations, les entrées du journal binaire pour la transaction ressemblent à :

BEGIN /*!*/; # at 423 # at 483 # at 529 #150922 8:04:24 server id 1855786460 end_log_pos 483 Annotate_rows: #Q> INSERT INTO square(x, y) VALUES(5, 5 * 5) #150922 8:04:24 server id 1855786460 end_log_pos 529 Table_map: `test`.`square` mapped to number 76 #150922 8:04:24 server id 1855786460 end_log_pos 567 Write_rows: table id 76 flags: STMT_END_F ### INSERT INTO `test`.`square` ### SET ### @1=5 ### @2=25 # at 567 #150922 8:04:26 server id 1855786460 end_log_pos 594 Xid = 88 COMMIT/*!*/;