Journalisation pour les bases de données Aurora MySQL - Amazon Aurora

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Journalisation pour les bases de données Aurora MySQL

Les journaux Aurora MySQL fournissent des informations essentielles sur l’activité et les erreurs de base de données. En les activant, vous pouvez identifier et résoudre les problèmes, comprendre les performances de la base de données et en auditer l’activité. Nous vous recommandons d’activer ces journaux pour toutes vos instances de base de données Aurora MySQL afin de garantir des performances et une disponibilité optimales des bases de données. Les types de journaux suivants peuvent être activés. Chaque journal contient des informations spécifiques qui peuvent contribuer à identifier des impacts sur le traitement de la base de données.

  • Erreur : Aurora MySQL écrit dans le journal d’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. La journalisation des erreurs est activée par défaut. Pour plus d’informations, consultez Journaux des erreurs Aurora MySQL.

  • 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 journalisation, consultez Journal des requêtes lentes et journal général Aurora MySQL et Journal des requêtes générales dans la documentation MySQL.

    Note

    Les journaux généraux peuvent devenir très volumineux et consommer de l’espace de stockage. Pour plus d’informations, consultez Renouvellement et rétention des journaux pour Aurora MySQL.

  • Requêtes lentes : le journal des requêtes lentes se compose des instructions SQL qui ont pris plus de long_query_time secondes pour s’exécuter et qui nécessitent l’examen d’au moins min_examined_row_limit lignes. 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 de bonnes candidates pour l’optimisation.

    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 la réduire petit à petit pour optimiser le réglage.

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

    Dans Aurora MySQL version 3, vous pouvez activer log_slow_extra pour obtenir plus de détails. Pour plus d’informations, consultez Contenu du journal des requêtes lentes dans la documentation MySQL. Vous pouvez également modifier 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 log_slow_extra est activé globalement.

    Pour plus d’informations sur l’activation de la journalisation des requêtes lentes et la définition des paramètres de journalisation, consultez Journal des requêtes lentes et journal général Aurora MySQL et Journal des requêtes lentes 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éfinie certains paramètres de cluster de bases de données. Pour plus d’informations, consultez Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL.

  • Binaire : le journal binaire (binlog) contient les événements qui décrivent les modifications apportées à la base de données, telles que les opérations de création de tables ou de modification des données des tables. Il contient également les événements relatifs aux instructions susceptibles d’apporter des modifications (par exemple, une instruction 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 nécessaire à chaque instruction pour mettre à jour les données.

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

    Note

    Aurora MySQL ne nécessite pas de journalisation binaire pour les opérations de restauration.

    Pour plus d’informations sur l’activation de la journalisation binaire et la définition du format de journal binaire, consultez Configuration d’Aurora MySQL pour la journalisation des bases de données mono-AZ et Journal binaire dans la documentation MySQL.

Vous pouvez publier les journaux d’erreurs, les journaux généraux, les journaux de requêtes lentes et les journaux d’audit dans Amazon CloudWatch Logs. Pour plus d’informations, consultez Publication des journaux de base de données dans Amazon CloudWatch Logs.

pt-query-digest est un autre outil utile pour résumer les journaux de requêtes lentes, les journaux généraux et les journaux binaires.