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 journal des erreurs MySQL est généré par défaut. Vous pouvez générer le journal des requêtes lentes et le journal général en définissant les paramètres nécessaires dans votre groupe de paramètres DB. Amazon RDS assura la rotation de tous les fichiers journaux MariaDB. Les intervalles pour chaque type sont donnés ci-dessous.

Vous pouvez surveiller les journaux MariaDB directement via la console Amazon RDS, l'API Amazon RDS, la CLI Amazon RDS ou les 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 Surveillance des fichiers journaux Amazon RDS.

Accès aux journaux des erreurs MariaDB

Le journal des erreurs MariaDB est écrit dans le fichier <host-name>.err. Vous pouvez consulter ce fichier à l'aide de la console Amazon RDS. Vous pouvez également récupérer le journal à l'aide de l'API Amazon RDS, AWS de la CLI Amazon RDS ou des kits SDK. 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 MariaDB et le journal général 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 de base de données. Pour plus d'informations sur la création et la modification d'un groupe de paramètres DB, consultez Utilisation des groupes de paramètres. 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 ou AWS des AWS CLI SDK.

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

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 :

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 provenant de la console Amazon RDS, de l'API Amazon RDS, de la CLI Amazon RDS AWS ou des SDK, définissez log_output le paramètre 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 :

Publier des logs MariaDB sur Amazon Logs CloudWatch

Vous pouvez configurer votre instance de base de données MariaDB pour publier les données de journal dans un groupe de journaux dans Amazon Logs. CloudWatch Avec CloudWatch Logs, vous pouvez effectuer une analyse en temps réel des données du journal, puis les utiliser CloudWatch pour créer des alarmes et afficher des métriques. Vous pouvez utiliser CloudWatch les journaux pour stocker vos enregistrements de journal dans un espace 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, supposons que vous configuriez la fonction d'exportation de manière à inclure le journal de requêtes lentes. Les données de requêtes lentes sont ensuite stockées dans un flux de journaux 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.

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

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

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 
    			

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 
    			

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 les journaux des requêtes générales et lentes vers des tables sur l'instance de base de données. Pour ce faire, créez un groupe de paramètres de base de données et définissez le paramètre de 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. Pour activer la journalisation dans les tables, vous devez également définir les paramètres de serveur suivants 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 envisagez d'utiliser la réplication, le format de journalisation binaire est important. 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 plus d'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.

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 :

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

Voici un exemple :

Pour LinuxmacOS, 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

Dans 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. Toutefois, 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 lequel RDS conserve les journaux binaires, utilisez la procédure stockée mysql.rds_set_configuration. Spécifiez une période suffisamment longue pour 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.

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; 

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

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 de réplica 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/*!*/;