

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.

# Fichiers journaux de base de données MySQL
<a name="USER_LogAccess.Concepts.MySQL"></a>

Vous pouvez surveiller les journaux MySQL directement via la console Amazon RDS, l'API Amazon RDS ou AWS CLI. AWS SDKs 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 [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

**Topics**
+ [Présentation des journaux de base de données RDS for MySQL](USER_LogAccess.MySQL.LogFileSize.md)
+ [Publication des journaux MySQL dans Amazon CloudWatch Logs](USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.md)
+ [Envoi de la sortie du journal MySQL à des tables](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Configuration de la journalisation binaire MySQL pour les clusters de bases de données multi-AZ](USER_Binlog.MultiAZ.md)
+ [Accès aux journaux binaires MySQL](USER_LogAccess.MySQL.Binarylog.md)

# Présentation des journaux de base de données RDS for MySQL
<a name="USER_LogAccess.MySQL.LogFileSize"></a>

Vous pouvez surveiller les types de fichiers journaux RDS for MySQL suivants :
+ Journal des erreurs
+ Journal des requêtes lentes
+ Journal général
+ Journal d’audit
+ Journal d’instance
+ Journal des erreurs d’authentification de base de données IAM

Le journal des erreurs RDS for 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 de base de données.

**Topics**
+ [Journaux des erreurs RDS for MySQL](#USER_LogAccess.MySQL.Errorlog)
+ [Journal des requêtes lentes et journal général RDS for MySQL](#USER_LogAccess.MySQL.Generallog)
+ [Journal d’audit MySQL](#USER_LogAccess.MySQL.Auditlog)
+ [Renouvellement et rétention des journaux pour RDS for MySQL](#USER_LogAccess.MySQL.LogFileSize.retention)
+ [Limites de taille des journaux de reprise](#USER_LogAccess.MySQL.LogFileSize.RedoLogs)

## Journaux des erreurs RDS for MySQL
<a name="USER_LogAccess.MySQL.Errorlog"></a>

RDS for MySQL écrit les erreurs dans le fichier `mysql-error.log`. 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.

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

Par défaut, les journaux des erreurs sont filtrés de sorte que seuls les événements inattendus tels que les erreurs soient affichés. Toutefois, les journaux des erreurs contiennent également des informations supplémentaires sur la base de données, comme la progression des requêtes, qui ne sont pas affichées. Par conséquent, même en l’absence d’erreurs réelles, la taille des journaux des erreurs peut augmenter en raison des activités en cours sur la base de données. Et même si vous pouvez voir une certaine taille en octets ou en kilo-octets pour les journaux d'erreurs dans le AWS Management Console, ils peuvent contenir 0 octet lorsque vous les téléchargez.

RDS for MySQL écrit `mysql-error.log` sur le disque toutes les 5 minutes. Il ajoute le contenu du journal à `mysql-error-running.log`.

RDS for MySQL assure la rotation du fichier `mysql-error-running.log` toutes les heures. Les journaux générés au cours des deux dernières semaines sont conservés.

**Note**  
La période de conservation des journaux est différente pour Amazon RDS et Aurora.

## Journal des requêtes lentes et journal général RDS for MySQL
<a name="USER_LogAccess.MySQL.Generallog"></a>

Vous pouvez écrire le journal des requêtes lentes et le journal général RDS for MySQL dans un fichier ou dans une table de base de données. Pour ce faire, définissez les paramètres de 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 [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). 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 la CLI Amazon RDS ou. AWS SDKs

Vous pouvez contrôler la journalisation RDS for 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 journalisée, en secondes. La valeur par défaut est de 10 secondes et la valeur minimum est 0. Si log\$1output = FILE, vous pouvez indiquer une valeur à virgule flottante avec une résolution en microseconde. Si log\$1output = 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 journalisé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. Les requêtes n’utilisant pas d’index sont journalisées même si la durée de leur exécution est inférieure à la valeur du paramètre `long_query_time`. La valeur par défaut est 0.
+ `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.
  + **AUCUNE**– Désactive la journalisation.

Pour que les données de requête lentes apparaissent dans Amazon CloudWatch Logs, les conditions suivantes doivent être remplies :
+ CloudWatch Les journaux doivent être configurés pour inclure les journaux des requêtes lentes.
+ `slow_query_log` doit être activé.
+ `log_output` doit être défini sur `FILE`.
+ La durée de la requête doit être plus longue que celle configurée pour `long_query_time`.

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 :
+ [Journal des requêtes lentes](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [Journal des requêtes générales](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)

## Journal d’audit MySQL
<a name="USER_LogAccess.MySQL.Auditlog"></a>

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 plus d’informations, consultez [Prise en charge du plugin d'audit MariaDB pour MySQL](Appendix.MySQL.Options.AuditPlugin.md).

## Renouvellement et rétention des journaux pour RDS for MySQL
<a name="USER_LogAccess.MySQL.LogFileSize.retention"></a>

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. RDS for MySQL gère la rotation et la suppression des journaux comme suit :
+ 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 maintenir ce seuil, les journaux sont automatiquement renouvelés toutes les heures. MySQL supprime les fichiers journaux datant de plus de deux semaines. Si la taille de l’ensemble des fichiers journaux après la suppression dépasse le seuil, les fichiers journaux les plus anciens sont supprimés jusqu’à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.
+ Lorsque la journalisation `FILE` est activée, les fichiers journaux sont examinés toutes les heures et ceux datant de plus de deux semaines 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. Le cas échéant, les fichiers journaux les plus anciens 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 tables des journaux 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é. Cela se produit également si la taille de tous les journaux combinés 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. La rotation des journaux des tables se produit ensuite si l’espace utilisé par les journaux des tables est supérieur à 10 % de l’espace de stockage alloué. Elle se produit également si la taille de tous les journaux combinés est supérieure à 5 Go. Vous pouvez vous abonner à la catégorie d’événement `low 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 [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).

  Lors de la rotation des tables de journaux, la table de journal actuelle est d’abord copiée vers une table de journal de sauvegarde. Les entrées de la table de journal actuelle sont ensuite 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 de la console Amazon RDS, de l'API Amazon RDS, de l'interface de ligne de commande Amazon RDS, AWS SDKs ou définissez `log_output` le paramètre 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 deux dernières semaines sont conservés. Veuillez noter que la période de rétention est différente pour Amazon RDS et pour Aurora.

## Limites de taille des journaux de reprise
<a name="USER_LogAccess.MySQL.LogFileSize.RedoLogs"></a>

Pour RDS for MySQL versions 8.0.32 et antérieures, la valeur par défaut de ce paramètre est de 256 Mo. Ce montant est obtenu en multipliant la valeur par défaut du paramètre `innodb_log_file_size` (128 Mo) par la valeur par défaut du paramètre `innodb_log_files_in_group` (2). Pour plus d’informations, consultez [Best practices for configuring parameters for Amazon RDS for MySQL, part 1: Parameters related to performance](https://aws.amazon.com/blogs/database/best-practices-for-configuring-parameters-for-amazon-rds-for-mysql-part-1-parameters-related-to-performance/). 

Pour RDS for MySQL version 8.0.33 et versions mineures ultérieures, Amazon RDS utilise le paramètre `innodb_redo_log_capacity` au lieu du paramètre `innodb_log_file_size`. La valeur par défaut Amazon RDS du paramètre `innodb_redo_log_capacity` est 2 Go. Pour plus d’informations, consultez [Changements dans MySQL 8.0.30](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html) dans la documentation MySQL.

À partir de MySQL 8.4, Amazon RDS active le paramètre `innodb_dedicated_server` par défaut. Avec le paramètre `innodb_dedicated_server`, le moteur de base de données calcule les paramètres `innodb_buffer_pool_size` et `innodb_redo_log_capacity`. Pour de plus amples informations, veuillez consulter [Configuration de la taille du groupe de mémoires tampons et de la capacité du journal de reprise dans MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md).

# Publication des journaux MySQL dans Amazon CloudWatch Logs
<a name="USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs"></a>

Vous pouvez configurer votre instance de base de données MySQL 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.  | 
|  Journal des erreurs d’authentification de base de données IAM  |  Vous devez activer le type de journal `iam-db-auth-error` pour une instance de base de données en créant ou en modifiant une instance de base de données.  | 
|  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.  | 

## Console
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.CON"></a>

**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/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l'instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify**.

1. Dans la section **Exportations des journaux**, choisissez les journaux que vous voulez commencer à publier dans CloudWatch Logs.

1. Choisissez **Continuer**, puis **Modifier l'instance de base de données** sur la page récapitulative.

## AWS CLI
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.CLI"></a>

 Vous pouvez publier des journaux MySQL avec l AWS CLI. Vous pouvez appeler la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 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 AWS CLI suivantes : 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

Exécutez l'une de ces commandes de l'AWS CLI 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 de l'AWS CLI que vous exécutez.

**Example**  
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 :  

```
1. aws rds modify-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
Pour Windows :  

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

**Example**  
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 :  

```
1. aws rds create-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' \
4.     --db-instance-class db.m4.large \
5.     --engine MySQL
```
Pour Windows :  

```
1. aws rds create-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' ^
4.     --db-instance-class db.m4.large ^
5.     --engine MySQL
```

## API RDS
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.API"></a>

Vous pouvez publier des journaux MySQL avec l'API RDS. Vous pouvez appeler l'action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 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 : 
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)

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'AWS CLI que vous exécutez.

# Envoi de la sortie du journal MySQL à des tables
<a name="Appendix.MySQL.CommonDBATasks.Logs"></a>

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

# Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ
<a name="USER_LogAccess.MySQL.BinaryFormat"></a>

Le *journal binaire* est un jeu de fichiers journaux contenant des informations sur les modifications de données apportées à une instance de serveur MySQL. Le journal binaire contient des informations telles que les suivantes :
+ Événements décrivant les modifications apportées à la base de données telles que la création de tables ou les modifications de lignes
+ Informations sur la durée de chaque instruction qui a mis à jour les données
+ Événements pour des instructions pouvant mettre à jour des données mais ne l’ayant pas fait

Le journal binaire enregistre les instructions envoyées pendant la réplication. Il est également requis pour certaines opérations de récupération. Pour plus d’informations, consultez [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dans la documentation MySQL.

La fonction de sauvegarde automatisée détermine si la journalisation binaire est activée ou désactivée pour MySQL. Vous avez les options suivantes :

Activer la journalisation binaire  
Définissez la période de rétention des sauvegardes sur une valeur positive différente de zéro.

Désactiver la journalisation binaire  
Définissez la période de rétention des sauvegardes sur zéro.

Pour plus d’informations, consultez [Activation des sauvegardes automatiques](USER_WorkingWithAutomatedBackups.Enabling.md).

MySQL on Amazon RDS prend en charge les formats de journalisation binaire *basés sur les lignes*, *basés sur les instructions* et *mixtes*. Nous recommandons le format mixte, sauf si vous avez besoin d’un format binlog spécifique. Pour plus de détails sur les différents formats de journalisation binaire MySQL, consultez [Formats de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) dans 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 plus d’informations sur les avantages et les désavantages des différents formats de journalisation binaire pour la réplication, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) dans la documentation MySQL.

**Important**  
Avec MySQL 8.0.34, MySQL a rendu le paramètre `binlog_format` obsolète. Dans les versions ultérieures de MySQL, MySQL prévoit de supprimer le paramètre et de ne prendre en charge que la réplication basée sur les lignes. Par conséquent, nous recommandons d’utiliser la journalisation basée sur les lignes pour les nouvelles configurations de réplication MySQL. Pour plus d’informations, consultez [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) dans la documentation MySQL.  
Les versions 8.0 et 8.4 de MySQL acceptent le paramètre `binlog_format`. Lors de l’utilisation de ce paramètre, MySQL émet un avertissement d’obsolescence. Dans une future version majeure, MySQL supprimera le paramètre `binlog_format`.  
La réplication basée sur les instructions peut provoquer des incohérences entre l’instance source et un réplica en lecture. Pour plus d’informations, consultez [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) dans la documentation MySQL.  
L'activation de la journalisation binaire augmente le nombre d' I/O opérations d'écriture sur le disque sur le d'instances de base de données. Vous pouvez surveiller l'utilisation des IOPS à l'aide de cette `WriteIOPS` `` CloudWatch métrique.

**Pour définir le format de journalisation binaire MySQL**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Groupes de paramètres**.

1. Choisissez le groupe de paramètres de bases de données, associé à l’instance de base de données, que vous voulez modifier.

   Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si l’instance 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 [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).

1. Pour **Actions**, choisissez **Modifier**.

1. Définissez le paramètre `binlog_format` au format de journalisation binaire de votre choix (`ROW`, `STATEMENT` ou `MIXED`).

   Vous pouvez désactiver la journalisation binaire en définissant la période de conservation des sauvegardes d’une instance de base de données sur zéro, mais cela désactive les sauvegardes automatiques quotidiennes. La désactivation des sauvegardes automatiques désactive ou désactive la variable de session `log_bin`. Cela désactive la journalisation binaire sur l’instance de base de données RDS for MySQL, qui à son tour réinitialise la variable de session `binlog_format` à la valeur par défaut de `ROW` dans la base de données. Nous vous recommandons de ne pas désactiver les sauvegardes. Pour plus d’informations sur le paramètre **Période de rétention des sauvegardes**, consultez [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).

1. Choisissez **Save changes** (Enregistrer les modifications)pour enregistrer les mises à jour apportées au groupe de paramètres .

Le paramètre `binlog_format` étant dynamique dans RDS for MySQL, vous n’avez pas besoin de redémarrer l’instance de base de données pour que les modifications s’appliquent. (Notez que dans Aurora MySQL, ce paramètre est statique. Pour plus d’informations, consultez [Configuration de la journalisation binaire Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html).)

**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 différents formats de journalisation binaire pour différentes instances de base de données MySQL dans une AWS région, 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.

# Configuration de la journalisation binaire MySQL pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ"></a>

La journalisation binaire dans les clusters de bases de données multi-AZ Amazon RDS for MySQL enregistre toutes les modifications de base de données afin de prendre en charge la réplication point-in-time, la restauration et l'audit. Dans les clusters de bases de données multi-AZ, les journaux binaires synchronisent les nœuds secondaires avec le nœud primaire, ce qui garantit la cohérence des données entre les zones de disponibilité et permet des basculements fluides. 

Pour optimiser la journalisation binaire, Amazon RDS prend en charge la compression des transactions des journaux binaires, ce qui réduit les exigences de stockage pour les journaux binaires et améliore l’efficacité de la réplication.

**Topics**
+ [Compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ](#USER_Binlog.MultiAZ.compression)
+ [Configuration de la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ](#USER_Binlog.MultiAZ.configuring)

## Compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ.compression"></a>

La compression des transactions du journal binaire utilise l’algorithme zstd pour réduire la taille des données de transaction stockées dans les journaux binaires. Lorsqu'il est activé, le moteur de base de données MySQL compresse les charges utiles des transactions en un seul événement, minimisant I/O ainsi les frais de stockage. Cette fonctionnalité améliore les performances des bases de données, réduit la taille des journaux binaires et optimise l’utilisation des ressources pour la gestion et la réplication des journaux dans les clusters de bases de données multi-AZ.

Amazon RDS fournit la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ RDS for MySQL via les paramètres suivants :
+ `binlog_transaction_compression` : lorsque cette option est activée (`1`), le moteur de base de données compresse les données utiles des transactions et les écrit dans le journal binaire sous la forme d’un événement unique. Cela réduit l'utilisation du stockage et les I/O frais généraux. Ce paramètre est désactivé par défaut.
+ `binlog_transaction_compression_level_zstd` : configure le niveau de compression zstd pour les transactions du journal binaire. Des valeurs plus élevées augmentent le taux de compression, ce qui réduit encore les besoins en stockage mais augmente l’utilisation du processeur et de la mémoire pour la compression. La valeur par défaut est de 3, avec une plage de 1 à 22.

Ces paramètres vous permettent d’optimiser la compression des journaux binaires en fonction des caractéristiques de la charge de travail et de la disponibilité des ressources. Pour plus d’informations, consultez [Compression des transactions de journaux binaires](https://dev.mysql.com/doc/refman/8.4/en/binary-log-transaction-compression.html) dans la documentation MySQL.

La compression des transactions dans les journaux binaires présente les principaux avantages suivants :
+ La compression réduit la taille des journaux binaires, en particulier pour les charges de travail comportant des transactions importantes ou des volumes d’écriture élevés.
+ Les journaux binaires plus petits réduisent le réseau et la I/O surcharge, améliorant ainsi les performances de réplication.
+ Le paramètre `binlog_transaction_compression_level_zstd` permet de contrôler le compromis entre le taux de compression et la consommation de ressources.

## Configuration de la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ.configuring"></a>

Pour configurer la compression des transactions de journaux binaires pour un cluster de bases de données multi-AZ RDS for MySQL, modifiez les paramètres de cluster appropriés en fonction de vos exigences de charge de travail.

### Console
<a name="USER_Binlog.MultiAZ.configuring-console"></a>

**Pour activer la compression des transactions de journaux binaires**

1. Modifiez le groupe de paramètres du cluster de bases de données pour définir le paramètre `binlog_transaction_compression` sur `1`.

1. (Facultatif) Ajustez la valeur du paramètre `binlog_transaction_compression_level_zstd` en fonction de vos exigences en matière de charge de travail et de la disponibilité des ressources.

Pour de plus amples informations, veuillez consulter [Modification des paramètres d'un groupe de paramètres de cluster de base de données ](USER_WorkingWithParamGroups.ModifyingCluster.md).

### AWS CLI
<a name="USER_Binlog.MultiAZ.configuring-cli"></a>

Pour configurer la compression des transactions du journal binaire à l'aide de AWS CLI, utilisez la commande [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html).

**Example**  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name your-cluster-parameter-group \
  --parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```
Pour Windows :  

```
aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name your-cluster-parameter-group ^
  --parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```

### API RDS
<a name="USER_Binlog.MultiAZ.configuring-api"></a>

Pour configurer la compression des transactions de journaux binaires à l’aide de l’API Amazon RDS, utilisez l’opération [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html).

# Accès aux journaux binaires MySQL
<a name="USER_LogAccess.MySQL.Binarylog"></a>

Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger ou diffuser des journaux binaires à partir des instances de base de données RDS for MySQL. 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 plus d'informations sur l'utilisation de l'utilitaire mysqlbinlog, consultez [Using mysqlbinlog to back up binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) (Utilisation de mysqlbinlog pour sauvegarder les fichiers journaux binaires) dans la documentation MySQL.

Pour exécuter à nouveau l'utilitaire mysqlbinlog sur une instance Amazon RDS, utilisez les options suivantes :
+ `--read-from-remote-server` : obligatoire.
+ `--host` : le nom DNS du point de terminaison de l'instance.
+ `--port` : le port utilisé par l'instance.
+ `--user` : un utilisateur MySQL ayant l'autorisation `REPLICATION SLAVE`.
+ `--password` : le mot de passe de l'utilisateur MySQL ou omettez la valeur de mot de passe pour que l'utilitaire vous invite à saisir un mot de passe.
+ `--raw` : téléchargez le fichier au format binaire.
+ `--result-file` : le fichier local qui recevra la sortie brute.
+ `--stop-never` : diffusez les fichiers journaux binaires.
+ `--verbose` : lorsque vous utilisez le format binlog `ROW`, incluez cette option pour afficher les événements de ligne sous forme d'instructions pseudo-SQL. Pour plus d'informations sur l'option `--verbose`, consultez [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) (Affichage d'événements de ligne mysqlbinlog) dans la documentation MySQL.
+ 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 plus d'informations sur les options mysqlbinlog, consultez [mysqlbinlog — Utility for processing binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) (mysqlbinlog : utilitaire de traitement des fichiers journaux binaires) dans la documentation MySQL.

Les exemples suivants montrent comment utiliser l'utilitaire mysqlbinlog.

Pour Linux, macOS ou Unix :

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

Pour Windows :

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

Les journaux binaires doivent rester disponibles sur l’instance de base de données pour que l’utilitaire mysqlbinlog puisse y accéder. Pour garantir leur disponibilité, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) stockée et spécifiez une période suffisamment longue pour télécharger les journaux. Si cette configuration n’est pas définie, Amazon RDS purge les journaux binaires dès que possible, ce qui entraîne des lacunes dans les journaux binaires récupérés par l’utilitaire mysqlbinlog. 

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\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration).

```
call mysql.rds_show_configuration;
```