^
--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;
```
# Activation de l’annotation du journal binaire MariaDB
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/*!*/;
```
# Fichiers journaux de base de données Amazon RDS for Microsoft SQL Server
Vous pouvez accéder aux journaux des erreurs Microsoft SQL Server, aux journaux de l’agent, aux fichiers de trace et aux fichiers de vidage à l’aide de la console Amazon RDS, de l’ AWS CLI ou de l’API RDS. 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).
## Programme de rétention
Les fichiers journaux font l’objet d’une rotation chaque jour et chaque fois que votre instance de base de données est redémarrée. Voici le programme de rétention des journaux Microsoft SQL Server sur Amazon RDS.
****
| Log type (Type de journal) | Programme de rétention |
| --- | --- |
| Journaux des erreurs | Au maximum, 30 journaux d’erreurs sont conservés. Amazon RDS forrait supprimer les journaux d’erreurs datant de plus de 7 jours. |
| Journaux de l’agent | Au maximum, 10 journaux de l’agent sont conservés. Amazon RDS forrait supprimer les journaux de l’agent datant de plus de 7 jours. |
| Fichiers de trace | Les fichiers de trace sont conservés selon la période de rétention des fichiers de trace de votre instance de base de données. La période de rétention par défaut des fichiers de trace est de 7 jours. Pour modifier la période de rétention des fichiers de trace pour votre instance de base de données, consultez [Configuration de la période de rétention pour les fichiers de trace et de vidage](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
| Fichiers de vidage | Les fichiers de vidage sont conservés selon la période de rétention des fichiers de vidage de votre instance de base de données. La période de rétention par défaut des fichiers de vidage est de 7 jours. Pour modifier la période de rétention des fichiers de vidage pour votre instance de base de données, consultez [Configuration de la période de rétention pour les fichiers de trace et de vidage](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
## Affichage du journal des erreurs SQL Server à l’aide de la procédure rds\$1read\$1error\$1log
Vous pouvez utiliser la procédure stockée Amazon RDS `rds_read_error_log` pour afficher les journaux des erreurs et les journaux de l’agent. Pour de plus amples informations, veuillez consulter [Affichage des journaux des erreurs et des agents](Appendix.SQLServer.CommonDBATasks.Logs.md#Appendix.SQLServer.CommonDBATasks.Logs.SP).
## Publication des journaux SQL Server sur Amazon CloudWatch Logs
Avec Amazon RDS for SQL Server, vous pouvez publier les erreurs et les événements du journal de l'agent directement sur CloudWatch Amazon Logs. Analysez les données du journal avec CloudWatch Logs, puis utilisez-les CloudWatch pour créer des alarmes et afficher les métriques.
Avec CloudWatch Logs, vous pouvez effectuer les opérations suivantes :
+ Stocker des journaux dans un espace de stockage hautement durable pour lequel vous définissez la période de rétention.
+ Chercher et filtrer les données de journaux.
+ Partager des données de journaux entre les comptes.
+ Exporter des journaux vers Amazon S3.
+ Diffusez des données vers Amazon OpenSearch Service.
+ Traiter des données de journaux en temps réel avec Amazon Kinesis Data Streams. Pour plus d'informations, consultez le *guide du développeur d'applications Working with Amazon Managed Service for Apache Flink for SQL CloudWatch * [Logs](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/cloudwatch-logs.html).
Amazon RDS publie chaque journal de base de données SQL Server sous la forme d’un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous publiez les journaux des agents et les journaux des erreurs, les données d’erreurs sont stockées dans un flux de journal des erreurs dans le groupe de journaux `/aws/rds/instance/my_instance.node1/error`, et les données de journaux des agents sont stockées dans le groupe de journaux `/aws/rds/instance/my_instance.node1/agent`.
Pour les instances de base de données multi-AZ, Amazon RDS publie le journal de base de données sous la forme de deux flux distincts dans le groupe de journaux. Par exemple, si vous publiez les journaux d’erreurs, les données d’erreurs sont stockées dans les flux de journaux d’erreurs `/aws/rds/instance/my_instance.node1/error` et `/aws/rds/instance/my_instance.node2/error` respectivement. Les flux de journaux ne changent pas lors d’un basculement et le flux de journaux d’erreurs de chaque nœud peut contenir les journaux d’erreurs issus de l’instance principale ou secondaire. Avec Multi-AZ, un flux de journaux est automatiquement créé pour que `/aws/rds/instance/my_instance/rds-events` stocke les données d’événements telles que les basculements d’instances de base de données.
**Note**
La publication des journaux SQL Server dans CloudWatch Logs n'est pas activée par défaut. La publication de fichiers de trace et de vidage n’est pas prise en charge. La publication des journaux SQL Server dans CloudWatch Logs est prise en charge dans toutes les régions.
### Console
**Pour publier les journaux de base de données SQL Server dans CloudWatch des journaux à partir du AWS Management 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 (Modifier)**.
1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.
Vous pouvez choisir **Journal de l’agent**, **Journal des erreurs**ou les deux.
1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.
### AWS CLI
Pour publier des journaux SQL Server, vous pouvez utiliser 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 SQL Server en utilisant les commandes 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-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)
**Example**
L'exemple suivant crée une instance de base de données SQL Server avec la publication CloudWatch des journaux activée. La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON qui peut inclure `error`, `agent` ou les deux.
Pour Linux, macOS ou Unix :
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--enable-cloudwatch-logs-exports '["error","agent"]' \
--db-instance-class db.m4.large \
--engine sqlserver-se
```
Pour Windows :
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--enable-cloudwatch-logs-exports "[\"error\",\"agent\"]" ^
--db-instance-class db.m4.large ^
--engine sqlserver-se
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).
**Example**
L'exemple suivant modifie une instance de base de données SQL Server existante pour publier des fichiers CloudWatch journaux dans 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 qui peut inclure `error`, `agent` ou les deux.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["error","agent"]}'
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"EnableLogTypes\":[\"error\",\"agent\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).
**Example**
L'exemple suivant modifie une instance de base de données SQL Server existante pour désactiver la publication des fichiers journaux de l'agent dans CloudWatch Logs. La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `DisableLogTypes` et sa valeur est un tableau de chaînes qui peut inclure `error`, `agent` ou les deux.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["agent"]}'
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"agent\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).
# Fichiers journaux de base de données MySQL
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
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
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
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
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
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
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
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
**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
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
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
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
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
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
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
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
**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
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
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
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;
```
# Fichiers journaux de base de données Amazon RDS for Oracle
Vous pouvez accéder aux journaux des alertes, aux fichiers d’audits et aux fichiers de trace Oracle à l’aide de la console Amazon RDS ou de l’API. 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).
Les fichiers d’audit Oracle fournis sont les fichiers d’audit Oracle standard. Amazon RDS prend en charge la fonction d’audit fin (FGA) Oracle. Cependant, l’accès aux journaux ne donne pas accès aux événements FGA stockés dans la table `SYS.FGA_LOG$`, accessibles via la vue `DBA_FGA_AUDIT_TRAIL`.
L’opération de l’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) qui répertorie les fichiers journaux Oracle disponibles pour une instance de base de données ignore le paramètre `MaxRecords` et renvoie jusqu’à 1 000 enregistrements. L’appel renvoie `LastWritten` sous la forme d’une date POSIX en millisecondes.
**Topics**
+ [Programme de rétention](#USER_LogAccess.Concepts.Oracle.Retention)
+ [Utilisation des fichiers de trace Oracle](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles)
+ [Publication de journaux Oracle sur Amazon CloudWatch Logs](#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)
+ [Accès aux journaux des alertes et aux journaux de l’écouteur](#USER_LogAccess.Concepts.Oracle.AlertLogAndListenerLog)
## Programme de rétention
Le moteur de base de données Oracle peut procéder à la rotation des fichiers journaux s’ils deviennent très volumineux. Pour conserver les fichiers d’audit ou de trace, vous devez les télécharger. Si vous stockez les fichiers localement, vous réduisez vos coûts de stockage Amazon RDS et libérez plus d’espace pour vos données.
Le tableau suivant présente le programme de rétention des journaux d’alertes, des fichiers d’audit et des fichiers de trace Oracle sur Amazon RDS.
****
| Log type (Type de journal) | Programme de rétention |
| --- | --- |
| Journaux des alertes | Le journal d’alerte de texte fait l’objet d’une rotation quotidienne avec une rétention de 30 jours gérée par Amazon RDS. Le journal d’alerte XML est conservé au moins 7 jours. Vous pouvez accéder à ce journal grâce à la vue `ALERTLOG`. |
| Fichiers d’audit | La période de rétention par défaut des fichiers d’audit est de 7 jours. Amazon RDS forrait supprimer des fichiers d’audit datant de plus de sept jours. |
| Fichiers de trace | La période de rétention par défaut des fichiers de trace est de 7 jours. Amazon RDS forrait supprimer des fichiers de trace datant de plus de sept jours. |
| Journaux de l’écouteur | La période de rétention par défaut pour les journaux d’écouteur est de 7 jours. Amazon RDS forrait supprimer les journaux d’écouteur datant de plus de 7 jours. |
**Note**
Les fichiers d’audit et les fichiers de trace partagent la même configuration de rétention.
## Utilisation des fichiers de trace Oracle
Vous trouverez ci-après de descriptions de procédures Amazon RDS permettant de créer, d’actualiser, de supprimer les fichiers de trace ou d’y accéder.
**Topics**
+ [Liste de fichiers](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)
+ [Génération de fichiers de trace et suivi d’une session](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Generating)
+ [Récupération de fichiers de trace](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Retrieving)
+ [Purge des fichiers de trace](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Purging)
### Liste de fichiers
Vous pouvez utiliser l’une ou l’autre de deux procédures permettent d’accéder à tous les fichiers dans le chemin `background_dump_dest`. La première actualise la liste de l’ensemble des fichiers actuellement dans `background_dump_dest`.
```
1. EXEC rdsadmin.manage_tracefiles.refresh_tracefile_listing;
```
Une fois la liste actualisée, interrogez la vue suivante pour accéder aux résultats.
```
1. SELECT * FROM rdsadmin.tracefile_listing;
```
Vous pouvez également utiliser `FROM table` pour diffuser des données non relationnelles dans un format de table afin de répertorier le contenu de l’annuaire de bases de données.
```
1. SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('BDUMP'));
```
La requête suivante affiche le texte d’un fichier journal.
```
1. SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP','alert_dbname.log.date'));
```
Sur un réplica en lecture, obtenez le nom du répertoire BDUMP en interrogeant `V$DATABASE.DB_UNIQUE_NAME`. Si le nom unique est `DATABASE_B`, le répertoire BDUMP est `BDUMP_B`. L’exemple suivant interroge le nom BDUMP sur un réplica, puis utilise ce nom pour interroger le contenu de `alert_DATABASE.log.2020-06-23`.
```
1. SELECT 'BDUMP' || (SELECT regexp_replace(DB_UNIQUE_NAME,'.*(_[A-Z])', '\1') FROM V$DATABASE) AS BDUMP_VARIABLE FROM DUAL;
2.
3. BDUMP_VARIABLE
4. --------------
5. BDUMP_B
6.
7. SELECT TEXT FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP_B','alert_DATABASE.log.2020-06-23'));
```
### Génération de fichiers de trace et suivi d’une session
Puisqu’il n’existe aucune restriction sur `ALTER SESSION`, un grand nombre de méthodes standard permettant de générer des fichiers de trace dans Oracle restent disponibles pour les instances de base de données Amazon RDS. Les procédures suivantes sont fournies pour les fichiers de trace pour lesquels l’accès doit être élargi.
****
| Méthode Oracle | Méthode Amazon RDS |
| --- | --- |
| `oradebug hanganalyze 3 ` | `EXEC rdsadmin.manage_tracefiles.hanganalyze; ` |
| `oradebug dump systemstate 266 ` | `EXEC rdsadmin.manage_tracefiles.dump_systemstate;` |
Vous pouvez utiliser de nombreuses méthodes standard pour suivre des sessions individuelles connectées à une instance de base de données Oracle dans Amazon RDS. Pour activer le suivi d'une session, vous pouvez exécuter des sous-programmes dans des PL/SQL packages fournis par Oracle, tels que `DBMS_SESSION` et`DBMS_MONITOR`. Pour plus d’informations, consultez [Activation du suivi d’une session](https://docs.oracle.com/database/121/TGSQL/tgsql_trace.htm#GUID-F872D6F9-E015-481F-80F6-8A7036A6AD29) dans la documentation d’Oracle.
### Récupération de fichiers de trace
Vous pouvez récupérer tous les fichiers dans `background_dump_dest` à l’aide d’une requête SQL standard sur un tableau Amazon RDS externe gérée. Pour utiliser cette méthode, vous devez exécuter la procédure définissant l’emplacement de cette table sur le fichier de trace spécifique.
Par exemple, vous pouvez utiliser la vue `rdsadmin.tracefile_listing` indiquée ci-dessus pour répertorier tous les fichiers de trace sur le système. Vous pouvez ensuite définir la vue `tracefile_table` afin qu’elle pointe vers le fichier de trace souhaité à l’aide de la procédure suivante.
```
1. EXEC rdsadmin.manage_tracefiles.set_tracefile_table_location('CUST01_ora_3260_SYSTEMSTATE.trc');
```
L’exemple suivant créé une table externe selon le schéma actuel. L’emplacement est défini sur le fichier fourni. Vous pouvez récupérer le contenu dans un fichier local à l’aide d’une requête SQL.
```
1. SPOOL /tmp/tracefile.txt
2. SELECT * FROM tracefile_table;
3. SPOOL OFF;
```
### Purge des fichiers de trace
Les fichiers de trace peuvent s’accumuler et consommer de l’espace sur le disque. Par défaut, Amazon RDS purge les fichiers de trace et les fichiers journaux de plus de sept jours. Vous pouvez afficher et définir la période de rétention des fichiers à l’aide de la procédure `show_configuration`. Vous devez exécuter la commande `SET SERVEROUTPUT ON` afin de pouvoir afficher les résultats de la configuration.
L’exemple suivant affiche la période de rétention des fichiers de trace actuelle, puis définit une nouvelle période.
```
1. # Show the current tracefile retention
2. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
3. NAME:tracefile retention
4. VALUE:10080
5. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
6.
7. # Set the tracefile retention to 24 hours:
8. SQL> EXEC rdsadmin.rdsadmin_util.set_configuration('tracefile retention',1440);
9. SQL> commit;
10.
11. #show the new tracefile retention
12. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
13. NAME:tracefile retention
14. VALUE:1440
15. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
```
En complément du processus de purge périodique, vous pouvez supprimer manuellement des fichiers de `background_dump_dest`. L’exemple suivant montre comment purger tous les fichiers datant de plus de cinq minutes.
```
EXEC rdsadmin.manage_tracefiles.purge_tracefiles(5);
```
Vous pouvez également purger tous les fichiers correspondant à un modèle spécifique (dans ce cas, n’incluez pas l’extension de fichier, par exemple .trc). L’exemple suivant montre comment purger tous les fichiers commençant par `SCHPOC1_ora_5935`.
```
1. EXEC rdsadmin.manage_tracefiles.purge_tracefiles('SCHPOC1_ora_5935');
```
## Publication de journaux Oracle sur Amazon CloudWatch Logs
Vous pouvez configurer votre instance de base de données RDS pour Oracle afin de publier les données de journal dans un groupe de CloudWatch journaux dans Amazon Logs. Avec CloudWatch Logs, vous pouvez analyser les données du journal et 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 Oracle 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 d’audit, les données d’audit sont stockées dans un flux de journal d’audit dans le groupe de journaux `/aws/rds/instance/my_instance/audit`. Le tableau suivant récapitule les conditions requises pour que RDS for Oracle publie des journaux sur Amazon CloudWatch Logs.
| Nom du journal | Exigence | Par défaut |
| --- | --- | --- |
| Journal des alertes | Aucune. Vous ne pouvez pas désactiver ce journal. | Activé |
| Journal de suivi | Définissez le paramètre `trace_enabled` sur `TRUE` ou laissez-le tel que défini par défaut. | `TRUE` |
| Journal d’audit | Définissez le paramètre `audit_trail` sur l’une des valeurs autorisées suivantes : { none | os | db [, extended] | xml [, extended] } | `none` |
| Journal d’écoute | Aucune. Vous ne pouvez pas désactiver ce journal. | Activé |
| Journal d’Oracle Management Agent | Aucune. Vous ne pouvez pas désactiver ce journal. | Activé |
Le journal d’Oracle Management Agent contient les groupes de journaux présentés dans le tableau suivant.
****
| Nom du journal | CloudWatch groupe de journaux |
| --- | --- |
| emctl.log | oemagent-emctl |
| emdctlj.log | oemagent-emdctlj |
| gcagent.log | oemagent-gcagent |
| gcagent\$1errors.log | oemagent-gcagent-errors |
| emagent.nohup | oemagent-emagent-nohup |
| secure.log | oemagent-secure |
Pour plus d’informations, consultez [Localisation des fichiers de suivi et des fichiers journaux de Management Agent](https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emadm/locating-management-agent-log-and-trace-files1.html#GUID-9C710D78-6AA4-42E4-83CD-47B5FF4892DF) dans la documentation Oracle.
### Console
**Pour publier les journaux Oracle DB dans CloudWatch Logs à partir du AWS Management 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 (Modifier)**.
1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.
1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.
### AWS CLI
Pour publier les journaux Oracle vous pouvez utiliser 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 Oracle en utilisant les commandes 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)
**Example**
L'exemple suivant crée une instance de base de données Oracle avec la publication CloudWatch des journaux activée. La valeur `--cloudwatch-logs-export-configuration` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison de `alert`, `audit`, `listener` et `trace`.
Pour Linux, macOS ou Unix :
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '["trace","audit","alert","listener","oemagent"]' \
--db-instance-class db.m5.large \
--allocated-storage 20 \
--engine oracle-ee \
--engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 \
--license-model bring-your-own-license \
--master-username myadmin \
--manage-master-user-password
```
Pour Windows :
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration trace alert audit listener oemagent ^
--db-instance-class db.m5.large ^
--allocated-storage 20 ^
--engine oracle-ee ^
--engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 ^
--license-model bring-your-own-license ^
--master-username myadmin ^
--manage-master-user-password
```
**Example**
L'exemple suivant modifie une instance de base de données Oracle existante pour publier des fichiers CloudWatch journaux dans 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 `alert`, `audit`, `listener` et `trace`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["trace","alert","audit","listener","oemagent"]}'
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration EnableLogTypes=\"trace\",\"alert\",\"audit\",\"listener\",\"oemagent\"
```
**Example**
L'exemple suivant modifie une instance de base de données Oracle existante pour désactiver la publication des fichiers journaux d'audit et d'écoute dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `DisableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `alert`, `audit`, `listener` et `trace`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit","listener"]}'
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration DisableLogTypes=\"audit\",\"listener\"
```
### API RDS
Vous pouvez publier des journaux Oracle Database 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 Oracle en appelant les opérations de l’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 l’opération RDS que vous exécutez.
## Accès aux journaux des alertes et aux journaux de l’écouteur
Vous pouvez consulter le journal d’alertes à l’aide de la console Amazon RDS. Vous pouvez aussi utiliser l’instruction SQL suivante.
```
1. SELECT message_text FROM alertlog;
```
Accédez au journal de l'écouteur à l'aide d'Amazon CloudWatch Logs.
**Note**
Oracle procède à la rotation des journaux des alertes et de l’écouteur lorsqu’ils dépassent 10 Mo. A ce moment là, ils ne sont pas disponibles dans les vues Amazon RDS.
# Fichiers journaux de base de données RDS pour PostgreSQL
Vous pouvez surveiller les types de fichiers journaux suivants :
+ Journal PostgreSQL
+ Journal de mise à niveau
+ Journal des erreurs d’authentification de base de données IAM
**Note**
Pour activer les journaux d’erreurs d’authentification de base de données IAM, vous devez d’abord activer l’authentification de base de données IAM pour votre instance de base de données RDS pour PostgreSQL. Pour plus d’informations sur l’authentification de la base de données IAM, consultez [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
RDS pour PostgreSQL consigne les activités de base de données dans le fichier journal PostgreSQL par défaut. Pour une instance de base de données PostgreSQL sur site, ces messages sont stockés localement dans `log/postgresql.log`. Pour une instance de base de données RDS pour PostgreSQL, le fichier journal est disponible sur l’instance Amazon RDS. Ces journaux sont également accessibles via le AWS Management Console, où vous pouvez les consulter ou les télécharger. Le niveau de journalisation par défaut capture les échecs de connexion, les erreurs de serveur fatales, les blocages et les échecs de requête.
Pour plus d’informations sur l’affichage, le téléchargement et la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md). Pour en savoir plus sur les journaux PostgreSQL, consultez la section [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 1)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) et [Working with Amazon RDS and Aurora PostgreSQL logs: Part 2 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 2)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/).
Outre les journaux PostgreSQL standard décrits dans cette rubrique, RDS pour PostgreSQL prend également en charge l’extension PostgreSQL Audit (`pgAudit`). La plupart des secteurs réglementés et des agences gouvernementales doivent conserver un journal d’audit ou une piste d’audit des modifications apportées aux données afin de se conformer aux exigences légales. Pour plus d’informations sur l’installation et l’utilisation de pgAudit, consultez [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
**Topics**
+ [Paramètres de journalisation dans RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
+ [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)
# Paramètres de journalisation dans RDS pour PostgreSQL
Vous pouvez personnaliser le comportement de journalisation de votre instance de base de données RDS pour PostgreSQL en modifiant divers paramètres. Dans le tableau suivant, vous trouverez les paramètres qui affectent combien de temps les journaux sont stockés, quand effectuer la rotation du journal et s’il convient de fournir en sortie le journal au format CSV (valeurs séparées par des virgules). Vous pouvez également trouver le texte de sortie envoyé à STDERR, entre autres paramètres. Pour modifier les valeurs des paramètres modifiables, utilisez un groupe de paramètres de base de données pour votre Instance RDS pour PostgreSQL. Pour plus d’informations, consultez [Groupes de paramètres de base de données pour les instances de base de données Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
| Paramètre | Par défaut | Description |
| --- | --- | --- |
| log\$1destination | stderr | Définit le format de sortie pour le journal. La valeur par défaut est `stderr`, mais vous pouvez également spécifier une valeur séparée par des virgules (CSV) en ajoutant `csvlog` au paramètre. Pour plus d’informations, consultez [Définition de la destination du journal (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H | Spécifie le modèle du nom de fichier journal. Outre la valeur par défaut, ce paramètre prend en charge `postgresql.log.%Y-%m-%d` et `postgresql.log.%Y-%m-%d-%H%M` pour le modèle de nom de fichier. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Définit le préfixe pour chaque ligne de journal qui est écrite sur `stderr`, afin de noter l’heure (%t), l’hôte distant (%r), l’utilisateur (%u), la base de données (%d) et l’ID du processus (%p). |
| log\$1rotation\$1age | 60 | Minutes après lesquelles la rotation automatique du fichier journal est effectuée. Vous pouvez remplacer cette valeur par toute valeur comprise entre 1 et 1 440 minutes. Pour plus d’informations, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | Taille (en Ko) à laquelle la rotation automatique du fichier journal est effectuée. Par défaut, ce paramètre n’est pas utilisé, car une rotation des journaux est effectuée en fonction du paramètre `log_rotation_age`. Pour en savoir plus, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | Les journaux PostgreSQL plus anciens que le nombre de minutes spécifié sont supprimés. La valeur par défaut de 4 320 minutes supprime les fichiers journaux après trois jours. Pour plus d’informations, consultez [Définition de la période de conservation des journaux](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Pour identifier les problèmes d’application, vous pouvez rechercher dans le journal les échecs de requête, les échecs de connexion, les interblocages et les erreurs fatales du serveur. Par exemple, supposons que vous avez converti une application héritée d’Oracle vers Amazon RDS pour PostgreSQL, mais que certaines requêtes n’ont pas été converties correctement. Ces requêtes mal formatées génèrent des messages d’erreur que vous pouvez trouver dans les journaux pour aider à identifier les problèmes. Pour plus d’informations sur la journalisation des requêtes, consultez [Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
Dans les rubriques suivantes, vous pouvez trouver des informations sur la manière de définir les différents paramètres qui contrôlent les détails de base de vos journaux PostgreSQL.
**Topics**
+ [Définition de la période de conservation des journaux](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [Définition de la destination du journal (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [Compréhension du paramètre log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Définition de la période de conservation des journaux
Le paramètre `rds.log_retention_period` indique la durée pendant laquelle votre instance de base de données RDS pour PostgreSQL conserve ses fichiers journaux. La valeur par défaut est de 3 jours (4 320 minutes), mais vous pouvez définir une valeur comprise entre 1 jour (1 440 minutes) et 7 jours (10 080 minutes). Assurez-vous que votre instance de base de données RDS pour PostgreSQL dispose d’un espace de stockage suffisant pour contenir les fichiers journaux pendant cette période.
Nous vous recommandons de publier régulièrement vos CloudWatch journaux sur Amazon Logs afin de pouvoir consulter et analyser les données système longtemps après leur suppression de votre cluster de base de données . Instance de base de données RDS pour PostgreSQL. Pour plus d’informations, consultez [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
## Définition de la rotation des fichiers journaux
Amazon RDS crée de nouveaux fichiers journaux toutes les heures, par défaut. Le timing est contrôlé par le paramètre `log_rotation_age`. Ce paramètre a une valeur par défaut de 60 (minutes), mais vous pouvez le régler sur une valeur comprise entre 1 minute et 24 heures (1 440 minutes). Au moment de la rotation, un fichier journal distinct est créé. Le fichier est nommé selon le modèle spécifié par le paramètre `log_filename`.
Les fichiers journaux peuvent également faire l’objet d’une rotation en fonction de leur taille, comme indiqué dans le paramètre `log_rotation_size`. Ce paramètre indique que le journal doit faire l’objet d’une rotation lorsqu’il atteint la taille spécifiée (en kilo-octets). Pour une instance de base de données RDS pour PostgreSQL, la valeur `log_rotation_size` n’est pas définie, c’est-à-dire qu’il n’y a pas de valeur spécifiée. Toutefois, vous pouvez définir ce paramètre entre 0 et 2 097 151 Ko (kilo-octets).
Les noms de fichier journal sont basés sur le modèle de nom de fichier spécifié dans le paramètre `log_filename`. Les valeurs disponibles pour ce paramètre sont les suivantes :
+ `postgresql.log.%Y-%m-%d` : format par défaut du nom de fichier journal. Inclut l’année, le mois et la date dans le nom du fichier journal.
+ `postgresql.log.%Y-%m-%d-%H` : inclut l’heure dans le format du nom de fichier journal.
Pour plus d’informations, consultez [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) et [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) dans la documentation de PostgreSQL.
## Définition de la destination du journal (`stderr`, `csvlog`)
Par défaut, Amazon RDS PostgreSQL génère des journaux au format d’erreur standard (stderr). Ce format correspond au réglage par défaut du paramètre `log_destination`. Chaque message est préfixé selon le modèle spécifié dans le paramètre `log_line_prefix`. Pour plus d’informations, consultez [Compréhension du paramètre log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
RDS pour PostgreSQL peut également générer les journaux au format `csvlog`. La valeur `csvlog` permet d’analyser les données du journal en tant que données CSV (valeurs séparées par des virgules). Par exemple, supposons que vous utilisez l’extension `log_fdw` pour travailler avec vos journaux en tant que tables externes. La table externe créée sur les fichiers journaux `stderr` contient une seule colonne avec les données des événements de journal. En ajoutant `csvlog` au paramètre `log_destination`, vous obtenez le fichier journal au format CSV avec des démarcations pour les différentes colonnes de la table externe. Vous pouvez désormais trier et analyser vos journaux plus facilement. Pour savoir comment utiliser `log_fdw` avec `csvlog`, consultez [Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
Si vous spécifiez `csvlog` pour ce paramètre, sachez que les deux fichiers `stderr` et `csvlog` sont générés. Assurez-vous de surveiller le stockage consommé par les journaux, en tenant compte de `rds.log_retention_period` et des autres paramètres qui affectent le stockage et la rotation des journaux. Utiliser `stderr` et `csvlog` fait plus que doubler le stockage consommé par les journaux.
Si vous ajoutez `csvlog` à `log_destination` et que vous souhaitez revenir au paramètre `stderr` seul, vous devez réinitialiser le paramètre. Pour ce faire, ouvrez la console Amazon RDS, puis ouvrez le groupe de paramètres personnalisé de la base de données pour votre instance. Choisissez le paramètre `log_destination`, choisissez **Edit parameter** (Modifier le paramètre), puis **Reset** (Réinitialiser).
Pour plus d’informations sur la configuration de la journalisation, consultez [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Utiliser les journaux d’Amazon RDS et Aurora PostgreSQL : partie 1).
## Compréhension du paramètre log\$1line\$1prefix
Le format du journal `stderr` précède chaque message du journal des détails spécifiés par le paramètre `log_line_prefix`. La valeur par défaut est :
```
%t:%r:%u@%d:[%p]:t
```
À partir de la version 16 d’Aurora PostgreSQL, vous pouvez également choisir :
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Chaque entrée de journal envoyée à stderr inclut les informations suivantes en fonction de la valeur sélectionnée :
+ `%t` : heure de l’entrée du journal sans millisecondes
+ `%m` : heure de l’entrée du journal, en millisecondes
+ `%r` : adresse de l’hôte distant
+ `%u@%d` : nom d’utilisateur @ nom de base de données
+ `[%p]` : ID de processus si disponible
+ `%l` : numéro de ligne de journal par session
+ `%e` : code d’erreur SQL
+ `%s` : horodatage de début du processus
+ `%v` : identifiant de transaction virtuel
+ `%x` : ID de transaction
+ `%c` : ID de session
+ `%q` : délimiteur non session
+ `%a` : nom de l’application
# Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL
Vous pouvez collecter des informations plus détaillées sur les activités de votre base de données, notamment les requêtes, les requêtes en attente de verrouillage, les points de contrôle et de nombreux autres détails en définissant certains des paramètres répertoriés dans le tableau suivant. Cette rubrique se concentre sur la journalisation des requêtes.
| Paramètre | Par défaut | Description |
| --- | --- | --- |
| log\$1connections | – | Enregistre toutes les connexions réussies. |
| log\$1disconnections | – | Journalise la fin de chaque session et sa durée. |
| log\$1checkpoints | 1 | Enregistre chaque point de vérification. |
| log\$1lock\$1waits | – | Enregistre les longs temps d’attente pour l’acquisition d’un verrou. Ce paramètre n’est pas défini par défaut. |
| log\$1min\$1duration\$1sample | – | (ms) Définit la durée minimum d’exécution au-delà de laquelle les instructions sont journalisées. La taille de l’échantillon est définie à l’aide du paramètre log\$1statement\$1sample\$1rate. |
| log\$1min\$1duration\$1statement | – | Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées. |
| log\$1statement | – | Définit le type d’instructions enregistrées. Par défaut, ce paramètre n’est pas défini, mais vous pouvez le modifier pour `all`, `ddl` ou `mod` afin de spécifier les types d’instructions SQL que vous souhaitez journaliser. Si vous spécifiez autre chose que `none` pour ce paramètre, vous devez également prendre des mesures supplémentaires pour empêcher l’exposition des mots de passe dans les fichiers journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | Le pourcentage d’instructions dépassant la durée spécifiée dans `log_min_duration_sample` pour être journalisées, exprimé sous la forme d’une valeur à virgule flottante comprise entre 0,0 et 1,0. |
| log\$1statement\$1stats | – | Ecrit les statistiques de performance cumulées dans le journal du serveur. |
## Utilisation de la journalisation pour détecter les requêtes lentes
Vous pouvez journaliser les instructions et les requêtes SQL pour favoriser la recherche des requêtes lentes. Vous pouvez activer cette fonctionnalité en modifiant les valeurs des paramètres `log_statement` et `log_min_duration`, comme indiqué dans cette section. Avant d’activer la journalisation des requêtes pour votre instance de base de données RDS pour PostgreSQL, vous devez être conscient de l’exposition possible à des mots de passe dans les journaux et de la manière d’atténuer les risques. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
Vous trouverez ci-dessous des informations de référence sur les paramètres `log_statement` et `log_min_duration`.log\$1statement
Ce paramètre indique le type d’instructions SQL qui doivent être envoyées au journal. La valeur par défaut est `none`. Si vous remplacez ce paramètre par `all`, `ddl` ou `mod`, veillez à prendre les mesures recommandées pour réduire le risque d’exposition des mots de passe dans les journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**tout**
Journalise toutes les instructions. Ce paramètre est recommandé à des fins de débogage.
**ddl**
Journalise toutes les instructions DDL (Data Definition Language), telles que CREATE, ALTER, DROP, etc.
**mod**
Journalise toutes les instructions DDL et les instructions de langage de manipulation des données (DML) telles que INSERT, UPDATE et DELETE, qui modifient les données.
**Aucune**
Aucune instruction SQL n’est journalisée. Nous recommandons ce paramètre pour éviter le risque d’exposer des mots de passe dans les journaux.log\$1min\$1duration\$1statement
Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées.
**–1–2147483647**
Le nombre de millisecondes (ms) d’exécution pendant lequel une instruction est journalisée.
**Configurer la journalisation des requêtes**
Ces étapes supposent que votre L’instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres de base de données personnalisé.
1. Définissez le paramètre `log_statement` sur `all`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` avec cette définition de paramètre.
```
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats:
! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed
! [0.025146 s user, 0.000000 s system total]
! 36644 kB max resident size
! 0/8 [0/8] filesystem blocks in/out
! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 19/0 [27/0] voluntary/involuntary context switches
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC;
----------------------- END OF LOG ----------------------
```
1. Définissez le paramètre `log_min_duration_statement`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` lorsque le paramètre est défini sur `1`.
Les requêtes qui dépassent la durée spécifiée dans le paramètre `log_min_duration_statement` sont enregistrées. Vous en trouverez un exemple ci-dessous. Vous pouvez consulter le fichier journal de votre instance de base de données RDS pour PostgreSQL dans la console Amazon RDS.
```
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments;
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms
2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time
2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB
----------------------- END OF LOG ----------------------
```
### Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtes
Nous vous recommandons de garder `log_statement` sur `none` pour éviter de dévoiler les mots de passe. Si vous avez réglé `log_statement` sur `all`, `ddl` ou `mod`, nous vous recommandons de suivre une ou plusieurs des étapes suivantes.
+ Pour le client, chiffrez les informations sensibles. Pour plus d’informations, consultez [Options de chiffrement](https://www.postgresql.org/docs/current/encryption-options.html) dans la documentation PostgreSQL. Utilisez les options `ENCRYPTED` (et `UNENCRYPTED`) des instructions `CREATE` et `ALTER`. Pour plus d’informations, consultez [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) dans la documentation PostgreSQL.
+ Pour votre instance de base de données RDS pour PostgreSQL, configurez et utilisez l’extension PostgreSQL Auditing (pgAudit). Cette extension supprime les informations sensibles dans les instructions CREATE et ALTER envoyées au journal. Pour de plus amples informations, veuillez consulter [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Limitez l'accès aux CloudWatch journaux.
+ Utilisez des mécanismes d’authentification plus forts tels que IAM.
## Publication de journaux PostgreSQL sur Amazon Logs CloudWatch
Pour stocker vos enregistrements de journal PostgreSQL dans un espace de stockage hautement durable, vous pouvez utiliser Amazon Logs. CloudWatch Avec CloudWatch Logs, vous pouvez également effectuer une analyse en temps réel des données des journaux et les utiliser CloudWatch pour consulter les métriques et créer des alarmes. Par exemple, si vous définissez `log_statement` sur `ddl`, vous pouvez configurer une alarme pour vous alerter chaque fois qu’une instruction DDL est exécutée. Vous pouvez choisir de télécharger vos journaux PostgreSQL dans Logs pendant le processus de création CloudWatch de votre instance de base de données RDS pour PostgreSQL. Si vous avez choisi de ne pas télécharger de journaux à ce moment-là, vous pouvez modifier ultérieurement votre instance pour commencer à charger les journaux à partir de ce moment. En d’autres termes, les journaux existants ne sont pas chargés. Seuls les nouveaux journaux sont chargés lorsqu’ils sont créés sur votre instance de base de données RDS pour PostgreSQL modifiée.
Toutes les versions de RDS pour PostgreSQL actuellement disponibles prennent en charge la publication de fichiers journaux dans Logs. CloudWatch Pour plus d’informations, consultez [Mises à jour d’Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*.
Pour utiliser les CloudWatch journaux, configurez votre instance de base de données RDS pour PostgreSQL afin de publier les données des journaux dans un groupe de journaux.
Vous pouvez publier les types de CloudWatch journaux suivants dans Logs for RDS pour PostgreSQL :
+ Journal PostgreSQL
+ Journal de mise à niveau
+ Journal des erreurs d’authentification de base de données IAM
Une fois la configuration terminée, Amazon RDS publie les événements du journal dans les flux de journaux au sein d'un groupe de CloudWatch journaux. Par exemple, les données de journaux PostgreSQL sont stockés dans le groupe de journaux `/aws/rds/instance/my_instance/postgresql`. Pour consulter vos journaux, ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
### Console
**Pour publier les journaux PostgreSQL dans Logs CloudWatch à 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 **Databases (Bases de données)**.
1. Choisissez l’instance de base de données que vous souhaitez modifier, puis choisissez **Modifier**.
1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.
La section **Exportations de journaux** n'est disponible que pour les versions de PostgreSQL qui prennent en charge la publication dans Logs. CloudWatch
1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.
### AWS CLI
Vous pouvez publier des journaux PostgreSQL à l'aide du. 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 PostgreSQL en appelant les commandes de 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-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 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 CLI que vous exécutez.
**Example Modifier une instance pour publier des journaux dans CloudWatch Logs**
L'exemple suivant modifie une instance de base de données PostgreSQL existante pour publier des fichiers journaux dans Logs. CloudWatch 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 `postgresql` et `upgrade`.
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql", "upgrade"]}'
```
Pour Windows :
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}'
```
**Example Création d'une instance pour publier des journaux dans CloudWatch Logs**
L'exemple suivant crée une instance de base de données PostgreSQL et publie des fichiers journaux dans Logs. CloudWatch La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison quelconque de `postgresql` et `upgrade`.
Pour Linux, macOS ou Unix :
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \
4. --db-instance-class db.m4.large \
5. --engine postgres
```
Pour Windows :
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' ^
4. --db-instance-class db.m4.large ^
5. --engine postgres
```
### API RDS
Vous pouvez publier des journaux PostgreSQL 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 PostgreSQL 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_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 l’opération que vous exécutez.