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

Fichiers journaux de base de données MySQL

Vous pouvez contrôler le journal des erreurs, le journal des requêtes lentes et le journal général MySQL. Le fichier journal des erreurs MySQL 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 que vous créez pour vos instances MySQL. Amazon RDS fait tourner tous les fichiers de journaux MySQL. Les intervalles pour chaque type sont indiquées ci-après.

Vous pouvez surveiller les journaux MySQL directement via la console Amazon RDS, l'API Amazon RDS, l'interface en ligne de commande AWS CLI ou les SDK AWS. Vous pouvez également accéder aux journaux MySQL 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 Amazon RDS Fichiers journaux de base de données.

Accès aux journaux d'erreurs MySQL

Le journal des erreurs MySQL est écrit dans le fichier mysql-error.log. Vous pouvez afficher mysql-error.log à 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 SDK AWS. mysql-error.log 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. Veuillez noter que la période de rétention est différente pour Amazon RDS et pour Aurora.

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.

MySQL écrit des informations dans le journal 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 MySQL

Le journal des requêtes lentes et le journal général MySQL 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'interface de ligne de commande Amazon RDS ou des SDK AWS.

Vous pouvez contrôler la journalisation MySQL à 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 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.

    • 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.

    • 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. Vous pouvez vous abonner à l'événement low_free_storage pour être informé lorsque les tables de journal font l'objet d'une rotation pour libérer de l'espace. Pour plus d'informations, consultez Utilisation de la notification d'événement Amazon RDS.

    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.

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 MySQL, 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. Veuillez noter que la période de rétention est différente pour Amazon RDS et pour Aurora.

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 MySQL :

Accès au journal d'audit MySQL

Pour accéder au journal d'audit, l'instance de base de données doit utiliser un groupe d'options personnalisé avec l'option MARIADB_AUDIT_PLUGIN. Pour de plus amples informations, veuillez consulter Prise en charge du plug-in d'audit MariaDB.

Publication des journaux MySQL dans CloudWatch Logs

Vous pouvez configurer votre instance de base de données MySQL 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 MySQL 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 MySQL.

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.

Note

La publication de fichiers journaux dans CloudWatch Logs n'est prise en charge pour les versions 5.6, 5.7 et 8.0 de MySQL.

Pour publier des journaux MySQL dans CloudWatch Logs à l'aide 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 des journaux MySQL 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 MySQL 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 d'interface de ligne de commande AWS que vous exécutez.

L'exemple suivant modifie une instance de base de données MySQL 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"]}'

L'exemple suivant crée une instance de base de données MySQL 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 MySQL

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 MySQL

Vous pouvez publier des journaux MySQL avec l'API RDS. Vous pouvez appeler l'action 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 MySQL 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 MySQL 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.

Pour MySQL, une taille limite est appliquée aux objets BLOB écrits dans le fichier journal redo. Pour prendre en compte cette limite, vérifiez que le paramètre innodb_log_file_size de votre instance de base de données MySQL est dix fois supérieur à la taille des données BLOB les plus volumineuses figurant dans vos tables, plus la longueur des autres champs de longueur variable (VARCHAR, VARBINARY, TEXT) dans ces tables. Pour plus d'informations sur la manière de définir les valeurs des paramètres, consultez Utilisation de groupes de paramètres de base de données. Pour plus d'informations sur la taille limite des objets BLOB du fichier journal redo, accédez à Changements dans MySQL 5.6.20.

Gestion des journaux MySQL 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

MySQL sur Amazon RDS prend en charge les formats de journalisation binaire basés sur les lignes, basés sur les instructions et mixtes pour les versions MySQL 5.6 et ultérieures. Le format de journalisation binaire par défaut est « mixte ». Pour les instances de bases de données s'exécutant sur les versions MySQL 5.1 et 5.5, seule la journalisation binaire est prise en charge. Pour plus de détails sur les différents formats de journalisation binaire MySQL, veuillez consulter Binary Logging Formats de la documentation MySQL.

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 de plus amples informations, veuillez consulter Determination of Safe and Unsafe Statements in Binary Logging dans la documentation MySQL.

Pour définir le format de journalisation binaire MySQL

  1. 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, consultez Utilisation de groupes de paramètres de base de données.

  4. Dans 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 de base de données.

Important

La modification d'un groupe de paramètres de base de données affecte toutes les instances de base de données qui utilisent ce dernier. Si vous souhaitez spécifier des formats de journalisation binaire différents pour différentes instances de base de données MySQL dans une région AWS, les instances de base de données doivent utiliser différents groupes de paramètres de base de données. Ces groupes de paramètres identifient différents formats de journalisation. Affectez le groupe de paramètres de base de données approprié à chaque instance de base de données.

Accès aux journaux binaires MySQL

Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger ou diffuser des journaux binaires à partir d'instances Amazon RDS exécutant la version MySQL 5.6 ou une version ultérieure. Le journal binaire est téléchargé dans votre ordinateur local et vous pouvez effectuer des actions comme relire le journal à l'aide de l'utilitaire mysql. Pour de plus amples informations sur l'utilisation de l'utilitaire mysqlbinlog, veuillez accéder à Utilisation de mysqlbinlog pour sauvegarder les fichiers journaux binaires.

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 MySQL 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.

  • Pour que le fichier soit téléchargé au format binaire, spécifiez l'option --raw.

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

  • 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 diffuser les fichiers journaux binaires, spécifiez l'option --stop-never.

Pour de plus amples informations sur les options mysqlbinlog, veuillez accéder à mysqlbinlog - Utilitaire de traitement des fichiers journaux binaires.

Par exemple, consultez ce qui suit.

Pour Linux, macOS ou Unix :

mysqlbinlog \ --read-from-remote-server \ --host=MySQL56Instance1.cg034hpkmmjt.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password \ --raw \ --result-file=/tmp/ \ binlog.00098

Pour Windows :

mysqlbinlog ^ --read-from-remote-server ^ --host=MySQL56Instance1.cg034hpkmmjt.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password ^ --raw ^ --result-file=/tmp/ ^ binlog.00098

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 de l'instance de base de données afin de garantir que les journaux binaires conservés n'utilisent pas un espace de stockage trop grand.

Note

La procédure stockée mysql.rds_set_configuration est uniquement disponible pour les versions MySQL 5.6 ou ultérieures.

L'exemple suivant définit la période de conservation 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;