Journalisation pour les bases de données Aurora MySQL

Erreur — Aurora MySQL écrit dans le journal des erreurs uniquement au démarrage, à l'arrêt et en cas d'erreur. 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. La journalisation des erreurs est activée par défaut. Pour plus d’informations, consultez Journaux d'SQLerreurs SQL .

Général — Le journal général fournit des informations détaillées sur l'activité de la base de données, y compris toutes les instructions SQL exécutées par le moteur de base de données. Pour plus d'informations sur l'activation de la journalisation générale et la définition des paramètres de journalisationRequête SQL lente et journaux généraux d'Aurora My SQL RDS, consultez la section « Le journal général des requêtes » dans la documentation MySQL.

Requête lente : le journal des requêtes lentes contient des instructions SQL dont l'exécution prend plus de long_query_time en secondes et qui nécessitent l'examen d'au moins des lignes min_examined_row_limit. Vous pouvez utiliser le journal des requêtes lentes pour rechercher les requêtes dont l'exécution prend du temps et qui sont donc susceptibles d'être optimisées.

La valeur par défaut de long_query_time est 10 secondes. Nous vous recommandons de commencer par une valeur élevée pour identifier les requêtes les plus lentes, puis de redescendre pour affiner le réglage.

Vous pouvez également utiliser des paramètres connexes, tels que log_slow_admin_statements etlog_queries_not_using_indexes. Comparez rows_examined avecrows_returned. Si rows_examined cette valeur est bien supérieure àrows_returned, ces requêtes peuvent potentiellement être bloquantes.

Dans Aurora MySQL version 3, vous pouvez l'activer log_slow_extra pour obtenir plus de détails. Pour plus d'informations, consultez le contenu du journal des requêtes lent dans la documentation MySQL. Vous pouvez également effectuer des modifications long_query_time au niveau de la session pour déboguer l'exécution des requêtes de manière interactive, ce qui est particulièrement utile si cette option log_slow_extra est activée globalement.

Pour plus d'informations sur l'activation de la journalisation lente des requêtes et la définition des paramètres de journalisationRequête SQL lente et journaux généraux d'Aurora My SQL RDS, consultez « The slow query log » dans la documentation MySQL.

Audit — Le journal d'audit surveille et enregistre l'activité de la base de données. La journalisation d'audit pour Aurora MySQL se nomme « audit avancé ». Pour activer l'audit avancé, vous devez définir certains paramètres du cluster de bases de données. Pour plus d’informations, consultez Utilisation de l'audit avancé avec un cluster Amazon Aurora My SQL DB.

Binaire — Le journal binaire (binlog) contient des événements qui décrivent les modifications apportées à la base de données, telles que les opérations de création de tables et les modifications apportées aux données des tables. Il contient également des événements pour des instructions susceptibles d'apporter des modifications (par exemple, un DELETE ne correspondant à aucune ligne), à moins que la journalisation basée sur les lignes ne soit utilisée. Le journal binaire contient également des informations sur le temps que chaque instruction a pris pour mettre à jour les données.

L'exécution d'un serveur avec la journalisation binaire activée ralentit légèrement les performances. Toutefois, les avantages de la connexion binaire, qui permet de configurer la réplication et d'effectuer des opérations de restauration, compensent généralement cette baisse mineure des performances.

Pour plus d'informations sur l'activation de la journalisation binaire et la définition du format de journal binaireConfiguration d'Aurora MySQL, consultez la section « Le journal binaire » dans la documentation MySQL.