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_timeest 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_statementsetlog_queries_not_using_indexes. Comparezrows_examinedàrows_returned. Si la valeur derows_examinedest bien supérieure àrows_returned, ces requêtes peuvent potentiellement être bloquantes.Dans Aurora MySQL version 3, vous pouvez activer
log_slow_extrapour obtenir plus de détails. Pour plus d’informations, consultez Contenu du journal des requêtes lentesdans la documentation MySQL. Vous pouvez également modifier long_query_timeau niveau de la session pour déboguer l’exécution des requêtes de manière interactive, ce qui est particulièrement utile silog_slow_extraest 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