^
--result-file=/tmp/binlog.txt
```
In der Regel bereinigt Amazon RDS ein binäres Protokoll so bald wie möglich. Allerdings muss das binäre Protokoll immer noch auf der Instance verfügbar sein, sodass mysqlbinlog darauf zugreifen kann. Verwenden Sie die gespeicherte Prozedur `mysql.rds_set_configuration`, um anzugeben, wie viele Stunden RDS die binären Protokolldateien aufbewahren soll. Geben Sie einen Zeitraum an, in dem Sie genügend Zeit haben, um die Protokolle herunterzuladen. Nachdem Sie den Aufbewahrungszeitraum festgelegt haben, überwachen Sie die Speichernutzung für die DB-Instance, um sicherzustellen, dass die aufbewahrten binären Protokolle nicht zu viel Speicherplatz beanspruchen.
Das folgende Beispiel setzt den Aufbewahrungszeitraum auf 1 Tag.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Verwenden Sie die gespeicherte Prozedur `mysql.rds_show_configuration`, um die aktuelle Einstellung anzeigen zu lassen.
```
call mysql.rds_show_configuration;
```
# Aktivieren der MariaDB-Binärprotokoll-Kommentierung
In einer MariaDB-DB-Instance können Sie das Ereignis `Annotate_rows` verwenden, um ein Zeilenereignis mit einer Kopie der SQL-Abfrage zu kommentieren, die das Zeilenereignis ausgelöst hat. Diese Methode bietet eine ähnliche Funktionalität wie das Aktivieren des Parameters `binlog_rows_query_log_events` für eine RDS-for-MySQL-DB-Instance.
Sie können Binärprotokoll-Anmerkungen global aktivieren, indem Sie eine benutzerdefinierte Parametergruppe erstellen und den Parameter `binlog_annotate_row_events` auf **1** setzen. Sie können Anmerkungen auch auf Sitzungsebene aktivieren, indem Sie aufrufe `SET SESSION binlog_annotate_row_events = 1`. Verwenden Sie `replicate_annotate_row_events`, um Binärprotokoll-Anmerkungen auf der Replika-Instance zu replizieren, falls binäre Protokollierung darauf aktiviert ist. Für die Nutzung dieser Einstellungen sind keine besonderen Berechtigungen erforderlich.
Nachfolgend sehen Sie ein Beispiel für eine zeilenbasierte Transaktion in MariaDB. Die Verwendung von zeilenbasierter Protokollierung wird ausgelöst, indem der Transaktionsisolationslevel auf "read-committed" eingestellt wird.
```
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;
```
Ohne Anmerkungen sehen die Einträge des Binärprotokolls für die Transaktion wie folgt aus:
```
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/*!*/;
```
Die folgende Anweisung aktiviert Anmerkungen auf Sitzungsebene für diese Transaktion und deaktiviert die Anmerkungen nach dem Übertragen der Transaktion:
```
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;
```
Mit Anmerkungen sehen die Einträge des Binärprotokolls für die Transaktion wie folgt aus:
```
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/*!*/;
```
# Datenbankprotokolldateien von Amazon RDS für Microsoft SQL Server
Sie können über die Amazon-RDS-Konsole, AWS CLI oder die RDS-API auf SQL-Server-Fehlerprotokolle, Agenten-Protokolle, Trace-Dateien und Dump-Dateien zugreifen. Weitere Informationen zum Anzeigen und Herunterladen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
## Aufbewahrungsplan
Protokolldateien werden jeden Tag rotiert und jedes Mal, wenn Ihre DB-Instance neu gestartet wird. Im Folgenden wird der Aufbewahrungsplan für Microsoft SQL Server-Protokolle in Amazon RDS gezeigt.
****
| Protokolltyp | Aufbewahrungsplan |
| --- | --- |
| Fehlerprotokolle | Es werden maximal 30 Fehlerprotokolle aufbewahrt. Amazon RDS löscht möglicherweise Fehlerprotokolle, die älter als 7 Tage sind. |
| Agent-Protokolle | Es werden maximal 10 Agent-Protokolle aufbewahrt. Amazon RDS löscht möglicherweise Agent-Protokolle, die älter als 7 Tage sind. |
| Trace-Dateien | Trace-Dateien werden entsprechend dem Aufbewahrungszeitraum Ihrer DB-Instance für Trace-Dateien aufbewahrt. Der Standardaufbewahrungszeitraum für Trace-Dateien beträgt 7 Tage. Informationen zum Ändern des Aufbewahrungszeitraums für Trace-Dateien für Ihre DB-Instance finden Sie unter [Festlegen des Aufbewahrungszeitraums für Trace- und Dump-Dateien](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
| Dump-Dateien | Dump-Dateien werden entsprechend dem Aufbewahrungszeitraum Ihrer DB-Instance für Dump-Dateien aufbewahrt. Der Standardaufbewahrungszeitraum für Dump-Dateien beträgt 7 Tage. Informationen zum Ändern des Aufbewahrungszeitraums für Dump-Dateien für Ihre DB-Instance finden Sie unter [Festlegen des Aufbewahrungszeitraums für Trace- und Dump-Dateien](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles). |
## Anzeigen des SQL Server-Fehlerprotokolls unter Verwendung der Prozedur rds\$1read\$1error\$1log
Sie können die gespeicherte Amazon-RDS-Prozedur `rds_read_error_log` verwenden, um Fehlerprotokolle und Agent-Protokolle anzuzeigen. Weitere Informationen finden Sie unter [Anzeigen von Fehler- und Agent-Protokollen](Appendix.SQLServer.CommonDBATasks.Logs.md#Appendix.SQLServer.CommonDBATasks.Logs.SP).
## Veröffentlichen von SQL Server-Protokollen in Amazon CloudWatch Logs
Mit Amazon RDS for SQL Server können Sie Fehler- und Agentenprotokollereignisse direkt in Amazon CloudWatch Logs veröffentlichen. Analysieren Sie die Protokolldaten mit CloudWatch Logs und verwenden Sie sie dann, CloudWatch um Alarme zu erstellen und Metriken anzuzeigen.
Mit CloudWatch Logs können Sie Folgendes tun:
+ Speichern von Protokollen in hoch dauerhaften Speichern mit einem von Ihnen festgelegten Aufbewahrungszeitraum.
+ Durchsuchen und Filtern von Protokolldaten
+ Protokolldateien zwischen Konten freigeben.
+ Exportieren von Protokollen zu Amazon S3.
+ Streamen Sie Daten an Amazon OpenSearch Service.
+ Verarbeiten von Protokolldaten in Echtzeit mit Amazon Kinesis Data Streams. Weitere Informationen finden Sie unter [Arbeiten mit Amazon CloudWatch Logs im Amazon](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/cloudwatch-logs.html) *Managed Service for Apache Flink for SQL Applications Developer Guide*.
Amazon RDS veröffentlicht jedes SQL Server-Datenbankprotokoll als separaten Datenbank-Stream in der Protokollgruppe. Wenn Sie beispielsweise die Agent- und Fehlerprotokolle veröffentlichen, werden die Fehlerdaten in einem Fehlerprotokollstream in der Protokollgruppe `/aws/rds/instance/my_instance.node1/error` und die Agent-Protokolldaten in der Protokollgruppe `/aws/rds/instance/my_instance.node1/agent` gespeichert.
Für Multi-AZ-DB-Instances veröffentlicht Amazon RDS das Datenbankprotokoll als zwei separate Streams in der Protokollgruppe. Wenn Sie zum Beispiel Fehlerprotokolle veröffentlichen, werden die Fehlerdaten in dem Fehlerprotokollstream `/aws/rds/instance/my_instance.node1/error` bzw. `/aws/rds/instance/my_instance.node2/error` gespeichert. Die Protokollstreams ändern sich während eines Failovers nicht und der Fehlerprotokollstream jedes Knotens kann Fehlerprotokolle von der primären oder sekundären Instance enthalten. Bei Multi-AZ wird für `/aws/rds/instance/my_instance/rds-events` automatisch ein Protokollstream erstellt, um Ereignisdaten wie DB-Instance-Failover zu speichern.
**Anmerkung**
Das Veröffentlichen von SQL CloudWatch Server-Protokollen in Logs ist standardmäßig nicht aktiviert. Die Veröffentlichung von Trace- und Dump-Dateien wird nicht unterstützt. Das Veröffentlichen von SQL Server-Protokollen in CloudWatch Logs wird in allen Regionen unterstützt.
### Konsole
**Um SQL Server-DB-Protokolle in Logs zu CloudWatch veröffentlichen, klicken Sie auf AWS-Managementkonsole**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** und dann die DB-Instance, die Sie ändern möchten.
1. Wählen Sie **Modify** aus.
1. Wählen Sie im Abschnitt **Protokollexporte** die Protokolle aus, die Sie in CloudWatch Logs veröffentlichen möchten.
Sie können **Agentenprotokoll**, **Fehlerprotokoll** oder beides wählen.
1. Wählen Sie **Weiter** und dann auf der zusammenfassenden Seite **Modify DB Instance** (DB-Instance ändern) aus.
### AWS CLI
Um SQL Server-Protokolle zu veröffentlichen, können Sie den Befehl [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) mit den folgenden Parametern verwenden:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**Anmerkung**
Eine Änderung der Option `--cloudwatch-logs-export-configuration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund sind die Optionen `--apply-immediately` und `--no-apply-immediately` wirkungslos.
Sie können SQL Server-Protokolle auch mit den folgenden Befehlen veröffentlichen:
+ [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**
Im folgenden Beispiel wird eine SQL Server-DB-Instance mit aktivierter CloudWatch Protokollveröffentlichung erstellt. Der `--enable-cloudwatch-logs-exports`-Wert ist ein JSON-Zeichenfolgenarray, der `error`, `agent` oder beide enthalten kann.
Für Linux, macOS oder 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
```
Für 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
```
Bei Verwendung der Windows-Befehlszeile müssen doppelte Anführungszeichen (") im JSON-Code mit einem umgekehrten Schrägstrich (\$1) als Escape-Zeichen versehen werden.
**Example**
Im folgenden Beispiel wird eine bestehende SQL Server-DB-Instance so geändert, dass Protokolldateien in CloudWatch Logs veröffentlicht werden. Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `EnableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit `error`, `agent` oder beiden.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["error","agent"]}'
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"EnableLogTypes\":[\"error\",\"agent\"]}"
```
Bei Verwendung der Windows-Befehlszeile müssen doppelte Anführungszeichen (") im JSON-Code mit einem umgekehrten Schrägstrich (\$1) als Escape-Zeichen versehen werden.
**Example**
Im folgenden Beispiel wird eine bestehende SQL Server-DB-Instance so geändert, dass das Veröffentlichen von Agent-Protokolldateien in Logs deaktiviert wird. CloudWatch Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `DisableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit `error`, `agent` oder beiden.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["agent"]}'
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"agent\"]}"
```
Bei Verwendung der Windows-Befehlszeile müssen doppelte Anführungszeichen (") im JSON-Code mit einem umgekehrten Schrägstrich (\$1) als Escape-Zeichen versehen werden.
# MySQL-Datenbank-Logdateien
Sie können die MySQL-Protokolle direkt über die Amazon RDS-Konsole, die Amazon RDS-API AWS CLI, oder überwachen AWS SDKs. Sie können auf MySQL-Protokolle auch direkt zugreifen, indem Sie die Protokolle in eine Datenbank-Tabelle in der Hauptdatenbank weiterleiten und diese Tabelle abfragen. Mit dem Dienstprogramm "mysqlbinlog" können Sie ein binäres Protokoll herunterladen.
Weitere Informationen zum Anzeigen und Herunterladen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
**Topics**
+ [
# Überblick über RDS-for-MySQL-Datenbankprotokolle
](USER_LogAccess.MySQL.LogFileSize.md)
+ [
# Veröffentlichen von MySQL-Protokollen in Amazon CloudWatch Logs
](USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.md)
+ [
# Senden der an Tabellen
](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [
# Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken
](USER_LogAccess.MySQL.BinaryFormat.md)
+ [
# Konfigurieren der MySQL-Binärprotokollierung für DB-Cluster mit Multi-AZ
](USER_Binlog.MultiAZ.md)
+ [
# Zugriff auf MySQL-Binärprotokolle
](USER_LogAccess.MySQL.Binarylog.md)
# Überblick über RDS-for-MySQL-Datenbankprotokolle
Sie können die folgenden Arten von RDS-for-MySQL-Protokolldateien überwachen:
+ Fehler-log
+ Slow-Query-Protokoll
+ Allgemeines Protokoll
+ Prüfungsprotokoll
+ Instance-Protokoll
+ Fehlerprotokoll zur IAM-Datenbankauthentifizierung
Das RDS-for-MySQL-Fehlerprotokoll wird standardmäßig generiert. Sie können die langsamen Abfrage- und allgemeinen Protokolle generieren, indem Sie Parameter in Ihrer DB-Parametergruppe festlegen.
**Topics**
+ [
## RDS-for-MySQL-Fehlerprotokolle
](#USER_LogAccess.MySQL.Errorlog)
+ [
## RDS-für-MySQL-Protokolle für langsame Abfragen und allgemeine Protokolle
](#USER_LogAccess.MySQL.Generallog)
+ [
## MySQL Audit-Protokoll
](#USER_LogAccess.MySQL.Auditlog)
+ [
## Protokollrotation und -aufbewahrung für RDS für MySQL
](#USER_LogAccess.MySQL.LogFileSize.retention)
+ [
## Größenbeschränkungen für Redo-Protokolle
](#USER_LogAccess.MySQL.LogFileSize.RedoLogs)
## RDS-for-MySQL-Fehlerprotokolle
RDS für MySQL schreibt Fehler in die `mysql-error.log`-Datei. An den Namen jeder Protokolldatei wird die Stunde ihrer Erstellung (in UTC) angefügt. Die Protokolldateien verfügen auch über einen Zeitstempel, anhand dessen Sie feststellen können, wann die Protokolleinträge geschrieben wurden.
RDS f0r MySQL schreibt das Fehlerprotokoll nur beim Startup, Herunterfahren und beim Auftreten von Fehlern. Eine DB-Instance kann Stunden oder Tage lang laufen, ohne dass neue Einträge in das Fehlerprotokoll geschrieben werden. Wenn Sie keine neuen Einträge sehen, sind im Server keine Fehler aufgetreten, die zu einem Eintrag in das Protokoll führen würden.
Konstruktionsbedingt werden die Fehlerprotokolle gefiltert, sodass nur unerwartete Ereignisse wie Fehler angezeigt werden. Die Fehlerprotokolle enthalten jedoch auch einige zusätzliche Datenbankinformationen, z. B. den Abfragefortschritt, die nicht angezeigt werden. Daher kann die Größe der Fehlerprotokolle auch ohne tatsächliche Fehler aufgrund laufender Datenbankaktivitäten zunehmen. Und obwohl Sie in den Fehlerprotokollen möglicherweise eine bestimmte Größe in Byte oder Kilobyte sehen AWS-Managementkonsole, haben sie möglicherweise 0 Byte, wenn Sie sie herunterladen.
RDS für MySQL schreibt `mysql-error.log` alle 5 Minuten auf die Festplatte. Es fügt den Inhalt des Protokolls `mysql-error-running.log` an.
RDS für MySQL rotiert die Datei `mysql-error-running.log` stündlich. Es behält die in den letzten zwei Wochen erzeugten Protokolle bei.
**Anmerkung**
Der Aufbewahrungszeitraum für das Protokoll ist zwischen Amazon RDS und unterschiedlich Aurora.
## RDS-für-MySQL-Protokolle für langsame Abfragen und allgemeine Protokolle
Das Slow-Query-Protokoll von RDS für MySQL und das allgemeine Protokoll können in eine Datei oder in eine Datenbanktabelle geschrieben werden. Legen Sie dazu die Parameter in Ihrer DB-Parametergruppe fest. Weitere Informationen zum Erstellen und Ändern einer DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Sie müssen diese Parameter festlegen, bevor Sie das Protokoll für langsame Abfragen oder das allgemeine Protokoll in der Amazon RDS-Konsole oder mithilfe der Amazon RDS-API, Amazon RDS-CLI oder anzeigen können AWS SDKs.
Sie können RDS-for-MySQL-Protokolle mithilfe der Parameter in dieser Liste kontrollieren:
+ `slow_query_log` Um das Slow-Query-Protokoll zu erstellen, auf 1 setzen. Der Standardwert ist 0.
+ `general_log` Um das allgemeine Protokoll zu erstellen, auf 1 setzen. Der Standardwert ist 0.
+ `long_query_time`: Damit vermieden wird, dass schnell ausgeführte Abfragen im Slow-Query-Protokoll aufgenommen werden, legen Sie die kürzeste Laufzeit für eine zu protokollierende Abfrage in Sekunden fest. Der Standardwert liegt bei 10 Sekunden, der Mindestwert bei 0. Wenn log\$1output = FILE, können Sie einen Gleitkommawert angeben, der die Mikrosekundenauflösung festlegt. Wenn log\$1output = TABLE, können Sie einen Ganzzahlwert angeben, der die Sekundenauflösung festlegt. Nur Abfragen, deren Laufzeit den `long_query_time`-Wert übersteigt, werden im Protokoll aufgenommen. Wenn Sie beispielsweise `long_query_time` auf 0,1 setzen, verhindert dies Einträge von allen Abfragen, die weniger als 100 Millisekunden lang ausgeführt werden.
+ `log_queries_not_using_indexes`: Um alle Abfragen, die keinen Index für das Slow-Query-Protokoll verwenden im Protokoll aufzunehmen, auf 1 setzen. Abfragen, die keinen Index verwenden, werden protokolliert, auch wenn ihre Laufzeit niedriger als der Wert des Parameters `long_query_time` ist. Der Standardwert ist 0.
+ `log_output option`: Sie können eine der folgenden Optionen für den `log_output`-Parameter festlegen.
+ **TABLE** (Standard)– schreibt allgemeine Abfragen in die `mysql.general_log`-Tabelle und langsame Abfragen in die `mysql.slow_log`-Tabelle.
+ **FILE**– schreibt Protokolle allgemeiner und langsamer Abfragen in das Dateisystem.
+ **NONE**– Die Protokollierung ist deaktiviert.
Damit langsame Abfragedaten in Amazon CloudWatch Logs angezeigt werden, müssen die folgenden Bedingungen erfüllt sein:
+ CloudWatch Protokolle müssen so konfiguriert sein, dass sie langsame Abfrageprotokolle enthalten.
+ `slow_query_log` muss aktiviert sein.
+ muss `log_output` auf `FILE` festgelegt sein.
+ Die Abfrage muss länger dauern als die für `long_query_time` konfigurierte Zeit.
Weitere Informationen zu den Slow-Query- und allgemeinen Protokollen finden Sie in den folgenden Themen in der MySQL-Dokumentation:
+ [Das Slow-Query-Protokoll](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [Das allgemeine Abfrageprotokoll](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)
## MySQL Audit-Protokoll
Für den Zugriff auf das Audit-Protokoll muss die DB-Instance eine benutzerdefinierte Optionsgruppe mit der Option `MARIADB_AUDIT_PLUGIN` verwenden. Weitere Informationen finden Sie unter [MariaDB-Audit-Plugin-Support für MySQL](Appendix.MySQL.Options.AuditPlugin.md).
## Protokollrotation und -aufbewahrung für RDS für MySQL
Wenn Protokollierung aktiviert ist, rotiert Amazon RDS Tabellenprotokolle oder löscht Protokolldateien in regelmäßigen Intervallen. Dies ist eine Vorsichtsmaßnahme, um möglichst zu vermeiden, dass eine umfangreiche Protokolldatei die Datenbanknutzung blockiert oder die Leistung beeinträchtigt. RDS für MySQL behandelt Rotation und Löschen wie folgt:
+ Die MySQL-Slow-Query-Protokolldatei, Fehlerprotokolldatei und allgemeine Protokolldatei sind auf eine Größe beschränkt, die 2 % des zugewiesenen Speicherplatzes für eine DB-Instance nicht überschreiten darf. Um diesen Schwellenwert einzuhalten, werden die Protokolle automatisch stündlich gedreht. MySQL entfernt Protokolldateien, die älter als zwei Wochen sind. Wenn die kombinierte Größe der Protokolle nach dem Löschen von alten Protokolldateien den Schwellwert überschreitet, werden die ältesten Protokolldateien gelöscht, bis die Größe den Schwellwert nicht mehr überschreitet.
+ Wenn die `FILE`-Protokollierung aktiviert ist, werden Protokolldateien stündlich untersucht und Protokolldateien, die älter als zwei Wochen sind, werden gelöscht. In einigen Fällen kann die Größe der verbleibenden kombinierten Protokolldatei nach dem Löschen die Schwelle von 2 % des zugeteilten Speicherplatzes für eine DB-Instance überschreiten. In diesen Fällen werden die ältesten Protokolldateien gelöscht, bis die Größe den Schwellenwert nicht mehr überschreitet.
+ Wenn die `TABLE`-Protokollierung aktiviert ist, werden in einigen Fällen Protokolltabellen alle 24 Stunden überschrieben. Diese Rotation erfolgt, wenn der von den Tabellenprotokollen verwendete Speicherplatz mehr als 20 Prozent des zugeteilten Speicherplatzes ausmacht. Sie tritt auch auf, wenn die Größe aller kombinierten Protokolle mehr als 10 GB beträgt. Wenn der für eine DB-Instance verwendete Speicherplatz 90 Prozent des Speicherplatzes überschreitet, der der DB-Instance zugeteilt ist, werden die Schwellen für die Protokollrotation reduziert. Protokolltabellen werden dann rotiert, wenn der von den Tabellenprotokollen verwendete Speicherplatz mehr als 10 Prozent des zugeteilten Speicherplatzes ausmacht. Sie werden auch rotiert, wenn die Größe aller kombinierten Protokolle mehr als 5 GB beträgt. Sie können die Ereigniskategorie `low storage` abonnieren, um Benachrichtigungen zu erhalten, wenn Protokolltabellen rotiert werden, um Speicherplatz freizugeben. Weitere Informationen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
Wenn Protokolltabellen rotiert werden, wird die aktuelle Protokolltabelle zuerst in eine Backup-Protokolltabelle kopiert. Dann werden die Einträge aus der aktuellen Protokolltabelle entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle ins Backup kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.general_log`-Tabelle ist als `mysql.general_log_backup` benannt. Die Backup-Protokolltabelle für die `mysql.slow_log`-Tabelle ist als `mysql.slow_log_backup` benannt.
Sie können die `mysql.general_log`-Tabelle rotieren, wenn Sie die Prozedur `mysql.rds_rotate_general_log` aufrufen. Sie können die `mysql.slow_log`-Tabelle rotieren, wenn Sie die Prozedur `mysql.rds_rotate_slow_log` aufrufen.
Tabellenprotokolle werden während des Upgrades einer Datenbankversion rotiert.
Um mit den Protokollen von der Amazon RDS-Konsole, der Amazon RDS-API, der Amazon RDS-CLI oder zu arbeiten AWS SDKs, setzen Sie den `log_output` Parameter auf FILE. So wie das MySQL-Fehlerprotokoll, werden diese Protokolldateien stündlich rotiert. Die Protokolldateien, die in den letzten zwei Wochen generiert wurden, werden aufbewahrt. Beachten Sie, dass der Aufbewahrungszeitraum bei Amazon RDS und Aurora jeweils unterschiedlich ist.
## Größenbeschränkungen für Redo-Protokolle
Bei RDS für MySQL Version 8.0.32 beträgt der Standardwert dieses Parameters 256 MB. Dieser Betrag wird abgeleitet, indem der Standardwert des Parameters `innodb_log_file_size` (128 MB) mit dem Standardwert des Parameters `innodb_log_files_in_group` (2) multipliziert wird. Weitere Informationen finden Sie unter [Best practices for configuring parameters for Amazon RDS für 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/).
Bei Version 8.0.33 von RDS für MySQL und höher wird der `innodb_redo_log_capacity`-Parameter anstelle des `innodb_log_file_size`-Parameters verwendet. Der Amazon-RDS-Standardwert für den Parameter `innodb_redo_log_capacity` ist 2 GB. Weitere Informationen finden Sie unter [Änderungen in MySQL 8.0.30](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html) in der MySQL-Dokumentation.
Ab MySQL 8.4 aktiviert Amazon RDS den Parameter `innodb_dedicated_server` standardmäßig. Mit dem Parameter `innodb_dedicated_server` berechnet die Datenbank-Engine die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity`. Weitere Informationen finden Sie unter [Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md).
# Veröffentlichen von MySQL-Protokollen in Amazon CloudWatch Logs
Sie können die MySQL-DB-Instance so konfigurieren, dass Protokolldaten in einer Protokollgruppe in Amazon CloudWatch Logs veröffentlicht werden. Mit CloudWatch Logs können Sie Echtzeitanalysen der Protokolldaten durchführen, und mit CloudWatch können Sie Alarme und Metriken erstellen. Sie können CloudWatch Logs verwenden, um Ihre Protokolldatensätze in einem Speicher mit hoher Beständigkeit abzulegen.
Amazon RDS veröffentlicht jedes MySQL-Datenbankprotokoll als separaten Datenbank-Stream in der Protokollgruppe. Wenn Sie beispielsweise die Exportfunktion so konfigurieren, dass das Slow-Query-Protokoll berücksichtigt wird, werden Slow-Query-Daten in einem Slow-Query-Protokollstream in der Protokollgruppe `/aws/rds/instance/my_instance/slowquery` gespeichert.
Das Fehlerprotokoll ist standardmäßig aktiviert. Die folgende Tabelle fasst die Anforderungen für die anderen MySQL-Protokolle zusammen.
| Protokoll | Anforderung |
| --- | --- |
| Prüfungsprotokoll | Die DB-Instance muss eine benutzerdefinierte Optionsgruppe mit der Option `MARIADB_AUDIT_PLUGIN` verwenden. |
| Allgemeines Protokoll | Die DB-Instance muss eine benutzerdefinierte Parametergruppe mit der Parametereinstellung `general_log = 1` verwenden, um das allgemeine Protokoll zu aktivieren. |
| Slow-Query-Protokoll | Die DB-Instance muss eine benutzerdefinierte Parametergruppe mit der Parametereinstellung `slow_query_log = 1` verwenden, um das Slow-Query-Protokoll zu aktivieren. |
| Fehlerprotokoll zur IAM-Datenbankauthentifizierung | Sie müssen den Protokolltyp `iam-db-auth-error` für eine DB-Instance aktivieren, indem Sie eine DB-Instance erstellen oder ändern. |
| Protokollausgabe | Die DB-Instance muss eine benutzerdefinierte Parametergruppe mit der Parametereinstellung `log_output = FILE` verwenden, um Protokolle in das Dateisystem zu schreiben und sie in CloudWatch Logs zu veröffentlichen. |
## Konsole
**So veröffentlichen Sie MySQL-Protokolle in CloudWatch Logs über die Konsole**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** und dann die DB-Instance, die Sie ändern möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie im Bereich **Protokollexporte** die Protokolle aus, die Sie in CloudWatch Logs veröffentlichen möchten.
1. Wählen Sie **Weiter** und dann auf der zusammenfassenden Seite **Modify DB Instance** (DB-Instance ändern) aus.
## AWS CLI
Sie können MySQL-Protokolle über veröffentliche AWS CLI. Sie können den Befehl [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) mit den folgenden Parametern aufrufen:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**Anmerkung**
Eine Änderung der Option `--cloudwatch-logs-export-configuration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund sind die Optionen `--apply-immediately` und `--no-apply-immediately` wirkungslos.
Sie können MySQL-Protokolle auch veröffentlichen, indem Sie die folgenden AWS CLI-Befehle aufrufen:
+ [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)
Führen Sie einen dieser AWS CLI-Befehle mit den folgenden Optionen aus:
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`
Je nach verwendetem AWS CLI-Befehl müssen möglicherweise noch weitere Optionen angegeben werden.
**Example**
Im folgenden Beispiel wird eine vorhandene MySQL-DB-Instance so konfiguriert, dass Protokolldateien in CloudWatch Logs veröffentlicht werden. Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `EnableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit einer beliebigen Kombination aus `audit`, `error`, `general` und `slowquery`.
Für Linux, macOS oder Unix:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
Für Windows:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
**Example**
Im folgenden Beispiel wird eine MySQL-DB-Instance erstellt und die Protokolldateien in CloudWatch Logs veröffentlicht. Der Wert `--enable-cloudwatch-logs-exports` ist ein JSON-Array mit Zeichenfolgen. Die Zeichenfolgen können eine beliebige Kombination von `audit`, `error`, `general` und `slowquery` sein.
Für Linux, macOS oder 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
```
Für 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
```
## RDS-API
Sie können MySQL-Protokolle über die RDS-API veröffentlichen. Die Aktion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) kann dazu mit den folgenden Parametern aufgerufen werden:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**Anmerkung**
Eine Änderung des Parameters `CloudwatchLogsExportConfiguration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund ist der Parameter `ApplyImmediately` wirkungslos.
Sie können MySQL-Protokolle auch veröffentlichen, indem Sie in der RDS-API die folgenden Operationen aufrufen:
+ [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)
Führen Sie eine dieser RDS-API-Operationen mit den folgenden Parametern aus:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Je nach ausgeführtem AWS CLI-Befehl müssen möglicherweise noch weitere Parameter angegeben werden.
# Senden der an Tabellen
Sie können die allgemeinen und Slow-Query-Protokolle an Tabellen in der DB-Instance weiterleiten, indem Sie eine DB-Parametergruppe erstellen und den `log_output`-Serverparameter auf `TABLE` setzen. Allgemeine Abfragen werden anschließend in der `mysql.general_log`-Tabelle und Slow-Queries in der`mysql.slow_log`-Tabelle protokolliert. Sie können die Tabellen abfragen, um auf Protokollinformationen zuzugreifen. Durch Aktivieren dieser Protokollierung wird die Datenmenge erhöht, die in die Datenbank geschrieben wird, was die Performance beeinträchtigen kann.
Das allgemeine Protokoll und das Slow-Query-Protokoll sind standardmäßig deaktiviert. Um die Protokollierung in Tabellen zu aktivieren, müssen Sie auch die Serverparameter `general_log` und `slow_query_log` auf `1` setzen.
Protokolltabellen wachsen stetig, bis die entsprechenden Protokollierungsaktivitäten ausgeschaltet werden, indem der entsprechende Parameter auf gesetzt wir `0`. Mit der Zeit sammelt sich häufig eine große Datenmenge an und belegt einen beträchtlichen Anteil Ihres zugeteilten Speicherplatzes. Amazon RDS erlaubt Ihnen nicht, die Protokolltabellen zu kürzen, aber Sie können ihre Inhalte verschieben. Beim Rotieren einer Tabelle wird deren Inhalt in einer Sicherungstabelle gespeichert, und anschließend wird eine neue leere Protokolldatei angelegt. Sie können Protokolltabellen mithilfe der folgenden Befehlszeilenprozeduren manuell rotieren, wobei die Eingabeaufforderung mit bezeichnet is `PROMPT>`:
```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```
Um alte Daten komplett zu entfernen und den Speicherplatz zurückzugewinnen, rufen Sie die entsprechende Prozedur zweimal nacheinander auf.
# Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken
Das *Binärprotokoll* ist eine Reihe von Protokolldateien, die Informationen zu Datenänderungen enthalten, die an einer MySQL-Server-Instance vorgenommen wurden. Das Binärprotokoll enthält Informationen wie die folgenden:
+ Ereignisse, die Datenbankänderungen wie Tabellenerstellungen oder Zeilenänderungen beschreiben
+ Informationen über die Dauer jeder Anweisung, durch die Daten aktualisiert wurden
+ Ereignisse für Anweisungen, durch die Daten aktualisieren werden hätten können, aber nicht wurden
Das binäre Protokoll zeichnet Anweisungen auf, die während der Replikation gesendet werden. Es ist auch für einige Wiederherstellungsvorgänge erforderlich. Weitere Informationen finden Sie unter [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) in der MySQL-Dokumentation.
Die Funktion für automatisierte Backups bestimmt, ob die binäre Protokollierung für MySQL ein- oder ausgeschaltet wird. Ihnen stehen folgende Optionen zur Verfügung:
Aktivieren der Binärprotokollierung
Legen Sie den Aufbewahrungszeitraum für Backups auf einen positiven Wert größer 0 fest.
Deaktivieren der Binärprotokollierung
Legen Sie den Aufbewahrungszeitraum für Backups auf 0 fest.
Weitere Informationen finden Sie unter [Aktivieren von automatisierten Backups](USER_WorkingWithAutomatedBackups.Enabling.md).
MySQL in Amazon RDS unterstützt die binären Protokollformate *row-based*, *statement-based* und *mixed*. Wir empfehlen gemischt, sofern Sie kein spezifisches Format des Binärprotokolls benötigen. Einzelheiten zu den verschiedenen MySQL-Binärprotokollformaten finden Sie in der MySQL-Dokumentation unter [Binary Logging Formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html).
Zur Verwendung der Replikation ist das binäre Protokollierungsformat wichtig, da es den Datensatz der Datenänderungen bestimmt, der in der Quelle aufgezeichnet und an die Replikationsziele gesendet wird. Weitere Informationen über Vor- und Nachteile verschiedener binärer Protokollierungsformate finden Sie unter [Vorteile und Nachteile einer auf Anweisungen und einer auf Zeilen basierenden Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) in der MySQL-Dokumentation.
**Wichtig**
Mit MySQL 8.0.34 hat MySQL den Parameter `binlog_format` als veraltet eingestuft. In späteren MySQL-Versionen plant MySQL, den Parameter zu entfernen und nur die zeilenbasierte Replikation zu unterstützen. Daher empfehlen wir, für neue MySQL-Replikationseinrichtungen die zeilenbasierte Protokollierung zu verwenden. Weitere Informationen finden Sie unter [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) in der MySQL-Dokumentation.
Die MySQL-Versionen 8.0 und 8.4 akzeptieren den Parameter `binlog_format`. Bei Verwendung dieses Parameters gibt MySQL eine Warnmeldung zur Veralterung aus. In einer zukünftigen Hauptversion wird MySQL den Parameter `binlog_format` entfernen.
Die anweisungsbasierte Replikation kann zu Inkonsistenzen zwischen dem Quell-DB-Instance- und einem Lese-Replikat führen. Weitere Informationen finden Sie unter [ Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) in der MySQL-Dokumentation.
Durch die Aktivierung der binären Protokollierung wird die Anzahl der I/O Festplattenschreibvorgänge im erhöht. Sie können die IOPS-Nutzung mit der `WriteIOPS` `` CloudWatch Metrik überwachen.
**Stellen Sie das MySQL-binäres-Protokollierungsformat wie folgt ein:**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Parameter groups (Parametergruppen)** aus.
1. Wählen Sie die zu ändernde DB-Parametergruppe aus, die der DB-Instance zugeordnet ist.
Eine Standard-Parametergruppe kann nicht modifiziert werden. Erstellen Sie eine neue Parametergruppe und ordnen Sie diese dem DB-Instance- zu, wenn der DB-Instance- eine Standardparametergruppe verwendet.
Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Wählen Sie unter **Aktionen** die Option **Bearbeiten** aus.
1. Legen Sie den Parameter `binlog_format` auf das binäre Protokollierungsformat Ihrer Wahl fest (`ROW`, `STATEMENT` oder `MIXED`).
Sie können die Binärprotokollierung deaktivieren, indem Sie den Aufbewahrungszeitraum für Backups einer DB-Instance auf Null festlegen. Dadurch werden jedoch tägliche automatische Backups deaktiviert. Durch das Deaktivieren automatisierter Sicherungen wird die Sitzungsvariable `log_bin` ausgeschaltet oder deaktiviert. Dadurch wird die Binärprotokollierung auf der DB-Instance von RDS für MySQL deaktiviert, wodurch wiederum die Sitzungsvariable `binlog_format` auf den Standardwert `ROW` in der Datenbank zurückgesetzt wird. Wir empfehlen, Backups nicht zu deaktivieren. Weitere Informationen zur Einstellung **Aufbewahrungszeitraums für Backups** finden Sie unter [Einstellungen für DB-Instances](USER_ModifyInstance.Settings.md).
1. Wählen Sie **Save changes (Änderungen speichern)**, um die Aktualisierungen in dieser DB--Parametergruppe zu speichern.
Da der Parameter `binlog_format` in RDS für MySQL dynamisch ist, müssen Sie die DB-Instance nicht neu starten, damit die Änderungen übernommen werden. (Beachten Sie, dass dieser Parameter in Aurora MySQL statisch ist. Weitere Informationen finden Sie unter [Konfigurieren der Aurora-MySQL-Binärprotokollierung](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html).)
**Wichtig**
Das Ändern einer DB-Parametergruppe wirkt sich auf alle DB-Instances aus, die diese Parametergruppe verwenden. Wenn Sie unterschiedliche binäre Logging-Formate für verschiedene MySQL-DB-Instances in einer AWS Region angeben möchten, müssen die DB-Instances unterschiedliche DB-Parametergruppen verwenden. Diese Parametergruppen identifizieren unterschiedliche Protokollierungsformate. Weisen Sie den einzelnen DB-Instances die entsprechende DB-Parametergruppe zu.
# Konfigurieren der MySQL-Binärprotokollierung für DB-Cluster mit Multi-AZ
Die binäre Protokollierung in Amazon RDS for MySQL Multi-AZ-DB-Clustern zeichnet alle Datenbankänderungen auf, um Replikation, point-in-time Wiederherstellung und Prüfung zu unterstützen. In DB-Clustern mit Multi-AZ synchronisieren Binärprotokolle Sekundärknoten mit dem Primärknoten, wodurch die Datenkonsistenz in allen Availability Zones gewährleistet und reibungslose Failover ermöglicht werden.
Um die Binärprotokollierung zu optimieren, unterstützt Amazon RDS die Komprimierung von Binärprotokolltransaktionen, wodurch der Speicherbedarf für Binärprotokolle reduziert und die Replikationseffizienz verbessert werden.
**Topics**
+ [
## Komprimieren von Binärprotokolltransaktionen für DB-Cluster mit Multi-AZ
](#USER_Binlog.MultiAZ.compression)
+ [
## Komprimieren von Binärprotokolltransaktionen für DB-Cluster mit Multi-AZ
](#USER_Binlog.MultiAZ.configuring)
## Komprimieren von Binärprotokolltransaktionen für DB-Cluster mit Multi-AZ
Bei der Komprimierung von Binärprotokolltransaktionen wird der zstd-Algorithmus verwendet, um die Größe der in Binärprotokollen gespeicherten Transaktionsdaten zu reduzieren. Wenn diese Option aktiviert ist, komprimiert die MySQL-Datenbank-Engine Transaktionsnutzlasten zu einem einzigen Ereignis, wodurch der Speicheraufwand minimiert wird I/O . Dieses Feature verbessert die Datenbankleistung, reduziert die Größe des Binärprotokolls und optimiert die Ressourcennutzung für die Verwaltung und Replikation von Protokollen in DB-Clustern mit Multi-AZ.
Amazon RDS bietet die Komprimierung von Binärprotokolltransaktionen für DB-Cluster mit Multi-AZ von RDS für MySQL über die folgenden Parameter:
+ `binlog_transaction_compression` – Wenn diese Option aktiviert ist (`1`), komprimiert die Datenbank-Engine Transaktionsnutzdaten und schreibt sie als einzelnes Ereignis in das Binärprotokoll. Dies reduziert den Speicherverbrauch und den Overhead. I/O Der Parameter ist standardmäßig deaktiviert.
+ `binlog_transaction_compression_level_zstd` – Konfiguriert die zstd-Komprimierungsstufe für Binärprotokolltransaktionen. Höhere Werte erhöhen das Kompressionsverhältnis, wodurch der Speicherbedarf weiter reduziert wird, aber die CPU- und Speichernutzung für die Komprimierung erhöht werden. Der Standardwert ist 3 mit einem Bereich von 1–22.
Mit diesen Parametern können Sie die Komprimierung von Binärprotokollen auf der Grundlage der Workload-Merkmale und der Ressourcenverfügbarkeit optimieren. Weitere Informationen finden Sie unter [Binary Log Transaction Compression](https://dev.mysql.com/doc/refman/8.4/en/binary-log-transaction-compression.html) in der MySQL-Dokumentation.
Die Komprimierung von Binärprotokolltransaktionen bietet die folgenden wesentlichen Vorteile:
+ Durch die Komprimierung wird die Größe von Binärprotokollen verringert, insbesondere bei Workloads mit großen Transaktionen oder hohen Schreibvolumen.
+ Kleinere Binärprotokolle reduzieren den Netzwerk- und I/O Overhead und verbessern so die Replikationsleistung.
+ Der Parameter `binlog_transaction_compression_level_zstd` ermöglicht die Steuerung des Kompromisses zwischen dem Komprimierungsverhältnis und dem Ressourcenverbrauch.
## Komprimieren von Binärprotokolltransaktionen für DB-Cluster mit Multi-AZ
Um die Komprimierung von Binärprotokolltransaktionen für einen DB-Cluster mit Multi-AZ von RDS für MySQL zu konfigurieren, ändern Sie die entsprechenden Cluster-Parametereinstellungen entsprechend Ihren Workload-Anforderungen.
### Konsole
**So aktivieren Sie die Komprimierung von Binärprotokolltransaktionen**
1. Ändern Sie die DB-Cluster-Parametergruppe, um den Parameter `binlog_transaction_compression` auf `1` festzulegen.
1. (Optional) Passen Sie den Wert des Parameters `binlog_transaction_compression_level_zstd` an Ihre Workload-Anforderungen und die Ressourcenverfügbarkeit an.
Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Cluster-Parametergruppe ](USER_WorkingWithParamGroups.ModifyingCluster.md).
### AWS CLI
Um die Komprimierung von Binärprotokolltransaktionen mit dem zu konfigurieren AWS CLI, verwenden Sie den Befehl [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html).
**Example**
Für Linux, macOS oder 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"
```
Für 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"
```
### RDS-API
Verwenden Sie den Vorgang [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html), um die Komprimierung von Binärprotokolltransaktionen mithilfe der Amazon-RDS-API zu konfigurieren.
# Zugriff auf MySQL-Binärprotokolle
Sie können das Dienstprogramm mysqlbinlog verwenden, um Binärprotokolle aus RDS-for-MySQL-DB-Instances herunterzuladen oder zu streamen. Das Binärprotokoll wird auf den lokalen Computer heruntergeladen, von wo aus Sie Aktionen, wie die Wiedergabe eines Protokolls mithilfe des Hilfsprogramms mysql ausführen können. Weitere Informationen über die Verwendung des Dienstprogramms mysqlbinlog finden Sie unter [Verwenden von mysqlbinlog zum Sichern binärer Protokolldateien](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) in der MySQL-Dokumentation.
Verwenden Sie zum Ausführen des Dienstprogramms mysqlbinlog mit einer Amazon-RDS-Instance die folgenden Optionen:
+ `--read-from-remote-server` – Erforderlich.
+ `--host` – der DNS-Name vom Endpunkt der Instance.
+ `--port` – der von der Instance verwendete Port.
+ `--user` – ein MySQL-Benutzer, dem die Berechtigung `REPLICATION SLAVE` erteilt wurde.
+ `--password` – das Passwort für den MySQL-Benutzer oder lassen Sie einen Passwortwert aus, damit das Dienstprogramm zur Eingabe eines Passworts auffordert.
+ `--raw` – Laden Sie die Datei im Binärformat herunter.
+ `--result-file` – die lokale Datei, die den raw-Output empfangen soll.
+ `--stop-never` – Streamen Sie die binären Protokolldateien.
+ `--verbose` – Wenn Sie das Binlog-Format `ROW` verwenden, schließen Sie diese Option ein, um die Zeilenereignisse als Pseudo-SQL-Anweisungen anzuzeigen. Weitere Informationen zur Option `--verbose` finden Sie unter [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) in der MySQL-Dokumentation.
+ Geben Sie die Namen einer oder mehrerer Binärprotokolldateien an. Verwenden Sie den SQL-Befehl `SHOW BINARY LOGS`, um eine Liste der verfügbaren Protokolle abzurufen.
Weitere Informationen über mysqlbinlog-Optionen finden Sie unter [mysqlbinlog – Hilfsprogramm für die Verarbeitung binärer Protokolldateien](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) in der MySQL-Dokumentation.
Die folgenden Beispiele veranschaulichen die Verwendung des Dienstprogramms mysqlbinlog.
Für Linux, macOS oder 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
```
Für 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
```
Binärprotokolle müssen auf der DB-Instance verfügbar bleiben, damit das Dienstprogramm mysqlbinlog auf sie zugreifen kann. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) und geben Sie einen Zeitraum mit ausreichend Zeit für den Download der Protokolle an, um die Verfügbarkeit sicherzustellen. Wenn diese Konfiguration nicht festgelegt ist, löscht Amazon RDS die Binärprotokolle so schnell wie möglich, was zu Lücken in den Binärprotokollen führt, die das Dienstprogramm mysqlbinlog abruft.
Das folgende Beispiel setzt den Aufbewahrungszeitraum auf 1 Tag.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration), um die aktuelle Einstellung anzeigen zu lassen.
```
call mysql.rds_show_configuration;
```
# Datenbankprotokolldateien von Amazon RDS für Oracle
Sie können über die Amazon-RDS-Konsole oder das API auf die Oracle-Warnungsprotokolle, -Auditdateien und -Trace-Dateien zugreifen. Weitere Informationen zum Anzeigen und Herunterladen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
Die bereitgestellten Oracle-Prüfungsdateien sind die Oracle-Standardprüfungsdateien. Amazon RDS unterstützt die FGA-Funktion (Fine-Grained Auditing) von Oracle. Der Protokollzugriff bietet jedoch keinen Zugriff auf FGA-Ereignisse, die in der Tabelle `SYS.FGA_LOG$` gespeichert sind, und die über die Ansicht `DBA_FGA_AUDIT_TRAIL` zur Verfügung stehen.
Die API-Operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) zum Auflisten der Oracle-Protokolldateien, die für eine DB-Instance verfügbar sind, ignoriert den Parameter `MaxRecords` und gibt bis zu 1 000 Datensätze zurück. Der Aufruf wird `LastWritten` als POSIX-Datum in Millisekunden zurückgegeben.
**Topics**
+ [
## Aufbewahrungsplan
](#USER_LogAccess.Concepts.Oracle.Retention)
+ [
## Arbeiten mit Oracle-Trace-Dateien
](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles)
+ [
## Oracle-Logs in Amazon CloudWatch Logs veröffentlichen
](#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)
+ [
## Zugreifen auf Alarmprotokolle und Listener-Protokolle
](#USER_LogAccess.Concepts.Oracle.AlertLogAndListenerLog)
## Aufbewahrungsplan
Die Oracle-Datenbank-Engine kann Protokolldateien rotieren, wenn diese sehr groß werden. Um Audit- oder Trace-Dateien aufzubewahren, laden Sie diese herunter. Wenn Sie die Dateien lokal speichern, reduzieren Sie Ihre Amazon-RDS-Speicherkosten und stellen mehr Speicherplatz für Ihre Daten zur Verfügung.
In der nachfolgenden Tabelle wird der Aufbewahrungsplan für Oracle-Warnungsprotokolle, -Auditdateien und -Trace-Dateien in Amazon RDS gezeigt.
****
| Protokolltyp | Aufbewahrungsplan |
| --- | --- |
| Alarmprotokolle | Die täglichen Warnungsprotokolle werden 30 Tage lang aufbewahrt und von Amazon RDS verwaltet. Das XML-Alarmprotokoll wird mindestens sieben Tage lang aufbewahrt. Sie können über die Ansicht `ALERTLOG` auf dieses Protokoll zugreifen. |
| Audit-Dateien | Der Standardaufbewahrungszeitraum für Prüfungsdateien beträgt sieben Tage. Amazon RDS löscht u. U. Prüfungsdateien, die älter als sieben Tage sind. |
| Trace-Dateien | Der Standardaufbewahrungszeitraum für Trace-Dateien beträgt sieben Tage. Amazon RDS löscht u. U. Trace-Dateien, die älter als sieben Tage sind. |
| Listener-Protokolle | Der Standardaufbewahrungszeitraum für Listener-Protokolle beträgt sieben Tage. Amazon RDS löscht u. U. Listener-Protokolle, die älter als sieben Tage sind. |
**Anmerkung**
Für Audit-Dateien und Trace-Dateien gilt die gleiche Aufbewahrungskonfiguration.
## Arbeiten mit Oracle-Trace-Dateien
Nachfolgend finden Sie Beschreibungen von Amazon-RDS-Verfahren zum Erstellen, Aktualisieren, Zugreifen auf und Löschen von Trace-Dateien.
**Topics**
+ [
### Auflisten von Dateien
](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)
+ [
### Erzeugen von Trace-Dateien und Nachverfolgen einer Sitzung
](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Generating)
+ [
### Abrufen von Trace-Dateien
](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Retrieving)
+ [
### Bereinigen von Trace-Dateien
](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Purging)
### Auflisten von Dateien
Sie können jedes der beiden Verfahren verwenden, um Zugriff auf eine Datei im Pfad `background_dump_dest` zuzulassen. Das erste Verfahren aktualisiert eine Ansicht mit einer Liste aller Dateien in `background_dump_dest`.
```
1. EXEC rdsadmin.manage_tracefiles.refresh_tracefile_listing;
```
Nachdem die Ansicht aktualisiert wurde, fragen Sie die folgende Ansicht ab, um auf die Ergebnisse zuzugreifen.
```
1. SELECT * FROM rdsadmin.tracefile_listing;
```
Eine Alternative zur vorherigen Vorgehensweise ist die Verwendung von `FROM table` zum Streamen von nicht-relationalen Daten in einem tabellenähnlichen Format, um den Inhalt des Datenbankverzeichnisses aufzulisten.
```
1. SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('BDUMP'));
```
Die folgende Abfrage zeigt den Text einer Protokolldatei.
```
1. SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP','alert_dbname.log.date'));
```
Rufen Sie auf einem Read Replica den Namen des BDUMP-Verzeichnisses durch Abfragen von a `V$DATABASE.DB_UNIQUE_NAME`. Wenn der eindeutige Name `DATABASE_B` lautet, dann ist `BDUMP_B` das BDUMP-Verzeichnis. Im folgenden Beispiel wird der BDUMP-Name auf einem Replica abgefragt und dann wird dieser Name verwendet, um den Inhalt von `alert_DATABASE.log.2020-06-23` abzufragen.
```
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'));
```
### Erzeugen von Trace-Dateien und Nachverfolgen einer Sitzung
Da es keine Einschränkungen für `ALTER SESSION` gibt, sind viele Standardmethoden zur Erzeugung von Trace-Dateien in Oracle auch in einer Amazon-RDS-DB-Instance verfügbar. Die folgenden Methoden sind für Trace-Dateien vorgesehen, auf die in größerem Umfang zugegriffen werden muss.
****
| Oracle-Methode | Amazon-RDS-Methode |
| --- | --- |
| `oradebug hanganalyze 3 ` | `EXEC rdsadmin.manage_tracefiles.hanganalyze; ` |
| `oradebug dump systemstate 266 ` | `EXEC rdsadmin.manage_tracefiles.dump_systemstate;` |
Sie können viele Standardverfahren zum Nachverfolgen einzelner, mit einer Oracle-DB-Instance in Amazon RDS verbundenen Sitzung verwenden. Um die Ablaufverfolgung für eine Sitzung zu aktivieren, können Sie Unterprogramme in PL/SQL Paketen ausführen, die von Oracle bereitgestellt werden, z. B. `DBMS_SESSION` und. `DBMS_MONITOR` Weitere Informationen finden Sie unter [Enabling Tracing for a Session](https://docs.oracle.com/database/121/TGSQL/tgsql_trace.htm#GUID-F872D6F9-E015-481F-80F6-8A7036A6AD29) in der Oracle-Dokumentation.
### Abrufen von Trace-Dateien
Sie können jede Trace-Datei in `background_dump_dest` mit einer SQL-Standardabfrage aus einer von Amazon RDS verwalteten externen Tabelle abrufen. Für diese Methode müssen Sie die Prozedur ausführen, um den Speicherort für diese Tabelle auf die spezifische Trace-Datei festzulegen.
Sie können beispielsweise die oben erwähnte Ansicht `rdsadmin.tracefile_listing` verwenden, um alle Trace-Dateien im System aufzulisten. Danach kann die `tracefile_table`-Ansicht so konfiguriert werden, dass sie auf die gewünschte Trace-Datei zeigt.
```
1. EXEC rdsadmin.manage_tracefiles.set_tracefile_table_location('CUST01_ora_3260_SYSTEMSTATE.trc');
```
Im folgenden Beispiel wird eine externe Tabelle im aktuellen Schema mit dem auf die angegebene Datei eingestellten Speicherort erstellt. Sie können den Inhalt mit einer SQL-Abfrage in eine lokale Datei abrufen.
```
1. SPOOL /tmp/tracefile.txt
2. SELECT * FROM tracefile_table;
3. SPOOL OFF;
```
### Bereinigen von Trace-Dateien
Trace-Dateien können sich ansammeln und viel Festplattenspeicher belegen. Amazon RDS löscht automatisch Trace-Dateien und Protokoll-Dateien, die älter als sieben Tage sind. Sie können den Aufbewahrungszeitraum für Trace-Dateien mit der Prozedur `show_configuration` anzeigen und festlegen. Sie sollten den Befehl `SET SERVEROUTPUT ON` ausführen, damit Sie die Konfigurationsergebnisse sehen können.
Im folgenden Beispiel wird zunächst der aktuelle Aufbewahrungszeitraum angezeigt und dann ein neuer Zeitraum festgelegt.
```
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.
```
Sie können zusätzlich zur regelmäßigen automatischen Bereinigung manuell Dateien aus entferne `background_dump_dest`. Im folgenden Beispiel werden alle Dateien gelöscht, die älter als fünf Minuten sind.
```
EXEC rdsadmin.manage_tracefiles.purge_tracefiles(5);
```
Sie können auch alle Dateien löschen, die mit einem bestimmten Muster übereinstimmen (geben Sie in diesem Fall keine Dateinamenserweiterung wie .trc an). Im folgenden Beispiel werden alle Dateien gelöscht, die mit beginne `SCHPOC1_ora_5935`.
```
1. EXEC rdsadmin.manage_tracefiles.purge_tracefiles('SCHPOC1_ora_5935');
```
## Oracle-Logs in Amazon CloudWatch Logs veröffentlichen
Sie können Ihre RDS for Oracle DB-Instance so konfigurieren, dass Protokolldaten in einer Protokollgruppe in Amazon CloudWatch Logs veröffentlicht werden. Mit CloudWatch Logs können Sie die Protokolldaten analysieren und zur Erstellung von Alarmen und CloudWatch zum Anzeigen von Metriken verwenden. Sie können CloudWatch Logs verwenden, um Ihre Protokolldatensätze in einem äußerst langlebigen Speicher zu speichern.
Amazon RDS veröffentlicht jedes Oracle-Datenbankprotokoll als separaten Datenbank-Stream in der Protokollgruppe. Wenn Sie beispielsweise die Exportfunktion so konfigurieren, dass das Audit-Protokoll berücksichtigt wird, werden Audit-Daten in einem Audit-Protokollstream in der Protokollgruppe `/aws/rds/instance/my_instance/audit` gespeichert. In der folgenden Tabelle sind die Anforderungen für RDS for Oracle zusammengefasst, um Protokolle in Amazon CloudWatch Logs zu veröffentlichen.
| Protokollnamen | Anforderung | Standard |
| --- | --- | --- |
| Alert-Protokoll | Keine. Sie können dieses Protokoll nicht deaktivieren. | Aktiviert |
| Trace-Protokoll | Stellen Sie den Parameter `trace_enabled` auf `TRUE` oder behalten Sie die Standardeinstellung bei. | `TRUE` |
| Prüfungsprotokoll | Legen Sie den Parameter `audit_trail` auf einen der folgenden Werte fest: { none | os | db [, extended] | xml [, extended] } | `none` |
| Listener-Protokoll | Keine. Sie können dieses Protokoll nicht deaktivieren. | Aktiviert |
| Oracle Management Agent-Protokoll | Keine. Sie können dieses Protokoll nicht deaktivieren. | Aktiviert |
Dieses Protokoll von Oracle Management Agent besteht aus den in der folgenden Tabelle aufgeführten Protokollgruppen.
****
| Protokollnamen | CloudWatch Protokollgruppe |
| --- | --- |
| 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 |
Weitere Informationen finden Sie unter [Locating Management Agent Log and Trace Files (Management Agent Protokoll- und Trace-Dateien anzeigen)](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) in der Oracle-Dokumentation.
### Konsole
**Um Oracle-DB-Logs in CloudWatch Logs aus dem zu veröffentlichen AWS-Managementkonsole**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** und dann die DB-Instance, die Sie ändern möchten.
1. Wählen Sie **Modify** aus.
1. Wählen Sie im Abschnitt **Protokollexporte** die Logs aus, mit der Veröffentlichung in CloudWatch Logs beginnen möchten.
1. Wählen Sie **Weiter** und dann auf der zusammenfassenden Seite **Modify DB Instance** (DB-Instance ändern) aus.
### AWS CLI
Um Oracle-Protokolle zu veröffentlichen, können Sie den Befehl [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) mit den folgenden Parametern verwenden:
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**Anmerkung**
Eine Änderung der Option `--cloudwatch-logs-export-configuration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund sind die Optionen `--apply-immediately` und `--no-apply-immediately` wirkungslos.
Sie können Oracle-Protokolle auch mit den folgenden Befehlen veröffentlichen:
+ [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**
Im folgenden Beispiel wird eine Oracle-DB-Instance mit aktivierter CloudWatch Protokollveröffentlichung erstellt. Der Wert `--cloudwatch-logs-export-configuration` ist ein JSON-Array mit Zeichenfolgen. Die Zeichenfolgen können eine beliebige Kombination von `alert`, `audit`, `listener` und `trace` sein.
Für Linux, macOS oder 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
```
Für 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**
Das folgende Beispiel ändert eine bestehende Oracle-DB-Instance, um Protokolldateien in CloudWatch Logs zu veröffentlichen. Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `EnableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit einer beliebigen Kombination aus `alert`, `audit`, `listener` und `trace`.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["trace","alert","audit","listener","oemagent"]}'
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration EnableLogTypes=\"trace\",\"alert\",\"audit\",\"listener\",\"oemagent\"
```
**Example**
Im folgenden Beispiel wird eine bestehende Oracle-DB-Instance dahingehend geändert, dass die Veröffentlichung von Audit- und Listener-Logdateien in Logs deaktiviert wird. CloudWatch Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `DisableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit einer beliebigen Kombination aus `alert`, `audit`, `listener` und `trace`.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit","listener"]}'
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--cloudwatch-logs-export-configuration DisableLogTypes=\"audit\",\"listener\"
```
### RDS-API
Sie können Oracle DB-Protokolle über die RDS-API veröffentlichen. Die Aktion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) kann dazu mit den folgenden Parametern aufgerufen werden:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**Anmerkung**
Eine Änderung des Parameters `CloudwatchLogsExportConfiguration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund ist der Parameter `ApplyImmediately` wirkungslos.
Sie können Oracle-Protokolle auch veröffentlichen, indem Sie die folgenden RDS-API-Operationen aufrufen:
+ [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)
Führen Sie eine dieser RDS-API-Operationen mit den folgenden Parametern aus:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Je nach ausgeführter RDS-Operation müssen möglicherweise noch weitere Parameter angegeben werden.
## Zugreifen auf Alarmprotokolle und Listener-Protokolle
Sie können über die Amazon-RDS-Konsole das Alarmprotokoll anzeigen. Sie können auch die folgende SQL-Anweisung verwenden.
```
1. SELECT message_text FROM alertlog;
```
Greifen Sie mit Amazon CloudWatch Logs auf das Listener-Protokoll zu.
**Anmerkung**
Oracle rotiert die Alarm- und Listener-Protokolle, wenn deren Dateigröße 10 MB überschreitet. Die Protokolle sind dann nicht mehr in den Amazon-RDS-Ansichten verfügbar.
# RDS für PostgreSQL-Datenbankprotokolldateien
Sie können die folgenden Arten von Protokolldateien überwachen:
+ PostgreSQL-Protokoll
+ Protokoll aktualisieren
+ Fehlerprotokoll zur IAM-Datenbankauthentifizierung
**Anmerkung**
Um Fehlerprotokolle für die IAM-Datenbankauthentifizierung zu aktivieren, müssen Sie zunächst die IAM-Datenbankauthentifizierung für Ihre DB-Instances von RDS für PostgreSQL aktivieren. Weitere Informationen zur Aktivierung der IAM-Datenbankauthentifizierung finden Sie unter [Aktivieren und Deaktivieren der IAM-Datenbank-Authentifizierung](UsingWithRDS.IAMDBAuth.Enabling.md).
RDS für PostgreSQL protokolliert Datenbankaktivitäten in der PostgreSQL-Standardprotokolldatei. Bei einer On-Premises PostgreSQL-DB-Instance werden diese Nachrichten in `log/postgresql.log` lokal gespeichert. Für eine DB-Instance von RDS für PostgreSQL ist die Protokolldatei auf der Amazon-RDS-Instance verfügbar. Auf diese Protokolle kann auch über die zugegriffen werden AWS-Managementkonsole, wo Sie sie ansehen oder herunterladen können. Die Standardprotokollierungsebene erfasst Anmeldefehler, schwerwiegende Serverfehler, Deadlocks und Abfragefehler.
Weitere Informationen zum Anzeigen, Herunterladen und Überwachen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md). Weitere Informationen zu PostgreSQL-Protokollen finden Sie unter [Arbeiten mit Amazon RDS und Aurora-PostgreSQL-Protokollen: Teil 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) und [Arbeiten mit Amazon RDS und Aurora-PostgreSQL-Protokollen: Teil 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/).
Zusätzlich zu den in diesem Thema behandelten PostgreSQL-Standardprotokollen unterstützt RDS für PostgreSQL auch die PostgreSQL-Audit-Erweiterung (`pgAudit`). Die meisten regulierten Branchen und Regierungsbehörden müssen ein Auditprotokoll oder einen Audit-Trail für die Änderungen von Daten führen, um die gesetzlichen Bestimmungen zu erfüllen. Weitere Informationen zur Installation und Verwendung von pgAudit finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
**Topics**
+ [
# Parameter für die Protokollierung in RDS für PostgreSQL
](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [
# Aktivieren der Abfrageprotokollierung für Ihren
](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
+ [
## PostgreSQL-Protokolle in Amazon Logs veröffentlichen CloudWatch
](#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)
# Parameter für die Protokollierung in RDS für PostgreSQL
Sie können das Protokollierungsverhalten für Ihre DB-Instance von RDS für PostgreSQL anpassen, indem Sie verschiedene Parameter ändern. In der folgenden Tabelle finden Sie unter anderem die Parameter, die sich darauf auswirken, wie lange die Protokolle gespeichert werden, wann das Protokoll rotiert werden soll und ob das Protokoll im CSV-Format (Comma-Separated Value) ausgegeben werden soll. Außerdem ist abgesehen von anderen Einstellungen die Textausgabe angegeben, die an STDERR gesendet wurde. Wenn Sie die Einstellungen für die modifizierbaren Parameter ändern möchten, verwenden Sie eine benutzerdefinierte DB-Parametergruppe für Ihren . Instance von RDS für PostgreSQL Weitere Informationen finden Sie unter [DB-Parametergruppen für DB-Instances von Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
| Parameter | Standard | Description |
| --- | --- | --- |
| log\$1destination | stderr | Legt das Ausgabeformat für das Protokoll fest. Die Standardeinstellung ist `stderr`, aber Sie können auch das CSV-Format angeben, indem Sie der Einstellung `csvlog` hinzufügen. Weitere Informationen finden Sie unter [Festlegen des Protokollziels (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H | Gibt das Muster für den Namen der Protokolldatei an. Zusätzlich zur Standardeinstellung unterstützt dieser Parameter `postgresql.log.%Y-%m-%d` und `postgresql.log.%Y-%m-%d-%H%M` für das Dateinamenmuster. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Definiert das Präfix für jede Protokollzeile, die in `stderr` geschrieben wird, um die Uhrzeit (%t), den Remote-Host (%r), den Benutzer (%u), die Datenbank (%d) und die Prozess-ID (%p) anzugeben. |
| log\$1rotation\$1age | 60 | Minuten, nach denen die Protokolldatei automatisch rotiert wird. Sie können diesen Wert im Bereich von 1 Minute bis 1.440 Minuten ändern. Weitere Informationen finden Sie unter [Festlegen der Rotation der Protokolldatei](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | Die Größe (kB), bei der das Protokoll automatisch rotiert wird. Standardmäßig wird dieser Parameter nicht verwendet, da die Protokolle auf der Grundlage des `log_rotation_age` Parameters rotiert werden. Weitere Informationen hierzu finden Sie unter [Festlegen der Rotation der Protokolldatei](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | PostgreSQL-Protokolle, die älter als die angegebene Anzahl von Minuten sind, werden gelöscht. Mit dem Standardwert von 4.320 Minuten werden Protokolldateien nach 3 Tagen gelöscht. Weitere Informationen finden Sie unter [Festlegen des Aufbewahrungszeitraums für Protokolle](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Anwendungsprobleme können Sie identifizieren, indem Sie im Protokoll nach Abfragefehlern, Anmeldefehlern, Deadlocks und schwerwiegenden Serverfehlern suchen. Angenommen, Sie haben eine Legacy-Anwendung von Oracle in Amazon RDS PostgreSQL konvertiert, wobei jedoch nicht alle Abfragen ordnungsgemäß umgewandelt wurden. Diese falsch formatierten Abfragen generieren Fehlermeldungen in den Protokollen, mit denen Sie Probleme identifizieren können. Weitere Informationen zur Protokollierung von Abfragen finden Sie unter [Aktivieren der Abfrageprotokollierung für Ihren ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
In den folgenden Themen finden Sie Informationen darüber, wie Sie verschiedene Parameter festlegen, die die grundlegenden Details Ihrer PostgreSQL-Protokolle steuern.
**Topics**
+ [
## Festlegen des Aufbewahrungszeitraums für Protokolle
](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [
## Festlegen der Rotation der Protokolldatei
](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [
## Festlegen des Protokollziels (`stderr`, `csvlog`)
](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [
## Grundlagen des Parameters log\$1line\$1prefix
](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Festlegen des Aufbewahrungszeitraums für Protokolle
Der `rds.log_retention_period`-Parameter gibt an, wie lange Ihre DB-Instance von RDS für PostgreSQL die entsprechenden Protokolldateien aufbewahrt. Die Standardeinstellung ist 3 Tage (4 320 Minuten). Sie können diese Einstellung jedoch auf einen beliebigen Wert zwischen 1 Tag (1 440 Minuten) und 7 Tagen (10 080 Minuten) festlegen. Stellen Sie sicher, dass Ihre DB-Instance von RDS für PostgreSQL über ausreichend Speicherplatz verfügt, um die Protokolldateien für diesen Zeitraum zu speichern.
Wir empfehlen, dass Sie Ihre Protokolle routinemäßig in Amazon CloudWatch Logs veröffentlichen, damit Sie Systemdaten noch lange nach dem Entfernen der Protokolle aus Ihrem anzeigen und analysieren können. DB-Instance von RDS für PostgreSQL Weitere Informationen finden Sie unter [PostgreSQL-Protokolle in Amazon Logs veröffentlichen CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
## Festlegen der Rotation der Protokolldatei
Neue Protokolldateien werden von Amazon RDS standardmäßig jede Stunde erstellt. Das Timing wird vom Parameter `log_rotation_age` kontrolliert. Dieser Parameter hat einen Standardwert von 60 (Minuten). Sie können ihn jedoch auf jeden beliebigen Wert zwischen 1 Minute und 24 Stunden (1 440 Minuten) festlegen. Wenn die Rotation ansteht, wird eine neue eindeutige Protokolldatei erstellt. Die Datei wird nach dem Muster benannt, das durch den Parameter `log_filename` angegeben wird.
Protokolldateien können auch entsprechend ihrer Größe gedreht werden, wie im Parameter `log_rotation_size` angegeben. Dieser Parameter gibt an, dass das Protokoll rotiert werden soll, wenn es die angegebene Größe (in Kilobyte) erreicht. Bei einer RDS-for-PostgreSQL-DB-Instance wird `log_rotation_size` nicht festgelegt, das heißt, es wird kein Wert angegeben. Der Parameter ermöglicht jedoch die Einstellung von 0-2 097 151 kB (Kilobyte).
Die Protokolldateinamen basieren auf dem Dateinamenmuster des Parameters `log_filename`. Die verfügbaren Einstellungen für diesen Parameter lauten wie folgt:
+ `postgresql.log.%Y-%m-%d` – Standardformat für den Namen der Protokolldatei. Nimmt das Jahr, den Monat und das Datum in den Namen der Protokolldatei auf.
+ `postgresql.log.%Y-%m-%d-%H` – Nimmt die Stunde in das Format des Protokolldateinamens auf.
Weitere Informationen finden Sie unter [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) und [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) in der PostgreSQL-Dokumentation.
## Festlegen des Protokollziels (`stderr`, `csvlog`)
Standardmäßig generiert Amazon RDS PostgreSQL Protokolle im Standardfehlerformat (stderr). Dieses Format ist die Standardeinstellung des Parameters `log_destination`. Jede Nachricht erhält ein Präfix nach dem im `log_line_prefix`-Parameter angegebenen Muster. Weitere Informationen finden Sie unter [Grundlagen des Parameters log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
RDS für PostgreSQL kann die Protokolle auch im `csvlog`-Format generieren. Das `csvlog`-Format ist nützlich, um die Protokolldaten als CSV-Daten zu analysieren. Angenommen, Sie verwenden die Erweiterung `log_fdw`, um mit Ihren Protokollen als Fremdtabellen zu arbeiten. Die Fremdtabelle, die für `stderr`-Protokolldateien erstellt wurde, enthält eine einzelne Spalte mit Protokollereignisdaten. Durch Hinzufügen von `csvlog` zum `log_destination`-Parameter erhalten Sie die Protokolldatei im CSV-Format mit Abgrenzungen für die verschiedenen Spalten der Fremdtabelle. Sie können Ihre Protokolle jetzt einfacher sortieren und analysieren. Informationen dazu, wie Sie `log_fdw` mit `csvlog` verwenden, finden Sie unter [Verwenden der Erweiterung log\$1fdw für den Zugriff auf das DB-Protokoll mithilfe von SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
Wenn Sie `csvlog` für diesen Parameter angeben, beachten Sie, dass sowohl `stderr`- als auch `csvlog`-Dateien generiert werden. Achten Sie auf den von den Protokollen verbrauchten Speicher und berücksichtigen Sie dabei die `rds.log_retention_period`und andere Einstellungen, die sich auf den Protokollspeicher und Turnover auswirken. Wenn Sie `stderr` und `csvlog` verwenden, verdoppelt sich der von den Protokollen verbrauchte Speicher.
Wenn Sie `csvlog` zu `log_destination` hinzufügen und zu `stderr` allein zurückkehren möchten, müssen Sie den Parameter zurücksetzen. Rufen Sie dazu die Amazon-RDS-Konsole auf und öffnen Sie die benutzerdefinierte DB-Parametergruppe für Ihre Instance. Wählen Sie den `log_destination`-Parameter, die Option **Edit parameter** (Parameter bearbeiten) und dann **Reset** (Zurücksetzen) aus.
Weitere Informationen zum Konfigurieren der Protokollierung finden Sie unter [Arbeiten mit Amazon-RDS- und Aurora-PostgreSQL-Protokollen: Teil 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/).
## Grundlagen des Parameters log\$1line\$1prefix
Das Protokollformat `stderr` wird jeder Protokollnachricht mit den Details vorangestellt, die durch den Parameter `log_line_prefix` angegeben werden. Der Standardwert ist:
```
%t:%r:%u@%d:[%p]:t
```
Ab Aurora-PostgreSQL-Version 16 können Sie auch Folgendes auswählen:
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Jeder Protokolleintrag, der an stderr gesendet wird, enthält die folgenden Informationen, die auf dem ausgewählten Wert basieren:
+ `%t` – Zeitpunkt des Protokolleintrags ohne Millisekunden
+ `%m` – Zeitpunkt des Protokolleintrags mit Millisekunden
+ `%r` – Adresse des Remote-Hosts
+ `%u@%d` – Benutzername und Datenbankname
+ `[%p]` – Prozess-ID, falls verfügbar
+ `%l` – Nummer der Protokollzeile pro Sitzung
+ `%e` – SQL-Fehlercode
+ `%s` – Start-Zeitstempel des Prozesses
+ `%v` – ID der virtuellen Transaktion
+ `%x` – Transaktions-ID
+ `%c` – Sitzungs-ID
+ `%q` – Nicht für Sitzungen vorgesehene Begrenzung
+ `%a` – Anwendungsname
# Aktivieren der Abfrageprotokollierung für Ihren
Sie können detailliertere Informationen über Ihre Datenbankaktivitäten sammeln, einschließlich Abfragen, Abfragen, die auf Sperren warten, Prüfpunkte und viele andere Details, indem Sie einige der in der folgenden Tabelle aufgeführten Parameter festlegen. Dieses Thema konzentriert sich auf das Protokollieren von Abfragen.
| Parameter | Standard | Description |
| --- | --- | --- |
| log\$1connections | – | Protokolliert jede erfolgreiche Verbindung. |
| log\$1disconnections | – | Protokolliert das Ende jeder Sitzung und ihre Dauer. |
| log\$1checkpoints | 1 | Protokolliert jeden Checkpoint. |
| log\$1lock\$1waits | – | Protokolliert lange Sperrenwartezeiten. Dieser Parameter ist standardmäßig nicht festgelegt. |
| log\$1min\$1duration\$1sample | – | (ms) Legt die Mindestausführungszeit fest, jenseits der stichprobenartig Anweisungen protokolliert werden. Die Stichprobengröße wird mit dem log\$1statement\$1sample\$1rate-Parameter festgelegt. |
| log\$1min\$1duration\$1statement | – | Jede SQL-Anweisung, die mindestens für die angegebene Zeit oder länger ausgeführt wird, wird protokolliert. Dieser Parameter ist standardmäßig nicht festgelegt. Die Aktivierung dieses Parameters kann Sie dabei unterstützen, nicht optimierte Abfragen zu finden. |
| log\$1statement | – | Legt den Typ der protokollierten Anweisungen fest. Standardmäßig ist dieser Parameter nicht festgelegt, aber Sie können ihn in `all`, `ddl` oder `mod` ändern, um die Typen von SQL-Anweisungen anzugeben, die protokolliert werden sollen. Wenn Sie etwas anderes als `none` für diesen Parameter angeben, sollten Sie auch zusätzliche Maßnahmen ergreifen, um die Offenlegung von Passwörtern in den Protokolldateien zu verhindern. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | Der Prozentsatz der Anweisungen, die die in `log_min_duration_sample` angegebene Zeit bei der Protokollierung überschreiten. Diese Angabe wird als Gleitkommawert zwischen 0,0 und 1,0 ausgedrückt. |
| log\$1statement\$1stats | – | Schreibt kumulative Leistungsstatistiken in das Serverprotokoll. |
## Verwendung der Protokollierung, um Abfragen mit langsamer Ausführung zu suchen
Sie können SQL-Anweisungen und Abfragen protokollieren, um Abfragen zu finden, die langsam ausgeführt werden. Sie aktivieren diese Funktion, indem Sie die Einstellungen der Parameter `log_statement` und `log_min_duration` wie in diesem Abschnitt beschrieben ändern. Bevor Sie die Abfrageprotokollierung für Ihre DB-Instance von RDS für PostgreSQL aktivieren, sollten Sie sich der möglichen Offenlegung von Passwörtern in den Protokollen bewusst sein und wissen, wie Sie die Risiken minimieren können. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
Nachstehend finden Sie Referenzinformationen zu den Parametern `log_statement` und `log_min_duration`.log\$1statement
Dieser Parameter gibt den Typ der SQL-Anweisungen an, die an das Protokoll gesendet werden sollen. Der Standardwert ist `none`. Wenn Sie diesen Parameter in `all`, `ddl` oder `mod` ändern, stellen Sie sicher, dass Sie die empfohlenen Maßnahmen ergreifen, um das Risiko einer Offenlegung von Passwörtern in den Protokollen zu reduzieren. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**all**
Protokolliert alle Anweisungen. Diese Einstellung wird für Debugging-Zwecke empfohlen.
**ddl**
Protokolliert alle Data Definition Language (DDL)-Anweisungen wie CREATE, ALTER, DROP usw.
**mod**
Protokolliert alle DDL-Anweisungen und Data Manipulation Language (DML)-Anweisungen wie INSERT, UPDATE und DELETE, die die Daten modifizieren.
**Keine**
Es werden keine SQL-Anweisungen protokolliert. Wir empfehlen diese Einstellung, um das Risiko zu vermeiden, dass Passwörter in den Protokollen offengelegt werden.log\$1min\$1duration\$1statement
Jede SQL-Anweisung, die mindestens für die angegebene Zeit oder länger ausgeführt wird, wird protokolliert. Dieser Parameter ist standardmäßig nicht festgelegt. Die Aktivierung dieses Parameters kann Sie dabei unterstützen, nicht optimierte Abfragen zu finden.
**–1–2147483647**
Die Laufzeit in Millisekunden (ms), in der eine Anweisung protokolliert wird.
**So richten Sie die Abfrageprotokollierung ein**
Bei diesen Schritten wird davon ausgegangen, dass Ihr Die DB-Instance von RDS für PostgreSQL verwendet eine benutzerdefinierte DB-Parametergruppe.
1. Stellen Sie den Parameter `log_statement` auf `all` ein. Im folgenden Beispiel werden die Informationen gezeigt, die bei dieser Parametereinstellung in die Datei `postgresql.log` geschrieben werden.
```
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. Legen Sie den Parameter `log_min_duration_statement` fest. Im folgenden Beispiel werden die Informationen gezeigt, die in die Datei `postgresql.log` geschrieben werden, wenn der Parameter auf `1` festgelegt wird.
Abfragen, die die im `log_min_duration_statement`-Parameter angegebene Dauer überschreiten, werden protokolliert. Es folgt ein Beispiel. Sie können die Protokolldatei für Ihre DB-Instance von RDS für PostgreSQL in der Amazon-RDS-Konsole anzeigen.
```
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 ----------------------
```
### Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der Abfrageprotokollierung
Wir empfehlen, für `log_statement` die Einstellung `none` beizubehalten, um zu vermeiden, dass Passwörter offengelegt werden. Wenn Sie `log_statement` auf `all`, `ddl` oder `mod` festlegen, sollten Sie einen oder mehrere der folgenden Schritte auszuführen.
+ Verschlüsseln Sie vertrauliche Informationen für den Client. Weitere Informationen finden Sie unter [Verschlüsselungsoptionen](https://www.postgresql.org/docs/current/encryption-options.html) der PostgreSQL-Dokumentation. Verwenden Sie die Optionen `ENCRYPTED` und `UNENCRYPTED` der `CREATE`- und `ALTER`-Anweisungen. Weitere Informationen finden Sie im Abschnitt [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) der PostgreSQL-Dokumentation.
+ Richten Sie für Ihre DB-Instance von RDS für PostgreSQL die PostgreSQL Auditing (PGAudit)-Erweiterung ein und verwenden Sie sie. Diese Erweiterung redigiert sensible Informationen in CREATE- und ALTER-Anweisungen, die an das Protokoll gesendet werden. Weitere Informationen finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Beschränkt den Zugriff auf die CloudWatch Protokolle.
+ Verwenden Sie stärkere Authentifizierungsmechanismen wie IAM.
## PostgreSQL-Protokolle in Amazon Logs veröffentlichen CloudWatch
Um Ihre PostgreSQL-Protokolldatensätze in einem äußerst langlebigen Speicher zu speichern, können Sie Amazon CloudWatch Logs verwenden. Mit CloudWatch Logs können Sie auch Protokolldaten in Echtzeit analysieren und diese zur Anzeige von Metriken und CloudWatch zur Erstellung von Alarmen verwenden. Wenn Sie beispielsweise `log_statement` auf `ddl` festlegen, können Sie einen Alarm einrichten, der immer dann ausgelöst wird, wenn eine DDL-Anweisung ausgeführt wird. Sie können wählen, ob Ihre CloudWatch PostgreSQL-Protokolle während der Erstellung Ihrer RDS for PostgreSQL-DB-Instance in Logs hochgeladen werden sollen. Wenn Sie zu diesem Zeitpunkt keine Protokolle hochladen möchten, können Sie Ihre Instance später so ändern, dass ab diesem Zeitpunkt mit dem Hochladen von Protokollen begonnen wird. Mit anderen Worten, vorhandene Protokolle werden nicht hochgeladen. Es werden nur neue Protokolle hochgeladen, da sie auf Ihrer modifizierten DB-Instance von RDS für PostgreSQL erstellt werden.
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen die Veröffentlichung von Protokolldateien in Logs. CloudWatch Weitere Informationen finden Sie unter [Aktualisierungen von Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) im Abschnitt *Versionshinweise für Amazon RDS für PostgreSQL*.
Um mit CloudWatch Logs zu arbeiten, konfigurieren Sie Ihre RDS for PostgreSQL-DB-Instance so, dass Protokolldaten in einer Protokollgruppe veröffentlicht werden.
Sie können die folgenden Protokolltypen in CloudWatch Logs for RDS for PostgreSQL veröffentlichen:
+ PostgreSQL-Protokoll
+ Protokoll aktualisieren
+ Fehlerprotokoll zur IAM-Datenbankauthentifizierung
Nachdem Sie die Konfiguration abgeschlossen haben, veröffentlicht Amazon RDS die Protokollereignisse, um Streams innerhalb einer CloudWatch Protokollgruppe zu protokollieren. Beispielsweise werden die PostgreSQL-Protokolldaten innerhalb der Protokollgruppe gespeicher `/aws/rds/instance/my_instance/postgresql`. Um Ihre Protokolle einzusehen, öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
### Konsole
**So veröffentlichen Sie PostgreSQL-Protokolle mithilfe der Konsole in CloudWatch Logs**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Datenbanken** aus.
1. Wählen Sie die zu ändernde DB-Instance aus und klicken Sie anschließend auf **Modify (Ändern)**.
1. Wählen Sie im Abschnitt **Protokollexporte** die Protokolle aus, die Sie in Logs veröffentlichen möchten CloudWatch .
Der Abschnitt **Protokollexporte** ist nur für PostgreSQL-Versionen verfügbar, die das Veröffentlichen in Logs unterstützen. CloudWatch
1. Wählen Sie **Weiter** und dann auf der zusammenfassenden Seite **Modify DB Instance** (DB-Instance ändern) aus.
### AWS CLI
Sie können PostgreSQL-Protokolle mit dem veröffentlichen. AWS CLI Sie können den Befehl [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) mit den folgenden Parametern aufrufen.
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`
**Anmerkung**
Eine Änderung der Option `--cloudwatch-logs-export-configuration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund sind die Optionen `--apply-immediately` und `--no-apply-immediately` wirkungslos.
Sie können PostgreSQL-Protokolle auch veröffentlichen, indem Sie die folgenden CLI-Befehle aufrufen:
+ [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)
Führen Sie einen dieser CLI-Befehle mit den folgenden Optionen aus:
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`
Je nach verwendetem CLI-Befehl müssen möglicherweise noch weitere Optionen angegeben werden.
**Example Ändern Sie eine Instanz, um Protokolle in Logs zu veröffentlichen CloudWatch**
Das folgende Beispiel ändert eine bestehende PostgreSQL-DB-Instance, um Protokolldateien in Logs zu veröffentlichen. CloudWatch Der `--cloudwatch-logs-export-configuration`-Wert ist ein JSON-Objekt. Der Schlüssel für dieses Objekt ist `EnableLogTypes` und dessen Wert ist ein Array von Zeichenfolgen mit einer beliebigen Kombination aus `postgresql` und `upgrade`.
Für Linux, macOS oder Unix:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql", "upgrade"]}'
```
Für Windows:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}'
```
**Example Erstellen Sie eine Instanz, um Protokolle in Logs zu veröffentlichen CloudWatch**
Im folgenden Beispiel wird eine PostgreSQL-DB-Instance erstellt und Protokolldateien in Logs veröffentlicht. CloudWatch Der Wert `--enable-cloudwatch-logs-exports` ist ein JSON-Array mit Zeichenfolgen. Die Zeichenfolgen können eine beliebige Kombination aus `postgresql` und `upgrade` sein.
Für Linux, macOS oder 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
```
Für 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
```
### RDS-API
Sie können PostgreSQL-Protokolle mit der RDS-API veröffentlichen. Die Aktion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) kann dazu mit den folgenden Parametern aufgerufen werden:
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`
**Anmerkung**
Eine Änderung des Parameters `CloudwatchLogsExportConfiguration` wird immer sofort auf die DB-Instance angewendet. Aus diesem Grund ist der Parameter `ApplyImmediately` wirkungslos.
Sie können PostgreSQL-Protokolle auch veröffentlichen, indem Sie die folgenden RDS-API-Operationen aufrufen:
+ [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)
Führen Sie eine dieser RDS-API-Operationen mit den folgenden Parametern aus:
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`
Je nach ausgeführter Operation müssen möglicherweise noch weitere Parameter angegeben werden.