Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Amazon RDS für PostgreSQL
Amazon RDS unterstützt DB-Instances für mehrere Versionen und Editionen von PostgreSQL. Eine Liste der verfügbaren Versionen finden Sie unter [Verfügbare PostgreSQL-Datenbankversionen](PostgreSQL.Concepts.General.DBVersions.md).
Sie können DB-Instances und DB-Snapshots, Point-in-Time-Wiederherstellungen und Backups erstellen. DB-Instances mit PostgreSQL unterstützen Multi-AZ-Bereitstellungen, Read Replicas sowie bereitgestellte IOPS und können innerhalb einer Virtual Private Cloud (VPC) erstellt werden. Für die Verbindung zu einer DB-Instance mit PostgreSQL können Sie auch Secure Socket Layer (SSL) nutzen.
Bevor Sie eine DB-Instance erstellen, stellen Sie sicher, dass Sie die Schritte in [Einrichten Ihrer Umgebung für Amazon RDS](CHAP_SettingUp.md) ausführen.
Sie können eine beliebige Standard-SQL-Client-Anwendung verwenden, um von Ihrem Computer aus Befehle für die Instance auszuführen. Beispiele solcher Anwendungen: pgAdmin, ein beliebtes Open-Source-Verwaltungs- und Entwicklungstool für PostgreSQL, oder auch psql, ein Befehlszeilen-Dienstprogramm, das Teil einer PostgreSQL-Installation ist. Um eine verwaltete Service-Erfahrung zu bieten, ermöglicht Amazon RDS keinen Host-Zugriff auf DB-Instances. Eingeschränkt wird auch der Zugriff auf bestimmte Systemprozeduren und Tabellen, für die erweiterte Berechtigungen erforderlich sind. Amazon RDS unterstützt den Zugriff auf Datenbanken auf einer DB-Instance unter Verwendung jeder Standard-SQL-Client-Anwendung. Amazon RDS unterstützt keinen direkten Zugriff auf den Host auf eine DB-Instance mithilfe von Telnet oder Secure Shell (SSH).
Amazon RDS für PostgreSQL ist im Einklang mit vielen Industriestandards. Sie können beispielsweise Amazon-RDS-for-PostgreSQL-Datenbanken verwenden, um HIPAA-konforme Anwendungen zu erstellen und Zustandsdaten zu speichern. Dazu gehört die Speicherung geschützter Zustandsdaten (protected health information, PHI) im Rahmen eines abgeschlossenen Business Associate Agreement (BAA) mit AWS. Amazon RDS für PostgreSQL erfüllt auch die Anforderungen des Federal Risk and Authorization Management Program (FedRAMP). Amazon RDS für PostgreSQL hat eine FedRAMP Joint Authorization Board (JAB) Provisional Authority to Operate (P-ATO) bei der FedRAMP HIGH Baseline innerhalb desAWS GovCloud (US)Regionen. Weitere Informationen über unterstützte Compliance-Standards finden Sie unter [AWSCloud-Compliance](https://aws.amazon.com/compliance/).
Um PostgreSQL-Daten in eine DB-Instance zu importieren, befolgen Sie bitte die Informationen im Abschnitt [Importieren von Daten in PostgreSQL in Amazon RDS](PostgreSQL.Procedural.Importing.md).
**Wichtig**
Wenn Sie auf ein Problem mit Ihrer DB-Instance von RDS für PostgreSQL stoßen, benötigt der Kundendienstmitarbeiter des AWS Supports möglicherweise weitere Informationen zum Zustand Ihrer Datenbanken. Ziel ist es, sicherzustellen, dass der AWS Support die erforderlichen Informationen so schnell wie möglich erhält.
Sie können PG Collector verwenden, um wertvolle Datenbankinformationen in einer konsolidierten HTML-Datei zu sammeln. Weitere Informationen zu PG Collector, zur Ausführung und zum Herunterladen des HTML-Berichts finden Sie unter [PG Collector](https://github.com/awslabs/pg-collector).
Nach erfolgreichem Abschluss und sofern nicht anders angegeben, gibt das Skript die Ausgabe in einem lesbaren HTML-Format zurück. Das Skript ist so konzipiert, dass alle Daten oder Sicherheitsdetails, die Ihr Unternehmen gefährden könnten, aus dem HTML-Code ausgeschlossen werden. Es nimmt auch keine Änderungen an Ihrer Datenbank oder ihrer Umgebung vor. Wenn Sie jedoch Informationen im HTML-Code finden, die Sie nicht weitergeben möchten, können Sie diese entfernen, bevor Sie den HTML-Code hochladen. Wenn der HTML-Code akzeptabel ist, laden Sie ihn im Anlagen-Abschnitt der Falldetails Ihres Support-Falls hoch.
**Topics**
+ [Häufige Verwaltungsaufgaben für Amazon RDS for PostgreSQL](CHAP_PostgreSQL.CommonTasks.md)
+ [Arbeiten mit der Datenbank-Vorschauumgebung](working-with-the-database-preview-environment.md)
+ [Verfügbare PostgreSQL-Datenbankversionen](PostgreSQL.Concepts.General.DBVersions.md)
+ [Grundlegendes zum inkrementellen Versionierungsprozess von RDS für PostgreSQL](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [Unterstützte PostgreSQL-Erweiterungsversionen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [Arbeiten mit PostgreSQL-Funktionen, die von Amazon RDS für PostgreSQL unterstützt werden](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird](USER_ConnectToPostgreSQLInstance.md)
+ [Sichern von Verbindungen zu RDS for PostgreSQL mit SSL/TLS](PostgreSQL.Concepts.General.Security.md)
+ [Verwenden der Kerberos-Authentifizierung mit Amazon RDS für PostgreSQL](postgresql-kerberos.md)
+ [Verwenden eines benutzerdefinierten DNS-Servers für ausgehenden Netzwerkzugriff.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [Upgrades der DB-Engine von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md)
+ [Aktualisieren einer Engine-Version für PostgreSQL-DB-Snapshots](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [Verbesserung der Abfrageleistung für RDS für PostgreSQL mit Amazon-RDS-optimierten Lesevorgängen](USER_PostgreSQL.optimizedreads.md)
+ [Importieren von Daten in PostgreSQL in Amazon RDS](PostgreSQL.Procedural.Importing.md)
+ [Exportieren von Daten aus einem/einer RDS für PostgreSQL-DB-Instance zu Amazon S3](postgresql-s3-export.md)
+ [Aufrufen einer AWS Lambda Funktion aus einem )](PostgreSQL-Lambda.md)
+ [Häufige DBA-Aufgaben für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md)
+ [Optimierung mit Warteereignissen für RDS für PostgreSQL](PostgreSQL.Tuning.md)
+ [Optimierung von RDS für PostgreSQL mit proaktiven Erkenntnissen von Amazon Guru DevOps](PostgreSQL.Tuning_proactive_insights.md)
+ [Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [Arbeiten mit Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension.md)
# Häufige Verwaltungsaufgaben für Amazon RDS for PostgreSQL
Im Folgenden werden die Verwaltungsaufgaben veranschaulicht, die Sie mit einer Amazon RDS for PostgreSQL-DB-Instance am häufigsten durchführen. Bei jeder Aufgabe sind Links zu relevanter Dokumentation enthalten.
| Aufgabenbereich | Relevante Dokumentation |
| --- | --- |
| **Amazon RDS für die Erstanwendung einrichten** Sie müssen einige Voraussetzungen erfüllen, um Ihre DB-Instance erstellen zu können. Beispielsweise werden DB-Instances standardmäßig mit einer Firewall erstellt, die den Zugriff auf die Instance verhindert. Sie müssen also eine Sicherheitsgruppe mit den korrekten IP-Adressen und der Netzwerkkonfiguration erstellen, um auf die DB-Instance zugreifen zu können. | [Einrichten Ihrer Umgebung für Amazon RDS](CHAP_SettingUp.md) |
| **Understanding Amazon RDS DB instances (Grundlagen von Amazon RDS-DB-Instances)** Wenn Sie eine DB-Instance zu Produktionszwecken erstellen, müssen Sie wissen, wie Instance-Klassen, Speichertypen und bereitgestellte IOPS in Amazon RDS funktionieren. | [](Concepts.DBInstanceClass.md) [Amazon-RDS-Speichertypen](CHAP_Storage.md#Concepts.Storage) [Bereitgestellter IOPS SSD-Speicher](CHAP_Storage.md#USER_PIOPS) |
| **Suchen nach verfügbaren PostgreSQL-Versionen** Amazon RDS unterstützt mehrere Versionen von PostgreSQL. | [Verfügbare PostgreSQL-Datenbankversionen](PostgreSQL.Concepts.General.DBVersions.md) |
| **Einrichten von hoher Verfügbarkeit und Failover-Unterstützung** Bei einer DB-Instance für die Produktion sollten Multi-AZ-Bereitstellungen eingesetzt werden. Multi-AZ-Bereitstellungen bieten eine erhöhte Verfügbarkeit, eine längere Lebensdauer von Daten sowie eine höhere Fehlertoleranz für DB-Instances. | [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md) |
| **Grundlegendes zum Amazon Virtual Private Cloud (VPC)-Netzwerk** Wenn Ihr AWS Konto über eine Standard-VPC verfügt, wird Ihre DB-Instance automatisch in der Standard-VPC erstellt. Es kann sein, dass Ihr Konto nicht über eine Standard-VPC verfügt und Sie die DB-Instance in einer VPC erstellen möchten. Erstellen Sie in diesem Fall die VPC und die Subnetzgruppen, bevor Sie die DB-Instance erstellen. | [Arbeiten mit einer DB-Instance in einer VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Importieren von Daten in Amazon RDS PostgreSQL** Für den Import von Daten in Ihre PostgreSQL-DB-Instance in Amazon RDS stehen Ihnen verschiedene Tools zur Verfügung. | [Importieren von Daten in PostgreSQL in Amazon RDS](PostgreSQL.Procedural.Importing.md) |
| **Einrichten schreibgeschützter Read Replicas (primär und Standby)** RDS for PostgreSQL unterstützt Read Replicas sowohl in derselben AWS Region als auch in einer anderen AWS Region als die primäre Instance. | [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md) [Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md) [Erstellen einer Read Replica in einem anderen AWS-Region](USER_ReadRepl.XRgn.md) |
| **Grundlagen zu Sicherheitsgruppen** DB-Instances werden standardmäßig mit einer Firewall erstellt, die den Zugriff auf die Instance verhindert. Um den Zugriff über diese Firewall zu ermöglichen, bearbeiten Sie die eingehenden Regeln für die VPC Sicherheitsgruppe, die mit der VPC verknüpft ist, die die DB-Instance hostet. | [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md) |
| **Einrichten von Parametergruppen und -funktionen** Um die Standardparameter für Ihre DB-Instance zu ändern, erstellen Sie eine benutzerdefinierte DB-Parametergruppe und ändern Sie die Einstellungen darauf. Wenn Sie dies tun, bevor Sie Ihre DB-Instance erstellen, können Sie Ihre benutzerdefinierte DB-Parametergruppe auswählen, wenn Sie die Instance erstellen. | [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md) |
| **Verbinden mit Ihrer PostgreSQL-DB-Instance** Nachdem Sie eine Sicherheitsgruppe erstellt und diese einer DB-Instance zugeordnet haben, können Sie mithilfe einer beliebigen Standard-SQL-Client-Anwendung wie `psql` oder `pgAdmin` eine Verbindung mit dieser DB-Instance herstellen. | [Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird](USER_ConnectToPostgreSQLInstance.md) [Verwenden von SSL mit einer PostgreSQL-DB-Instance](PostgreSQL.Concepts.General.SSL.md) |
| **Sichern und Wiederherstellen Ihrer DB-Instance** Sie können Ihre DB-Instance so konfigurieren, dass sie automatische Backups oder manuelle Snapshots vornimmt. Aus diesen Backups oder Snapshots können Sie dann Instances wiederherstellen. | [Sichern, Wiederherstellen und Exportieren von Daten](CHAP_CommonTasks.BackupRestore.md) |
| **Überwachen der Aktivität und Leistung Ihrer DB-Instance** Sie können eine PostgreSQL-DB-Instance mithilfe von CloudWatch Amazon RDS-Metriken, Ereignissen und erweiterter Überwachung überwachen. | [Anzeigen von Metriken in der Amazon-RDS-Konsole](USER_Monitoring.md) [Anzeigen von Amazon-RDS-Ereignissen](USER_ListEvents.md) |
| **Aktualisieren der PostgreSQL-Datenbankversion** Sie können sowohl Upgrades von Hauptversionen als auch von Nebenversionen Ihrer PostgreSQL-DB-Instance vornehmen. | [Upgrades der DB-Engine von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md) [Auswählen einer Hauptversion für ein Upgrade von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **Arbeiten mit Protokolldateien** Sie können auf die Protokolldateien für Ihre PostgreSQL-DB-Instance zugreifen. | [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md) |
| **Grundlagen der bewährten Methoden für PostgreSQL-DB-Instances** Hier werden einige bewährte Methoden für die Arbeit mit PostgreSQL in Amazon RDS behandelt. | [Bewährte Methoden für die Arbeit mit PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
Im Folgenden finden Sie eine Liste anderer Abschnitte in diesem Leitfaden, die Ihnen helfen können, wichtige Funktionen von RDS for PostgreSQL zu verstehen und zu verwenden:
+ [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Steuern des Benutzerzugriffs auf die PostgreSQL−DatenbankSteuern des Benutzerzugriffs auf PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [Verstehen von Protokollierungsmechanismen, die von RDS for PostgreSQL unterstützt werden](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Verwenden eines benutzerdefinierten DNS-Servers für ausgehenden Netzwerkzugriff.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# Arbeiten mit der Datenbank-Vorschauumgebung
Die PostgreSQL-Community veröffentlicht kontinuierlich neue PostgreSQL-Versionen und -Erweiterungen, einschließlich Beta-Versionen. Dies gibt PostgreSQL-Benutzern die Möglichkeit, eine neue PostgreSQL-Version frühzeitig auszuprobieren. Weitere Informationen zum Beta-Versionsprozess der PostgreSQL-Community finden Sie unter [Beta-Informationen](https://www.postgresql.org/developer/beta/) in der PostgreSQL-Dokumentation. Entsprechend Weise stellt Amazon RDS bestimmte PostgreSQL-Beta-Versionen als Vorschauversionen zur Verfügung. Auf diese Weise können Sie DB-Instances mit der Vorschauversion erstellen und ihre Funktionen in der Datenbank-Preview-Umgebung testen.
DB-Instances von RDS für PostgreSQL in der Datenbank-Preview-Umgebung funktionieren ähnlich wie andere Instances von RDS für PostgreSQL. Sie können eine Vorschauversion jedoch nicht für die Produktion einsetzen.
Beachten Sie folgende wichtige Einschränkungen:
+ Alle DB-Instances werden 60 Tage nach Erstellung zusammen mit allen Backups und Snapshots gelöscht.
+ Sie können eine DB-Instance nur in einer virtuellen privaten Cloud (VPC) erstellen, die auf dem Service Amazon VPC basiert.
+ Sie können nur Allzweck-SSD und bereitgestellte IOPS-SSD als Speicher verwenden.
+ Bei DB-Instances können Sie vom AWS Support keine Hilfe erhalten. [Stattdessen können Sie Ihre Fragen in der von uns AWS verwalteten Q&A-Community re:POST stellen.AWS](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Sie können einen Snapshot einer DB-Instance nicht in eine Produktionsumgebung kopieren.
Die folgenden Optionen werden von der Vorschauversion unterstützt.
+ Sie können nur DB-Instances mit den Instance-Typen M6i, R6i, M6g, M5, T3, R6g und R5 erstellen. Weitere Informationen zu RDS-Instance-Klassen erhalten Sie unter [](Concepts.DBInstanceClass.md).
+ Sie können Single-AZ- und Multi-AZ-Bereitstellungen verwenden.
+ Sie können die standardmäßigen PostgreSQL-Dump- und -Ladefunktionen verwenden, um Datenbanken aus der Database Vorschauumgebung zu exportieren oder in diese zu importieren.
**Topics**
+ [Nicht in der Datenbank-Vorschauumgebung unterstützte Features](#preview-environment-exclusions)
+ [PostgreSQL-Version 17 in der Datenbank-Preview-Umgebung](#PostgreSQL.Concepts.General.version17)
+ [Erstellen einer neuen DB-Instance in der Datenbank-Vorschauumgebung](create-db-instance-in-preview-environment.md)
## Nicht in der Datenbank-Vorschauumgebung unterstützte Features
Die folgenden Features sind in der Datenbank-Vorschauumgebung nicht verfügbar:
+ Regionsübergreifende Snapshot-Kopie
+ Regionsübergreifende Lesereplikate
## PostgreSQL-Version 17 in der Datenbank-Preview-Umgebung
**Anmerkung**
Dies ist eine Vorschaudokumentation für Amazon RDS PostgreSQL Version 17. Änderungen sind vorbehalten.
PostgreSQL Version 17.0 ist jetzt in der Amazon RDS Database Preview-Umgebung verfügbar. PostgreSQL-Version 17.0 enthält mehrere Verbesserungen, die in der folgenden PostgreSQL-Dokumentation beschrieben werden: [PostgreSQL 17 Released](https://www.postgresql.org/docs/17/release-17.html).
Weitere Informationen zur Datenbank-Vorschauumgebung finden Sie unter [Arbeiten mit der Datenbank-Vorschauumgebung](#working-with-the-database-preview-environment). Um von der Konsole aus auf die Vorschau-Umgebung zuzugreifen, wählen Sie. [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/)
# Erstellen einer neuen DB-Instance in der Datenbank-Vorschauumgebung
Erstellen Sie mit dem folgenden Verfahren eine DB-Instance in der Vorschauumgebung.
**So erstellen Sie eine DB-Instance in der Datenbank-Vorschauumgebung**
1. Melden Sie sich bei der an AWS-Managementkonsole und ö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 **Dashboard** aus.
1. Suchen Sie auf Dashboard-Seite nach **Datenbank-Vorschauumgebung**, wie in der folgenden Abbildung gezeigt.
![\[Vorschauumgebung mit dem Link, der in der RDS-Konsole und im Dashboard angezeigt wird\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Sie können auch direkt zu [Datenbank-Preview-Umgebung](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#) navigieren. Bevor Sie fortfahren können, müssen Sie die Einschränkungen bestätigen und akzeptieren.
![\[Dialogfeld „Preview environment limitations“ (Einschränkungen der Vorschauumgebung)\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Wenn Sie die DB-Instance von RDS für PostgreSQL erstellen möchten, gehen Sie genauso vor wie bei der Erstellung einer DB-Instance von Amazon RDS. Weitere Informationen finden Sie im Verfahren [Konsole](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) unter [Erstellen einer DB-Instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
Verwenden Sie den folgenden Endpunkt, um mit der RDS-API oder der AWS CLI eine Instance in der Datenbank-Preview-Umgebung zu erstellen.
```
rds-preview.us-east-2.amazonaws.com
```
# Verfügbare PostgreSQL-Datenbankversionen
Amazon RDS unterstützt DB-Instances für mehrere Editionen von PostgreSQL. Sie können eine beliebige aktuell verfügbare PostgreSQL-Version festlegen, wenn Sie eine DB-Instance erstellen. Sie können die Hauptversionen (z. B. PostgreSQL 14) sowie eine beliebige verfügbare Nebenversion für die angegebene Hauptversion festlegen. Wenn keine Version angegeben wird, verwendet Amazon RDS standardmäßig eine verfügbare Version – in der Regel die aktuelle Version. Wenn die Hauptversion, jedoch nicht die Unterversion, festgelegt ist, verwendet Amazon RDS standardmäßig den letzten Release der Hauptversion, die Sie festgelegt haben.
Verwenden Sie den [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Befehl, um eine Liste der verfügbaren Versionen sowie die Standardeinstellungen für neu erstellte DB-Instances anzuzeigen. Verwenden Sie zum Beispiel den folgenden Befehl, um die Standardversion der PostgreSQL-Engine anzuzeigen:
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Weitere Informationen zu den PostgreSQL-Versionen, die von Amazon RDS unterstützt werden, finden Sie in den [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html). Sie können auch Informationen zu den Support-Daten für wichtige Engine-Versionen anzeigen, indem Sie den AWS CLI Befehl [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) ausführen oder den API-Vorgang [Describe DBMajor EngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS verwenden.
Wenn Sie nicht bereit sind, vor dem Ende des RDS-Standard-Supports manuell auf eine neue Engine-Hauptversion zu aktualisieren, registriert Amazon RDS Ihre Datenbanken nach dem Ende des RDS-Standard-Supports automatisch bei Amazon RDS Extended Support. Anschließend können Sie weiterhin RDS für PostgreSQL Version 11 und höher ausführen. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon RDS](extended-support.md) und [Amazon RDS – Preise](https://aws.amazon.com/rds/pricing/).
## Veraltete Versionen für Amazon RDS for PostgreSQL
Beachten Sie die folgenden veralteten Versionen:
+ RDS für PostgreSQL 10 wurde im Februar 2023 eingestellt.
+ RDS für PostgreSQL 9.6 wurde im März 2022 eingestellt.
+ RDS für PostgreSQL 9.5 wurde im März 2021 eingestellt.
[Weitere Informationen über die Verfallsrichtlinie für RDS for PostgreSQL finden Sie unter Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/) Weitere Informationen zu PostgreSQL-Versionen finden Sie unter [Versioning-Richtlinie](https://www.postgresql.org/support/versioning/) in der PostgreSQL-Dokumentation.
# Grundlegendes zum inkrementellen Versionierungsprozess von RDS für PostgreSQL
RDS für PostgreSQL bietet Sicherheitskorrekturen, Leistungsverbesserungen und neue Funktionen in Form von inkrementellen Versionen, wobei die Kompatibilität der Unterversionen gewahrt bleibt. Diese Versionen sind als R1, R2, R3 usw. gekennzeichnet.
**Benennungskonvention für veröffentlichte Versionen**
+ Die erste Version einer Unterversion ist R1. Gelegentlich beinhaltet sie neue Funktionen, Erweiterungen oder Upgrades vorhandener Erweiterungen.
+ Die nachfolgenden veröffentlichten Versionen (R2, R3 und höher) umfassen:
+ Sicherheits-Updates
+ Leistungsverbesserungen
+ Bugfixes
+ Aktualisierungen der Erweiterungen
## Vorteile des inkrementellen Versionierungsprozesses von RDS für PostgreSQL
Der inkrementelle Versionierungsprozess bietet die folgenden Vorteile:
+ Schnelle Einführung neuer Versionen der PostgreSQL-Community bei gleichzeitiger getrennter Verwaltung von RDS-spezifischen Verbesserungen für nachfolgende Versionen. Hierdurch wird der Versionierungsprozess rationalisiert und eine schnellere Bereitstellung kritischer Updates gewährleistet.
+ Zugriff auf Bugfixes, neue Funktionen, Sicherheits-Updates und Aktualisierungen der Erweiterungen, wobei die Kompatibilität mit der PostgreSQL-Unterversion gewahrt bleibt.
## Verwalten der Versions-Updates
Amazon RDS informiert Sie über neue inkrementelle Versionen durch ausstehende Wartungsaktionen in der AWS-Managementkonsole. Sie können Ihre Datenbank mit einer der folgenden Methoden aktualisieren:
+ Aktivieren Sie automatische Updates während der geplanten Wartungsfenster.
+ Wenden Sie Updates manuell im Rahmen ausstehender Wartungsaktionen an.
+ Verwenden Sie Blue/Green Bereitstellungen mit physischer Replikation, um Ausfallzeiten zu minimieren. Weitere Informationen finden Sie unter [Blau/Grün-Bereitstellungen unterstützen Unterversions-Upgrades von RDS für PostgreSQL](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/).
Berücksichtigen Sie vor dem Aktualisieren Ihrer Datenbank die folgenden wichtigen Punkte:
+ Nach Aktualisierungen muss die Datenbank neu gestartet werden, es sei denn, Sie verwenden Blau/Grün-Bereitstellungen mit physischer Replikation.
+ Einige inkrementelle Versionen sind obligatorisch, insbesondere solche, die Sicherheitskorrekturen enthalten.
Weitere Informationen zur Aktualisierung Ihrer Amazon RDS-DB-Instance finden Sie unter [Vertrauenswürdige Erweiterungen für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted) und [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html).
# Unterstützte PostgreSQL-Erweiterungsversionen
RDS für PostgreSQL unterstützt viele PostgreSQL-Erweiterungen. Die PostgreSQL-Community bezeichnet diese manchmal als Module. Erweiterungen bauen auf der von der PostgreSQL-Engine bereitgestellten Funktionalität auf. Darüber hinaus finden Sie eine Liste der von Amazon RDS unterstützten Erweiterungen in der Standard-DB-Parametergruppe für diese PostgreSQL-Version. Sie können sich auch die Liste der aktuellen Erweiterungen ansehen, wenn Sie `psql` verwenden, indem Sie den Parameter `rds.extensions` anzeigen, wie im folgenden Beispiel.
```
SHOW rds.extensions;
```
**Anmerkung**
Parameter, die in einer älteren Version hinzugefügt wurden, werden möglicherweise nicht richtig dargestellt, wenn der Parameter `rds.extensions` in `psql` verwendet wird.
Ab RDS für PostgreSQL 13 können bestimmte Erweiterungen von anderen Datenbankbenutzern als dem`rds_superuser`. Diese sind bekannt als*vertrauenswürdige Erweiterungen*. Weitere Informationen hierzu finden Sie unter [Vertrauenswürdige Erweiterungen für PostgreSQL](#PostgreSQL.Concepts.General.Extensions.Trusted).
Bestimmte Versionen von RDS für PostgreSQL unterstützen`rds.allowed_extensions`-Parameter. Mit diesem Parameter kann ein`rds_superuser`Beschränken Sie die Erweiterungen, die in der RDS-forPostgreSQL-DB-Instance installiert werden können. Weitere Informationen finden Sie unter [Beschränkung der Installation von PostgreSQL-Erweiterungen](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Eine Liste der PostgreSQL-Erweiterungen und Versionen, die von jeder verfügbaren Version von RDS für PostgreSQL unterstützt werden, finden Sie unter PostgreSQL-Erweiterungen, die auf Amazon RDS unterstützt werden, in den [Amazon RDS für PostgreSQL Release Notes](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
## Beschränkung der Installation von PostgreSQL-Erweiterungen
Sie können einschränken, welche Erweiterungen auf einer PostgreSQL-DB-Instance installiert werden können. Standardmäßig ist dieser Parameter nicht festgelegt, daher kann jede unterstützte Erweiterung hinzugefügt werden, wenn der Benutzer dazu berechtigt ist. Setzen Sie dazu den `rds.allowed_extensions`-Parameter auf eine Zeichenfolge von kommagetrennten Erweiterungsnamen. Indem Sie diesem Parameter eine Liste von Erweiterungen hinzufügen, identifizieren Sie explizit die Erweiterungen, die Ihre DB-Instance von RDS für PostgreSQL verwenden kann. Nur diese Erweiterungen können dann in der PostgreSQL-DB-Instance installiert werden.
Die Standardzeichenfolge für den `rds.allowed_extensions`-Parameter ist '\$1', was bedeutet, dass jede für die Engine-Version verfügbare Erweiterung installiert werden kann. Das Ändern des `rds.allowed_extensions`-Parameters erfordert keinen Neustart der Datenbank, da es sich um einen dynamischen Parameter handelt.
Die PostgreSQL-DB-Instance-Engine muss eine der folgenden Versionen sein, damit Sie den `rds.allowed_extensions`-Parameter verwenden können:
+ Alle PostgreSQL 16-Versionen
+ PostgreSQL 15 und alle höheren Versionen
+ PostgreSQL 14 und alle höheren Versionen
+ PostgreSQL 13.3 und höhere Nebenversionen
+ PostgreSQL 12.7 und höhere Nebenversionen
Verwenden Sie den folgenden psql-Befehl, um zu sehen, welche Erweiterungsinstallationen zulässig sind.
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
Wenn eine Erweiterung in der Liste im `rds.allowed_extensions`-Parameter installiert wurde, bevor sie ausgelassen wurde, kann die Erweiterung weiterhin normal verwendet werden, und Befehle wie `ALTER EXTENSION` und `DROP EXTENSION` funktionieren weiter. Nachdem eine Erweiterung jedoch eingeschränkt wurde, schlagen die `CREATE EXTENSION`-Befehle für die eingeschränkte Erweiterung fehl.
Die Installation von Erweiterungsabhängigkeiten mit `CREATE EXTENSION CASCADE` ist ebenfalls eingeschränkt. Die Erweiterung und ihre Abhängigkeiten müssen in angegeben werde `rds.allowed_extensions`. Wenn eine Installation der Erweiterungsabhängigkeit fehlschlägt, schlägt die gesamte `CREATE EXTENSION CASCADE`-Anweisung fehl.
Wenn eine Erweiterung nicht im `rds.allowed_extensions`-Parameter enthalten ist, wird ein Fehler wie der folgende angezeigt, wenn Sie versuchen, sie zu installieren.
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## Vertrauenswürdige Erweiterungen für PostgreSQL
Um die meisten PostgreSQL-Erweiterungen zu installieren, sind `rds_superuser`-Berechtigungen erforderlich. PostgreSQL 13 führte vertrauenswürdige Erweiterungen ein, die die Notwendigkeit der Gewährung von `rds_superuser`-Berechtigungen für normale Benutzer reduziert. Mit dieser Funktion können Benutzer viele Erweiterungen installieren, wenn sie über die `CREATE` -Berechtigung für die aktuelle Datenbank anstatt der `rds_superuser`-Rolle verfügen. Weitere Informationen finden Sie im SQL-Befehl [ERWEITERUNG ERSTELLEN](https://www.postgresql.org/docs/current/sql-createextension.html) in der PostgreSQL-Dokumentation.
Im Folgenden werden die Erweiterungen aufgeführt, die von einem Benutzer installiert werden können, der über die `CREATE`-Berechtigung für die aktuelle Datenbank verfügt und die `rds_superuser`-Rolle nicht benötigt:
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext](http://www.postgresql.org/docs/current/citext.html)
+ [cube](http://www.postgresql.org/docs/current/cube.html)
+ [dict\$1int](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
Eine Liste der PostgreSQL-Erweiterungen und Versionen, die von jeder verfügbaren RDS für PostgreSQL-Version unterstützt werden, finden Sie unter PostgreSQL-Erweiterungen, die auf Amazon RDS unterstützt werden, in den [Amazon RDS für PostgreSQL Release Notes](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
# Arbeiten mit PostgreSQL-Funktionen, die von Amazon RDS für PostgreSQL unterstützt werden
Amazon RDS für PostgreSQL unterstützt viele der am häufigsten verwendeten PostgreSQL-Funktionen. PostgreSQL verfügt beispielsweise über eine Selbstbereinigungsfunktion, die die routinemäßige Wartung der Datenbank durchführt. Die Autovakuierungsfunktion ist standardmäßig aktiviert. Obwohl Sie diese Funktion deaktivieren können, empfehlen wir dringend, sie eingeschaltet zu lassen. Diese Funktion zu verstehen und was Sie tun können, um sicherzustellen, dass sie so funktioniert, wie sie sollte, ist eine grundlegende Aufgabe eines jeden DBA. Weitere Informationen zur Selbstbereinigung finden Sie unter [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Weitere Informationen zu anderen gängigen DBA-Aufgaben finden Sie unter [Häufige DBA-Aufgaben für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md).
RDS für PostgreSQL unterstützt auch Erweiterungen, die der DB-Instance wichtige Funktionen hinzufügen. Sie können beispielsweise die PostGIS-Erweiterung verwenden, um mit räumlichen Daten zu arbeiten, oder die Erweiterung pg\$1cron verwenden, um die Wartung innerhalb der Instance zu planen. Weitere Informationen zu PostgreSQL-Erweiterungen finden Sie unter [Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md).
Fremddaten-Wrapper sind eine bestimmte Art von Erweiterung, die dazu dient, dass Ihre DB-Instance von RDS für PostgreSQL mit anderen kommerziellen Datenbanken oder Datentypen arbeiten kann. Weitere Informationen zu Fremddaten-Wrappern, die von RDS für PostgreSQL unterstützt werden, finden Sie unter [Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
Nachfolgend finden Sie Informationen über einige andere Funktionen, die von RDS für PostgreSQL unterstützt werden.
**Topics**
+ [Benutzerdefinierte Datentypen und Aufzählungen mit RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [Ereignisauslöser für RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [Huge Pages für RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [Ausführen der logischen Replikation für Amazon RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [RAM-Datenträger für das stats\$1temp\$1directory](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [Tablespaces für RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [RDS-für-PostgreSQL-Kollatierungen für EBCDIC- und andere Mainframe-Migrationen](PostgreSQL.Collations.mainframe.migration.md)
+ [Verwalten der logischen Slot-Synchronisation für RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# Benutzerdefinierte Datentypen und Aufzählungen mit RDS for PostgreSQL
PostgreSQL unterstützt das Erstellen benutzerdefinierter Datentypen und das Arbeiten mit Aufzählungen. Weitere Informationen zum Erstellen von und zum Arbeiten mit Aufzählungen und anderen Datentypen finden Sie unter [Enumerated types](https://www.postgresql.org/docs/14/datatype-enum.html) (Aufzählungstypen) in der PostgreSQL-Dokumentation.
Im Folgenden finden Sie ein Beispiel für das Erstellen eines Typs als Aufzählung und das anschließende Einfügen von Werten in eine Tabelle.
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# Ereignisauslöser für RDS for PostgreSQL
Alle aktuellen PostgreSQL-Versionen unterstützen Ereignisauslöser, ebenso alle verfügbaren Versionen von RDS for PostgreSQL. Sie können das Hauptbenutzerkonto nutzen (Standard, `postgres`), um Ereignisauslöser zu erstellen, zu ändern, umzubenennen und zu löschen. Ereignisauslöser befinden sich auf DB-Instance-Level und können so auf alle Datenbanken einer Instance angewendet werden.
Mit dem folgenden Code wird beispielsweise ein Ereignisauslöser erstellt, der den aktuellen Benutzer am Ende jedes DDL-Befehls (Data Definition Language, Datendefinitionssprache) ausgibt.
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
Weitere Informationen über PostgreSQL-Ereignisauslöser finden Sie unter [Event Triggers](https://www.postgresql.org/docs/current/static/event-triggers.html) in der PostgreSQL-Dokumentation.
Bei der Verwendung von PostgreSQL-Ereignisauslösern in Amazon RDS gibt es einige Einschränkungen. Diese umfassen u. a. folgende:
+ Auf Read Replicas können keine Ereignisauslöser erstellt werden. Sie können jedoch Ereignisauslöser auf einer Read Replica-Quelle erstellen. Die Ereignisauslöser werden dann in die Read Replica kopiert. Die Ereignisauslöser auf der Read Replica werden nicht bei Änderungen, die von der Quelle ausgehen, ausgelöst. Wenn jedoch die Read Replica verwendet wird, werden die vorhandenen Ereignisauslöser bei Datenbank-Operationen ausgelöst.
+ Um das Upgrade einer Hauptversion für eine PostgreSQL-DB-Instance durchzuführen, für die ein Ereignisauslöser verwendet wird, müssen Sie vor dem Upgraden der Instance die Ereignisauslöser löschen.
# Huge Pages für RDS für PostgreSQL
*Huge Pages* ist eine Arbeitsspeicher-Verwaltungsfunktion, die den Overhead reduziert, wenn eine DB-Instance mit großen, zusammenhängenden Arbeitsspeicherblöcken arbeitet, wie sie von gemeinsam genutzten Puffern verwendet werden. Diese PostgreSQL-Funktion wird von allen derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützt. Sie können große Seiten für Ihre Anwendung zuordnen, indem Sie Aufrufe des freigegebenen Speichers `mmap` oder `SYSV` verwenden. RDS für PostgreSQL unterstützt Seitengrößen von sowohl 4 KB als auch 2 MB.
Sie können Huge Pages ein- oder ausschalten, indem Sie den Wert des `huge_pages`-Parameters ändern. Die Funktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium.
RDS für PostgreSQL verwendet Huge Pages basierend auf dem verfügbaren gemeinsam genutzten Arbeitsspeicher. Wenn die DB-Instance aufgrund von Einschränkungen des gemeinsam genutzten Speichers keine großen Seiten verwenden kann, hindert Amazon RDS die DB-Instance am Starten. In diesem Fall legt Amazon RDS den Status der DB-Instance auf einen nicht kompatiblen Parameterstatus fest. In diesem Fall können Sie den Parameter `huge_pages` auf `off` setzen, sodass Amazon RDS die DB-Instance starten kann.
Der Parameter `shared_buffers` ist wichtig für die Einstellung des gemeinsam genutzten Speicherpools, der für die Verwendung von großen Seiten erforderlich ist. Der Standardwert für den `shared_buffers`-Parameter verwendet ein Makro für Datenbankparameter. Dieses Makro legt einen Prozentsatz der insgesamt verfügbaren 8 KB an Seiten fest, die für den Speicher der DB-Instance verfügbar sind, verfügbar. Wenn Sie riesige Seiten verwenden, werden diese Seiten in den riesigen Seiten zusammengefasst zugeordnet. Amazon RDS versetzt eine DB-Instance in einen inkompatiblen Parameterstatus, wenn die Parameter für den gemeinsam genutzten Speicher so eingestellt sind, dass sie mehr als 90 Prozent des DB-Instance-Speichers benötigen.
Weitere Informationen zur PostgreSQL-Arbeitsspeicherverwaltung finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
# Ausführen der logischen Replikation für Amazon RDS für PostgreSQL
Ab Version 10.4 unterstützt RDS für PostgreSQL die Veröffentlichung und das Abonnement von SQL-Syntax, die erstmals in PostgreSQL 10 eingeführt wurde. Weitere Informationen finden Sie unter [Logische Replikation](https://www.postgresql.org/docs/current/logical-replication.html) in der PostgreSQL-Dokumentation.
**Anmerkung**
Zusätzlich zu der in PostgreSQL 10 eingeführten nativen logischen Replikationsfunktion von PostgreSQL unterstützt RDS für PostgreSQL auch die `pglogical`-Erweiterung. Weitere Informationen finden Sie unter [Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Im Folgenden erfahren Sie, wie Sie die logische Replikation für eine DB-Instance von RDS für PostgreSQL einrichten.
**Topics**
+ [Verständnis der logischen Replikation und logischen Decodierung](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [Arbeiten mit logischen Replikations-Slots](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [Replizieren von Daten auf Tabellenebene mithilfe logischer Replikation](#PostgreSQL.Concepts.LogicalReplication.Tables)
## Verständnis der logischen Replikation und logischen Decodierung
RDS für PostgreSQL unterstützt das Streaming von Write-Ahead-Log(WAL)-Änderungen mithilfe der Slots für logische Replikation von PostgreSQL. Es unterstützt auch die Verwendung logischer Decodierung. Sie können logische Replikations-Slots in Ihrer Instance einrichten und über diese Slots Datenbankänderungen auf einen Client wie z. B. streame `pg_recvlogical`. Sie erstellen logische Replikationsslots auf Datenbankebene, die Replikationsverbindungen zu einer einzelnen Datenbank unterstützen.
Die gängigsten Clients für die logische PostgreSQL-Replikation sind AWS Database Migration Service oder ein individuell verwalteter Host auf einer Amazon EC2 EC2-Instance. Der logische Replikations-Slot enthält keine Informationen über den Empfänger des Streams. Es gibt auch keine Anforderung, dass das Ziel eine Replikatdatenbank sein muss. Wenn beim Einrichten eines Slots für die logische Replikation nicht vom Slot gelesen wird, können Daten in den Speicher Ihrer DB-Instance geschrieben werden und diesen schnell füllen.
Sie aktivieren die logische Replikation und die logische Decodierung PostgreSQL für Amazon RDS durch einen Parameter, einen neuen Replikationsverbindungstyp sowie eine Sicherheitsrolle. Beim Client für die logische Decodierung kann es sich um jeden beliebigen Client handeln, der eine Replikationsverbindung zu einer Datenbank in einer PostgreSQL-DB-Instance herstellen kann.
**Logische Decodierung für eine DB-Instance von RDS für PostgreSQL aktivieren**
1. Stellen Sie sicher, dass das Benutzerkonto, das Sie verwenden, folgende Rollen hat:
+ Die `rds_superuser`-Rolle, damit Sie die logische Replikation aktivieren können
+ Die `rds_replication`-Rolle erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots
1. Setzen Sie den statischen Parameter `rds.logical_replication` auf 1. Setzen Sie bei der Anwendung dieses Parameters auch die Parameter `wal_level`, `max_wal_senders`, `max_replication_slots` und `max_connections` fest. Diese Änderungen an den Parametern können die WAL-Generierung steigern, legen Sie daher den Parameter `rds.logical_replication` nur dann fest, wenn Sie logische Slots verwenden.
1. Starten Sie die DB-Instance neu, damit der statische Parameter `rds.logical_replication` in Kraft tritt.
1. Erstellen Sie einen logischen Replikationsslot wie im nächsten Abschnitt erläutert. Für diesen Prozess ist es erforderlich, dass Sie ein Decodier-Plugin angeben. Derzeit unterstützt RDS für PostgreSQL die test\$1decoding- und wal2json-Ausgabe-Plugins, die mit PostgreSQL geliefert werden.
Weitere Informationen zur logischen Decodierung mit PostgreSQL finden Sie in der [ PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html).
## Arbeiten mit logischen Replikations-Slots
Sie können SQL-Befehle verwenden, um mit logischen Slots zu arbeiten. Beispiel: Der folgende Befehl erstellt einen logischen Slot mit dem Namen `test_slot` unter Verwendung des standardmäßigen Ausgangs-Plugin `test_decoding` von PostgreSQL.
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
Mit dem folgenden Befehl können Sie die logischen Slots auflisten.
```
SELECT * FROM pg_replication_slots;
```
Mit dem folgenden Befehl können Sie einen logischen Slot entfernen.
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
Weitere Beispiele zum Arbeiten mit logischen Replikations-Slots finden Sie unter [ Logical Decoding Examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) in der PostgreSQL-Dokumentation.
Sobald Sie den logischen Replikationsslot erstellt haben, können Sie mit dem Streaming beginnen. Das folgende Beispiel zeigt, wie die logische Decodierung über das Streaming-Replikationsprotokoll gesteuert wird. Dieses Beispiel verwendet das Programm pg\$1recvlogical, das in der PostgreSQL-Distribution enthalten ist. Dazu muss die Client-Authentifizierung so eingerichtet sein, dass Replikationsverbindungen zugelassen werden.
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
Fragen Sie die Funktion `pg_replication_origin_status` ab, um den Inhalt der `pg_show_replication_origin_status` Ansicht anzuzeigen.
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## Replizieren von Daten auf Tabellenebene mithilfe logischer Replikation
Sie können die logische Replikation verwenden, um Daten aus Quelltabellen in Zieltabellen von RDS für PostgreSQL zu replizieren. Bei der logischen Replikation werden zunächst vorhandene Daten aus den Quelltabellen geladen und anschließend die laufenden Änderungen weiterhin repliziert.
1.
**Erstellen der Quelltabellen**
Stellen Sie eine Verbindung mit Ihrer Quelldatenbank in der DB-Instance von RDS für PostgreSQL her.
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**Einfügen der Daten in die Quelltabellen**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**Erstellen einer Publikation für Quelltabellen**
+ Erstellen Sie eine Publikation für die Quelltabellen:
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ Verwenden Sie eine SELECT-Abfrage, um die Details der erstellten Publikation zu überprüfen:
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ Vergewissern Sie sich, dass die Quelltabellen zur Publikation hinzugefügt wurden:
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ Um alle Tabellen in einer Datenbank zu replizieren, verwenden Sie Folgendes:
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ Wenn die Publikation bereits für eine einzelne Tabelle erstellt wurde und Sie eine neue Tabelle hinzufügen müssen, können Sie die folgende Abfrage ausführen, um der vorhandenen Publikation beliebige neue Tabellen hinzuzufügen:
```
ALTER PUBLICATION add table ;
```
1.
**Herstellen einer Verbindung mit der Zieldatenbank und Erstellen von Zieltabellen**
+ Stellen Sie eine Verbindung mit der Zieldatenbank in der Ziel-DB-Instance her. Erstellen Sie die Zieltabellen mit denselben Namen wie die Quelltabellen:
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ Vergewissern Sie sich, dass in den Zieltabellen keine Daten vorhanden sind, indem Sie eine SELECT-Abfrage für die Zieltabellen ausführen:
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**Erstellen und Überprüfen des Abonnements in der Zieldatenbank**
+ Erstellen Sie das Abonnement in der Zieldatenbank:
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ Verwenden Sie eine SELECT-Abfrage, um zu überprüfen, ob das Abonnement aktiviert ist:
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ Wenn das Abonnement erstellt wird, werden alle Daten von den Quelltabellen in die Zieltabellen geladen. Führen Sie eine SELECT-Abfrage für die Zieltabellen aus, um zu überprüfen, ob die ursprünglichen Daten geladen werden:
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**Überprüfen des Replikations-Slots in der Quelldatenbank**
Durch die Erstellung eines Abonnements in der Zieldatenbank wird ein Replikations-Slot in der Quelldatenbank erstellt. Überprüfen Sie die Details des Replikations-Slots, indem Sie die folgende SELECT-Abfrage für die Quelldatenbank ausführen:
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**Testen der Replikation**
+ Testen Sie, ob Datenänderungen in den Quelltabellen in die Zieltabellen repliziert werden, indem Sie folgende Zeilen in die Quelltabellen einfügen:
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ Überprüfen Sie die Anzahl der Zeilen in den Zieltabellen, um sicherzustellen, dass neu eingefügte Daten repliziert werden:
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**Aktualisieren des Abonnements nach dem Hinzufügen von Tabellen**
+ Wenn Sie einer vorhandenen Publikation neue Tabellen hinzufügen, muss das Abonnement unbedingt aktualisiert werden, damit die Änderungen wirksam werden:
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ Mit diesem Befehl werden fehlende Tabelleninformationen vom Publisher abgerufen und die Replikation für Tabellen gestartet, die seit der Erstellung oder letzten Aktualisierung des Abonnements zu den abonnierten Publikationen hinzugefügt wurden.
# Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen
Ab RDS für PostgreSQL, Versionen 11 und höher, können Sie die AWS Identity and Access Management (IAM-) Authentifizierung für Replikationsverbindungen verwenden. Diese Funktion erhöht die Sicherheit, da Sie den Datenbankzugriff mithilfe von IAM-Rollen anstelle von Kennwörtern verwalten können. Sie funktioniert sowohl bei der Cluster- als auch bei der Instance-Granularität und folgt demselben Sicherheitsmodell wie die Standard-IAM-Authentifizierung.
Die IAM-Authentifizierung für Replikationsverbindungen ist eine optionale Funktion. Um sie zu aktivieren, setzen Sie den `rds.iam_auth_for_replication` Parameter in Ihrem DB-Cluster oder Ihrer DB-Parametergruppe auf 1. Da es sich um einen dynamischen Parameter handelt, muss Ihr DB-Cluster oder Ihre Instance nicht neu gestartet werden, sodass Sie die IAM-Authentifizierung für bestehende Workloads ohne Ausfallzeiten nutzen können. Bevor Sie diese Funktion aktivieren können, müssen Sie die unten aufgeführten Voraussetzungen erfüllen.
**Topics**
+ [Voraussetzungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [Aktivieren der IAM-Authentifizierung für Replikationsverbindungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [Deaktivierung der IAM-Authentifizierung für Replikationsverbindungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [Einschränkungen und Überlegungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## Voraussetzungen
Um die IAM-Authentifizierung für Replikationsverbindungen verwenden zu können, müssen Sie alle der folgenden Anforderungen erfüllen:
+ Ihre RDS for PostgreSQL-DB-Instance muss Version 11 oder höher sein.
+ Gehen Sie auf Ihrer Publisher-DB-Instance RDS for PostgreSQL wie folgt vor:
+ Aktivieren Sie die IAM-Datenbankauthentifizierung. Weitere Informationen finden Sie unter [Aktivieren und Deaktivieren der IAM-Datenbank-Authentifizierung](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Aktivieren Sie die logische Replikation, indem Sie den `rds.logical_replication` Parameter auf 1 setzen.
Bei der logischen Replikation ist der Herausgeber die Quell-RDS-Datenbank für PostgreSQL, die Daten an die Abonnentendatenbank sendet. Weitere Informationen finden Sie unter [Ausführen der logischen Replikation für Amazon RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
**Anmerkung**
Sowohl die IAM-Authentifizierung als auch die logische Replikation müssen auf Ihrer Publisher-RDS für PostgreSQL-DB-Instance aktiviert sein. Wenn eine der beiden Optionen nicht aktiviert ist, können Sie die IAM-Authentifizierung nicht für Replikationsverbindungen verwenden.
## Aktivieren der IAM-Authentifizierung für Replikationsverbindungen
Gehen Sie wie folgt vor, um die IAM-Authentifizierung für die Replikationsverbindung zu aktivieren.
**Um die IAM-Authentifizierung für Replikationsverbindungen zu aktivieren**
1. Stellen Sie sicher, dass Ihr RDS for PostgreSQL-DB-Cluster oder Ihre Instance alle Voraussetzungen für die IAM-Authentifizierung mit Replikationsverbindungen erfüllt. Details hierzu finden Sie unter [Voraussetzungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites).
1. Konfigurieren Sie den `rds.iam_auth_for_replication` Parameter basierend auf Ihrem RDS for PostgreSQL-Setup:
+ Für RDS for PostgreSQL-DB-Instances: Ändern Sie Ihre DB-Parametergruppe.
+ Für Multi-AZ-Cluster: Ändern Sie Ihre DB-Cluster-Parametergruppe.
Auf 1 `rds.iam_auth_for_replication` setzen. Dies ist ein dynamischer Parameter, der sofort wirksam wird, ohne dass ein Neustart erforderlich ist.
**Anmerkung**
Multi-AZ-Cluster verwenden nur DB-Cluster-Parametergruppen. Einzelne Instance-Parametergruppen können in Multi-AZ-Clustern nicht geändert werden.
1. Connect zu Ihrer Datenbank her und weisen Sie Ihrem Replikationsbenutzer die erforderlichen Rollen zu:
Die folgenden SQL-Befehle gewähren die erforderlichen Rollen, um die IAM-Authentifizierung für Replikationsverbindungen zu aktivieren:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Nachdem Sie diese Schritte abgeschlossen haben, muss der angegebene Benutzer die IAM-Authentifizierung für Replikationsverbindungen verwenden.
**Wichtig**
Wenn Sie die Funktion aktivieren, müssen Benutzer mit `rds_replication` Rollen `rds_iam` sowohl als auch die IAM-Authentifizierung für Replikationsverbindungen verwenden. Dies gilt unabhängig davon, ob die Rollen dem Benutzer direkt zugewiesen oder über andere Rollen vererbt wurden.
## Deaktivierung der IAM-Authentifizierung für Replikationsverbindungen
Sie können die IAM-Authentifizierung für Replikationsverbindungen mit einer der folgenden Methoden deaktivieren:
+ Setzen Sie den `rds.iam_auth_for_replication` Parameter in Ihrer DB-Parametergruppe für DB-Instances oder in der DB-Cluster-Parametergruppe für Multi-AZ-Cluster auf 0.
+ Alternativ können Sie eine dieser Funktionen in Ihrem RDS for PostgreSQL-DB-Cluster oder Ihrer Instance deaktivieren:
+ Deaktivieren Sie die logische Replikation, indem Sie den `rds.logical_replication` Parameter auf 0 setzen
+ Deaktivieren Sie die IAM-Authentifizierung
Wenn Sie die Funktion deaktivieren, können Replikationsverbindungen Datenbankkennwörter zur Authentifizierung verwenden.
**Anmerkung**
Replikationsverbindungen für Benutzer ohne die `rds_iam` Rolle können die Kennwortauthentifizierung verwenden, auch wenn die Funktion aktiviert ist.
## Einschränkungen und Überlegungen
Beachten Sie bei der Verwendung der IAM-Authentifizierung für logische Replikationsverbindungen die folgenden Einschränkungen und Überlegungen:
+ Diese Funktion ist nur für RDS für PostgreSQL Version 11 und höher verfügbar.
+ Der Herausgeber muss die IAM-Authentifizierung für Replikationsverbindungen unterstützen.
+ Das IAM-Authentifizierungstoken läuft standardmäßig nach 15 Minuten ab. Möglicherweise müssen Sie lang andauernde Replikationsverbindungen aktualisieren, bevor das Token abläuft.
# RAM-Datenträger für das stats\$1temp\$1directory
Sie können den Parameter `rds.pg_stat_ramdisk_size` von RDS für PostgreSQL verwenden, um den Systemspeicher festzulegen, der einer RAM-Disk zur Speicherung von PostgreSQL-`stats_temp_directory` zugewiesen ist. Der RAM-Disk-Parameter ist nur für RDS für PostgreSQL 14 und frühere Versionen verfügbar.
Bei bestimmten Workloads kann die Einstellung dieses Parameters die Leistung verbessern und die I/O Anforderungen verringern. Weitere Informationen zur Verwendung von `stats_temp_directory` finden Sie in der [ PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY).
Wenn Sie einen RAM-Datenträger für Ihr `stats_temp_directory` einrichten möchten, legen Sie den Parameter `rds.pg_stat_ramdisk_size` in der von Ihrer DB-Instance verwendeten Parametergruppe auf einen literalen Ganzzahlwert fest. Dieser Parameter wird in MB angegeben, daher müssen Sie einen ganzzahligen Wert verwenden. Ausdrücke, Formeln und Funktionen sind für den Parameter `rds.pg_stat_ramdisk_size` nicht gültig. Starten Sie die DB-Instance neu, damit die Änderung wirksam wird. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Mit dem folgenden AWS CLI Befehl wird beispielsweise der RAM-Disk-Parameter auf 256 MB festgelegt.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
Nach dem Neustart führen Sie den folgenden Befehl aus, um den Status des `stats_temp_directory` anzuzeigen:
```
postgres=> SHOW stats_temp_directory;
```
Der Befehl sollte Folgendes zurückgeben.
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# Tablespaces für RDS for PostgreSQL
RDS for PostgreSQL unterstützt Tablespaces aus Kompatibilitätsgründen. Da sich der gesamte Speicher auf einem einzigen logischen Volume befindet, können Sie Tablespaces nicht zum I/O Teilen oder Isolieren verwenden. Unsere Benchmarks und Erfahrung zeigen, dass ein einzelnes logisches Volume für die meisten Anwendungsfälle das beste Setup ist.
Um Tablespaces mit Ihrer DB-Instance von RDS for PostgreSQL zu erstellen und zu verwenden, benötigen Sie die `rds_superuser`-Rolle. Das Hauptbenutzerkonto (Standardname, `postgres`) Ihrer DB-Instance von RDS for PostgreSQL ist Mitglied dieser Rolle. Weitere Informationen finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Wenn Sie beim Erstellen eines Tablespace einen Dateinamen angeben, lautet das Pfadpräfix `/rdsdbdata/db/base/tablespace`. Im folgenden Beispiel werden Tablespace-Dateien in abgeleg `/rdsdbdata/db/base/tablespace/data`. In diesem Beispiel wird angenommen, dass ein `dbadmin`-Benutzer (Rolle) existiert und ihm die `rds_superuser`-Rolle gewährt wurde, die zur Arbeit mit Tablespaces benötigt wird.
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
Weitere Informationen zu PostgreSQL-Tablespaces finden Sie unter [Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) in der PostgreSQL-Dokumentation.
# RDS-für-PostgreSQL-Kollatierungen für EBCDIC- und andere Mainframe-Migrationen
RDS-für-PostgreSQL-Versionen 10 und höher enthalten die ICU-Version 60.2, die auf Unicode 10.0 basiert und Kollationen aus dem Unicode Common Locale Data Repository, CLDR 32, enthält. Diese Software-Internationalisierungsbibliotheken stellen sicher, dass Zeichenkodierungen unabhängig vom Betriebssystem oder der Plattform einheitlich dargestellt werden. Weitere Informationen zu Unicode CLDR-32 finden Sie unter[CLDR 32 Versionshinweis](https://cldr.unicode.org/index/downloads/cldr-32)auf der Unicode CLDR-Website. Mehr über die Internationalisierungskomponenten für Unicode (ICU) erfahren Sie auf der[Technischer Ausschuss der Intensivstation (ICU-TC)](https://icu.unicode.org/home)Webseite. Hinweise zu ICU-60 finden Sie unter[Laden Sie ICU 60 herunter](https://icu.unicode.org/download/60).
Ab Version 14.3 umfasst RDS für PostgreSQL auch Kollatierungen, die bei der Datenintegration und Konvertierung von EBCDC-basierten Systemen helfen. Der erweiterte binär codierte Dezimalaustauschcode oder*EBCDIC*Encoding wird häufig von Mainframe-Betriebssystemen verwendet. Diese von Amazon RDS bereitgestellten Sortierungen sind eng definiert, um nur die Unicode-Zeichen zu sortieren, die direkt EBCDIC-Codepages zugeordnet sind. Die Zeichen werden in EBCDIC-Codepunktreihenfolge sortiert, um eine Datenvalidierung nach der Konvertierung zu ermöglichen. Diese Sortierungen enthalten weder denormalisierte Formen noch Unicode-Zeichen, die nicht direkt einem Zeichen auf der EBCDIC-Quellcodepage zugeordnet sind.
Die Zeichenzuordnungen zwischen EBCDIC-Codepages und Unicode-Codepunkten basieren auf von IBM veröffentlichten Tabellen. Das komplette Set ist bei IBM erhältlich als[komprimierte Datei](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip)zum Herunterladen. RDS für PostgreSQL verwendete diese Zuordnungen mit Tools, die von der ICU bereitgestellt wurden, um die in den Tabellen in diesem Abschnitt aufgeführten Kollatierungen zu erstellen. Die Kollationsnamen enthalten eine Sprache und ein Land, wie von der Intensivstation gefordert. EBCDIC-Codepages spezifizieren jedoch keine Sprachen, und einige EBCDIC-Codepages decken mehrere Länder ab. Das bedeutet, dass der Sprach- und Länderteil der Sortierungsnamen in der Tabelle willkürlich sind und nicht mit dem aktuellen Gebietsschema übereinstimmen müssen. Mit anderen Worten, die Codepage-Nummer ist der wichtigste Teil des Sortierungsnamens in dieser Tabelle. Sie können jede der in den folgenden Tabellen aufgeführten Kollatierungen in jeder RDS für PostgreSQL-Datenbank verwenden.
+ [Unicode to EBCDIC collations table](#ebcdic-table)— Einige Mainframe-Datenmigrationstools verwenden LATIN1 oder intern, um Daten LATIN9 zu kodieren und zu verarbeiten. Solche Tools verwenden Roundtrip-Schemata, um die Datenintegrität zu wahren und die umgekehrte Konvertierung zu unterstützen. Die Sortierungen in dieser Tabelle können von Tools verwendet werden, die Daten mithilfe von LATIN1 Kodierung verarbeiten, was keine besondere Behandlung erfordert.
+ [Unicode to LATIN9 collations table](#latin9-table) – Sie können diese Kollatierungen in jeder RDS für PostgreSQL-Datenbank verwenden.
In der folgenden Tabelle finden Sie in RDS für PostgreSQL verfügbare Kollatierungen, die EBCDIC-Codepages Unicode-Codepunkten zuordnen. Es wird empfohlen, die Sortierungen in dieser Tabelle für die Anwendungsentwicklung zu verwenden, die eine Sortierung basierend auf der Reihenfolge der IBM Codepages erfordert.
| Name der PostgreSQL-Sortierung | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge |
| --- | --- |
| DA-DK-CP277-x-Intensivstation | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 277 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 277-Codepunkt-Reihenfolge sortiert |
| DE-DE-CP273-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 273 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 273-Codepunkt-Reihenfolge sortiert |
| DE-GB-CP285-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 285 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 285-Codepunkt-Reihenfolge sortiert |
| de-US-CP037-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 037 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 37-Codepunktreihenfolge sortiert |
| es-ES-CP284-x-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 284 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 284-Codepunkt-Reihenfolge sortiert |
| fi-FI-CP278-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 278 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 278-Codepunkt-Reihenfolge sortiert |
| fr-FR-CP297-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 297 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 297-Codepunkt-Reihenfolge sortiert |
| es-es-CP280-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 280 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 280 Codepunkt-Reihenfolge sortiert. |
| NL-BE-CP500-x-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 500 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 500-Codepunktreihenfolge sortiert |
Amazon RDS bietet eine Reihe zusätzlicher Sortierungen, die Unicode-Codepunkte, die LATIN9 Zeichen anhand der von IBM veröffentlichten Tabellen zugeordnet sind, in der Reihenfolge der ursprünglichen Codepunkte gemäß der EBCDIC-Codepage der Quelldaten sortieren.
| Name der PostgreSQL-Sortierung | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge |
| --- | --- |
| DA-DK-CP1142 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1142 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1142-Codepunkte sortiert |
| de-DE-CP1141 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1141 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1141-Codepunkte sortiert |
| de-GB-CP1146 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1146 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1146-Codepunkte sortiert |
| en-US-CP1140 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1140 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1140-Codepunkte sortiert |
| es-ES-CP1145 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1145 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1145-Codepunkte sortiert |
| fi-FI-CP1143 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1143 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1143-Codepunkte sortiert |
| fr-FR-CP1147 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1147 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1147-Codepunkte sortiert |
| it-IT-CP1144 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1144 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1144-Codepunkte sortiert |
| nl-BE-CP1148 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1148 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1148-Codepunkte sortiert |
Im Folgenden finden Sie ein Beispiel für die Verwendung eines RDS-Werts für PostgreSQL-Sortierungen.
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
Wir empfehlen Ihnen, die Sortierungen in der[Unicode to EBCDIC collations table](#ebcdic-table)und in der[Unicode to LATIN9 collations table](#latin9-table)für die Anwendungsentwicklung, die eine Sortierung basierend auf der Reihenfolge der IBM Codepages erfordert. Die folgenden Sortierungen (mit dem Suffix „b“) sind auch in sichtbar, sind aber für die Verwendung durch Mainframe-Datenintegrations- und Migrationstools vorgesehen`pg_collation`, da sie Codepages mit bestimmten Codepunktverschiebungen AWS zuordnen und erfordern eine besondere Behandlung bei der Sortierung. Mit anderen Worten: Die folgenden Sortierungen werden nicht empfohlen.
+ DA-DK-277 b-x-icu
+ DA-DK-1142 b-x-icu
+ DE-DE-CP273 b-x-icu
+ DE-DE-CP1141 b-x-icu
+ de-GB-CP1146 b-x-icu
+ de-GB-CP285 b-x-icu
+ de-US-CP037 b-x-icu
+ de-US-CP1140 b-x-icu
+ es-ES-CP1145 b-x-icu
+ Es-ES-CP284 b-x-icu
+ fi-FI-CP1143 b-x-icu
+ fr-FR-CP1147 b-x-icu
+ fr-FR-CP297 b-x-icu
+ it-IT-CP1144 b-x-icu
+ it-IT-CP280 b-x-icu
+ NL-BE-CP1148 b-x-icu
+ NL-BE-CP500 b-x-icu
[Weitere Informationen zur Migration von Anwendungen aus Mainframe-Umgebungen zu finden Sie unter Was ist Mainframe-Modernisierung AWS? AWS](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html) .
Weitere Informationen zu PostgreSQL und Kollationen finden Sie unter [Support für Kollationen](https://www.postgresql.org/docs/current/collation.html) in der PostgreSQL-Dokumentation.
# Verwalten der logischen Slot-Synchronisation für RDS für PostgreSQL
Ab Community-PostgreSQL 17 wurde über den Parameter `sync_replication_slots` oder die zugehörige Funktion, die Slots bei der Ausführung manuell synchronisiert, eine neue Funktion `pg_sync_replication_slots()` zur automatischen Synchronisation logischer Replikations-Slots von Primär- zu Standby-Servern eingeführt.
Diese Funktionen sind ab RDS für PostgreSQL 17 verfügbar. Ein typisches Setup besteht aus einer primären Instance und ihrer [Read Replica](USER_PostgreSQL.Replication.ReadReplicas.md) sowie einem Abonnenten der primären Instance für die logische Replikation.
Stellen Sie sicher, dass das Abonnement so erstellt wurde, dass die Failover-Option auf true gesetzt ist:
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
Dadurch wird ein logischer Slot auf dem Publisher mit aktiviertem Failover erstellt.
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
Durch die Aktivierung der Slot-Synchronisierung werden alle Steckplätze für die logische Failover-Replikation auf dem primären System automatisch auf den physischen Standby-Slots erstellt und regelmäßig synchronisiert. Stellen Sie sicher, dass die folgenden Werte über [Parametergruppen](USER_WorkingWithParamGroups.Associating.md) festgelegt wurden:
+ `rds.logical_replication` muss `1` sein, um die logische Replikation zu aktivieren
+ `hot_standby_feedback` muss `1` im Standby-Modus sein
+ `rds.logical_slot_sync_dbname` im Standby-Modus muss auf einen gültigen Datenbanknamen gesetzt sein
Der Standardwert des Parameters ist `postgres`. Wenn die logische Publishing-Instance über die `postgres`-Datenbank verfügt, muss der Standardparameter nicht geändert werden.
+ `synchronized_standby_slots` auf dem primären System muss auf den physischen Replikations-Slot des Standby-Speichers eingestellt werden, der synchron sein soll
+ `sync_replication_slots` muss `1` sein, um die automatische Synchronisation zu aktivieren
Mit einem Abonnement-Slot mit aktiviertem Failover und den oben genannten Parameterwerten kann der Abonnent beim Heraufstufen einer Standby-Instance sein Abonnement für diese neu hochgestufte Instance ändern und die logische Replikation nahtlos fortsetzen.
# Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird
Wenn Amazon RDS Ihre DB-Instance bereitgestellt hat, können sie eine beliebige Standard-SQL-Client-Anwendung verwenden, um eine Verbindung zu der DB-Instance herzustellen. Bevor Sie eine Verbindung zu der DB-Instance herstellen können, muss diese verfügbar und zugänglich sein. Ob Sie sich von außerhalb der VPC mit der Instance verbinden können, hängt davon ab, wie Sie die Amazon-RDS-DB-Instance erstellt haben:
+ Wenn Sie Ihre DB-Instance als *öffentlich* erstellt haben, können sich Geräte und Amazon-EC2-Instances außerhalb der VPC mit Ihrer Datenbank verbinden.
+ Wenn Sie Ihre DB-Instance als *privat* erstellt haben, können sich nur Amazon-EC2-Instances und -Geräte innerhalb der Amazon VPC mit Ihrer Datenbank verbinden.
Um zu überprüfen, ob Ihre DB-Instance öffentlich oder privat ist, verwenden AWS-Managementkonsole Sie die Registerkarte **Konnektivität und Sicherheit** für Ihre Instance. Unter **Security** (Sicherheit) finden Sie den Wert „Publicly accessible“ (Öffentlich zugänglich), mit „No“ (Nein) für privat und „Yes“ (Ja) für öffentlich.
Weitere Informationen zu verschiedenen Amazon-RDS- und Amazon-VPC-Konfigurationen und deren Auswirkungen auf die Zugänglichkeit finden Sie unter [Szenarien für den Zugriff auf eine DB-Instance in einer VPC](USER_VPC.Scenarios.md).
**Contents**
+ [Installieren des psql-Clients](#install-psql)
+ [Suchen der Verbindungsinformationen für eine DB-Instance von RDS für PostgreSQL](#postgresql-endpoint)
+ [Herstellen einer Verbindung zu einer RDS für PostgreSQL-DB-Instance mit pgAdmin](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [Verwenden von psql zum Herstellen einer Verbindung mit Ihrer RDS für PostgreSQL-DB-Instance](USER_ConnectToPostgreSQLInstance.psql.md)
+ [Herstellen einer Verbindung mit RDS für PostgreSQL mithilfe des JDBC-Treibers von Amazon Web Services (AWS)](PostgreSQL.Connecting.JDBCDriver.md)
+ [Herstellen einer Verbindung mit RDS für PostgreSQL mithilfe des Python-Treibers von Amazon Web Services (AWS)](PostgreSQL.Connecting.PythonDriver.md)
+ [Fehlerbehebung bei Verbindungen mit Ihrer RDS für PostgreSQL-Instance](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [Fehler – FATAL: Datenbank *name* existiert nicht](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Fehler – Keine Verbindung mit dem Server möglich: Zeitüberschreitung für die Verbindung](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Fehler bei Zugriffsregeln für Sicherheitsgruppen](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Installieren des psql-Clients
Wenn Sie von einer EC2-Instance aus eine Verbindung mit Ihrer DB-Instance herstellen möchten, können Sie einen PostgreSQL-Client auf der EC2-Instance installieren. Führen Sie zum Installieren der aktuellen Version des psql-Clients in Amazon Linux 2023 den folgenden Befehl aus:
```
sudo dnf install postgresql
```
Führen Sie zum Installieren der aktuellen Version des psql-Clients in Amazon Linux 2 den folgenden Befehl aus:
```
sudo yum install -y postgresql
```
Führen Sie zum Installieren der aktuellen Version des psql-Clients in Ubuntu den folgenden Befehl aus:
```
sudo apt install -y postgresql-client
```
## Suchen der Verbindungsinformationen für eine DB-Instance von RDS für PostgreSQL
Wenn die DB-Instance verfügbar und zugänglich ist, können Sie eine Verbindung herstellen, indem Sie der SQL-Clientanwendung die folgenden Informationen bereitstellen:
+ Der Endpunkt der DB-Instance, der als Hostname (DNS-Name) für die Instance dient.
+ Den Port, über den die DB-Instance kommuniziert. Der Standardport für PostgreSQL lautet 5432.
+ Den Benutzernamen und das Passwort für die DB-Instance. Der Standardwert „Haupt-Benutzername“ für PostgreSQL ist `postgres`.
+ Der Name und das Passwort der Datenbank (DB-Name).
Sie können diese Details mithilfe des Befehls AWS-Managementkonsole, des AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehls oder der Amazon [DBInstancesRDS-API-Describe-Operation](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) abrufen.
**Um den Endpunkt, die Portnummer und den DB-Namen mit dem AWS-Managementkonsole**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Öffnen Sie die RDS-Konsole und wählen Sie **Databases (Datenbanken)**, um eine Liste Ihrer DB-Instances anzuzeigen.
1. Wählen Sie den Namen der PostgreSQL-DB-Instance, um deren Details anzuzeigen.
1. Kopieren Sie auf der Registerkarte **Connectivity & security (Anbindung und Sicherheit)** den Endpunkt. Notieren Sie sich auch die Portnummer. Sie benötigen sowohl den Endpunkt als auch die Portnummer, um die Verbindung zur DB-Instance herzustellen.
![\[Rufen Sie den Endpunkt von der RDS-Konsole ab\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. Notieren Sie auf der Registerkarte **Konfiguration** den DB-Namen. Wenn Sie eine Datenbank erstellt haben, als Sie die RDS für PostgreSQL-Instance erstellt haben, wird der Name unter DB-Name aufgeführt. Wenn Sie keine Datenbank erstellt haben, zeigt der DB-Name einen Bindestrich (‐) an.
![\[Rufen Sie den DB-Namen von der RDS-Konsole ab\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
Nachfolgend werden zwei Möglichkeiten gezeigt, eine Verbindung mit einer PostgreSQL-DB-Instance herzustellen. Im ersten Beispiel wird pgAdmin verwendet, ein beliebtes Open Source-Tool für die PostgreSQL-Administration und -Entwicklung. Im zweiten Beispiel wird psql verwendet, ein Befehlszeilen-Dienstprogramm, das in jeder PostgreSQL-Installation enthalten ist.
# Herstellen einer Verbindung zu einer RDS für PostgreSQL-DB-Instance mit pgAdmin
Sie können mit der Open-Source-Software pgAdmin eine Verbindung mit einer RDS für PostgreSQL-DB-Instance herstellen. Sie können pgAdmin von [http://www.pgadmin.org/](http://www.pgadmin.org/) herunterladen und instalieren, ohne über eine lokale PostgreSQL-Instance auf Ihrem Client-Computer zu verfügen.
**So stellen Sie eine Verbindung zu Ihrer RDS für PostgreSQL-DB-Instance mit pgAdmin her**
1. Starten Sie die Anwendung pgAdmin auf Ihrem Client-Computer.
1. Klicken Sie auf der Registerkarte **Dashboard** auf **Add New Server** (Neuen Server hinzufügen).
1. Geben Sie im Dialogfeld **Create – Server** (Erstellen – Server) auf der Registerkarte **General** (Allgemein) einen Namen für den Server in pgAdmin ein.
1. Geben Sie auf der Registerkarte **Verbindung** die folgenden Informationen der DB-Instance ein:
+ Geben Sie unter **Host** den Endpunkt ein, z. B. `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`.
+ Geben Sie in das Feld **Port** den zugehörigen Port ein.
+ Geben Sie für **Benutzername** den Benutzernamen ein, den Sie beim Erstellen der DB-Instance eingegeben haben (wenn Sie den „Haupt-Benutzernamen“ vom Standardwert `postgres` geändert haben).
+ Geben Sie unter **Password (Passwort)** das beim Erstellen der DB-Instance festgelegte Passwort ein.
![\[Beim Erstellen der DB-Instance festgelegtes Passwort eingeben\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. Wählen Sie **Speichern**.
Falls Probleme beim Herstellen der Verbindung auftreten, lesen Sie die Informationen unter [Fehlerbehebung bei Verbindungen mit Ihrer RDS für PostgreSQL-Instance](USER_ConnectToPostgreSQLInstance.Troubleshooting.md).
1. Um im pgAdmin-Browser auf eine Datenbank zuzugreifen, erweitern Sie nacheinander den Knoten **Server**, die DB-Instance und den Knoten **Datenbanken**. Wählen Sie anschließend die gewünschte Datenbank in der DB-Instance aus.
![\[Namen der DB-Instance-Datenbank im pgAdmin-Browser auswählen\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. Um einen Bereich zum Eingeben von SQL-Befehlen zu öffnen, klicken Sie auf **Tools**, **Query Tool** (Abfragetool).
# Verwenden von psql zum Herstellen einer Verbindung mit Ihrer RDS für PostgreSQL-DB-Instance
Sie können eine lokale Kopie des Befehlszeilenprogramms psql verwenden, um eine Verbindung mit einer RDS for PostgreSQL-DB-Instance herzustellen. Dazu muss entweder PostgreSQL oder der psql-Client auf dem Computer installiert sein.
Sie können den PostgreSQL-Client von der [PostgreSQL](https://www.postgresql.org/download/)-Website herunterladen. Folgen Sie den Anweisungen für Ihr Betriebssystem, um diese Version zu installieren.
Um über psql eine Verbindung zu Ihrer RDS for PostgreSQL-DB-Instance herzustellen, müssen Sie Hostinformationen (DNS), Zugangsdaten und den Namen der Datenbank angeben.
Verwenden Sie eines der folgenden Formate, um eine Verbindung zu Ihrer RDS für PostgreSQL-DB-Instance herzustellen. Sie werden beim Verbinden zur Eingabe eines Passworts aufgefordert. Verwenden Sie in Stapelaufträgen oder Skripts die Option `--no-password`. Diese Option ist für die gesamte Sitzung festgelegt.
**Anmerkung**
Ein Verbindungsversuch mit `--no-password` schlägt fehl, wenn der Server eine Passwortauthentifizierung erfordert und ein Passwort aus anderen Quellen nicht verfügbar ist. Weitere Informationen finden Sie in der [PSQL-Dokumentation](https://www.postgresql.org/docs/13/app-psql.html).
Wenn Sie sich zum ersten Mal mit dieser DB-Instance verbinden oder noch keine Datenbank für diese RDS for PostgreSQL-Instance erstellt haben, können Sie mit dem „Haupt-Benutzernamen“ und dem Passwort eine Verbindung zur **Postgres**-Datenbank herstellen.
Verwenden Sie unter Unix das folgende Format.
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
Verwenden Sie unter Windows das folgende Format.
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
Der folgende Befehl stellt beispielsweise eine Verbindung mit der Datenbank `mypgdb` in der PostgreSQL-DB-Instance `mypostgresql` her, wobei fiktive Anmeldeinformationen verwendet werden.
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Herstellen einer Verbindung mit RDS für PostgreSQL mithilfe des JDBC-Treibers von Amazon Web Services (AWS)
Der JDBC-Treiber für Amazon Web Services (AWS) ist als fortschrittlicher JDBC-Wrapper konzipiert. Dieser Wrapper ergänzt einen vorhandenen JDBC-Treiber und erweitert dessen Funktionen. Der Treiber ist Drop-In-kompatibel mit dem Community-pgJDBC-Treiber.
Um den AWS JDBC-Treiber zu installieren, hängen Sie die JAR-Datei des AWS JDBC-Treibers an (befindet sich in der Anwendung`CLASSPATH`) und behalten Sie die Verweise auf den jeweiligen Community-Treiber bei. Aktualisieren Sie das jeweilige Verbindungs-URL-Präfix wie folgt:
+ `jdbc:postgresql://` auf `jdbc:aws-wrapper:postgresql://`
Weitere Informationen zum AWS JDBC-Treiber und vollständige Anweisungen zu seiner Verwendung finden Sie im [Amazon Web Services (AWS) JDBC-Treiber-Repository](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
# Herstellen einer Verbindung mit RDS für PostgreSQL mithilfe des Python-Treibers von Amazon Web Services (AWS)
Der Amazon Web Services (AWS)-Python-Treiber ist als fortschrittlicher Python-Wrapper konzipiert. Dieser Wrapper ergänzt den Open-Source-Treiber Psycopg und erweitert dessen Funktionen. Der AWS -Python-Treiber unterstützt Python-Version 3.8 und höher. Sie können das Paket `aws-advanced-python-wrapper` zusammen mit den Open-Source-Paketen `psycopg` mithilfe des Befehls `pip` installieren.
Weitere Informationen zum AWS Python-Treiber und vollständige Anweisungen zu seiner Verwendung finden Sie im [ GitHub Python-Treiber-Repository von Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
# Fehlerbehebung bei Verbindungen mit Ihrer RDS für PostgreSQL-Instance
**Topics**
+ [Fehler – FATAL: Datenbank *name* existiert nicht](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Fehler – Keine Verbindung mit dem Server möglich: Zeitüberschreitung für die Verbindung](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Fehler bei Zugriffsregeln für Sicherheitsgruppen](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Fehler – FATAL: Datenbank *name* existiert nicht
Wenn Sie bei der Verbindung einen Fehler wie `FATAL: database name does not exist` erhalten, versuchen Sie, den Standard-Datenbanknamen **postgres** für die Option `--dbname` zu verwenden.
## Fehler – Keine Verbindung mit dem Server möglich: Zeitüberschreitung für die Verbindung
Wenn die Verbindung mit der DB-Instance nicht hergestellt werden kann, wird meistens der Fehler `Could not connect to server: Connection timed out.` angezeigt. Ist dies der Fall, gehen Sie wie folgt vor:
+ Prüfen Sie, ob der DB-Instance-Endpunkt als Hostname sowie die richtige Portnummer angegeben wurden.
+ Stellen Sie sicher, dass die öffentliche Zugänglichkeit der DB-Instance auf **Ja** festgelegt ist, um externe Verbindungen zuzulassen. Informationen zum Ändern der Einstellung **Öffentlicher Zugriff** finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
+ Stellen Sie sicher, dass der Benutzer, der sich mit der Datenbank verbindet, CONNECT-Zugriff darauf hat. Sie können folgende Abfrage verwenden, um den CONNECT-Zugriff auf die Datenbank bereitzustellen.
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ Prüfen Sie, ob die der DB-Instance zugewiesene Sicherheitsgruppe die erforderlichen Regeln enthält, um den Zugriff durch alle vorhandenen Firewalls zu ermöglichen. Beispiel: Bei der Erstellung der DB-Instance wurde der Standardport 5432 festgelegt und die Firewall-Regeln des Unternehmens blockieren Verbindungen mit diesem Port von externen Unternehmensgeräten.
Sie können dieses Problem beheben, indem Sie für die DB-Instance einen anderen Port verwenden. Stellen Sie außerdem sicher, dass die mit der DB-Instance verknüpfte Sicherheitsgruppe eingehende Verbindungen mit dem neuen Port zulässt. Informationen zum Ändern der Einstellung für **Datenbank-Port** finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
+ Prüfen Sie, ob der Port, den Sie verwenden möchten, bereits von einer lokalen Instance von PostgreSQL oder einem anderen Service belegt ist, der auf Ihrem Computer ausgeführt wird. Wenn Sie beispielsweise eine lokale PostgreSQL-Datenbank auf demselben Port haben (Standard ist 5432), kann dies eine erfolgreiche Verbindung mit der DB-Instance von RDS für PostgreSQL verhindern. Stellen Sie sicher, dass der Port frei ist, oder versuchen Sie möglichst, eine Verbindung mit einer anderen Portnummer herzustellen.
+ Weitere Informationen finden Sie auch unter [Fehler bei Zugriffsregeln für Sicherheitsgruppen](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules).
## Fehler bei Zugriffsregeln für Sicherheitsgruppen
Die bei Weitem häufigsten Verbindungsprobleme treten in Verbindung mit den Zugriffsregeln der Sicherheitsgruppe auf, die der DB-Instance zugewiesen wurde. Wenn Sie bei der Erstellung der DB-Instance die Standard-Sicherheitsgruppe verwendet haben, ist es sehr wahrscheinlich, dass die Regeln in der Sicherheitsgruppe den Zugriff auf die Instance nicht zulassen.
Damit die Verbindung möglich ist, muss die Sicherheitsgruppe, die Sie der DB-Instance bei der Erstellung zugewiesen haben, den Zugriff auf die DB-Instance zulassen. Wenn die DB-Instance beispielsweise in einer VPC erstellt wurde, muss sie über eine VPC-Sicherheitsgruppe verfügen, die die Verbindungen zulässt. Prüfen Sie, ob die DB-Instance mit einer Sicherheitsgruppe erstellt wurde, die keine Verbindungen vom Gerät oder von der Amazon EC2-Instance zulässt, auf dem bzw. der die Anwendung ausgeführt wird.
Sie können eine Regel für eingehenden Datenverkehr in der Sicherheitsgruppe hinzufügen oder ändern. Die Auswahl der Option **My IP (Meine IP)** für **Source (Quelle)** ermöglicht Zugriff auf die DB-Instance von der IP-Adresse, die in Ihrem Browser erkannt wird. Weitere Informationen finden Sie unter [Ermöglichen des Zugriffs auf Ihre DB-Instance in der VPC durch Erstellen einer Sicherheitsgruppe](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Wurde die DB-Instance außerhalb einer VPC erstellt, muss sie über eine Datenbank-Sicherheitsgruppe verfügen, die diese Verbindungen zulässt.
Weitere Informationen zu Amazon-RDS-Sicherheitsgruppen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md).
# Sichern von Verbindungen zu RDS for PostgreSQL mit SSL/TLS
RDS for PostgreSQL unterstützt die Secure-Socket-Layer(SSL)-Verschlüsselung für PostgreSQL-DB-Instances. Sie können die PostgreSQL-Verbindung zwischen Ihren Anwendungen und Ihren PostgreSQL-DB-Instances mit SSL verschlüsseln. Sie können auch festlegen, dass für alle Verbindungen zu Ihrer PostgreSQL-DB-Instance SSL verwendet werden soll. RDS for PostgreSQL unterstützt auch Transport Layer Security (TLS), das Nachfolgeprotokoll von SSL.
Weitere Informationen über Amazon RDS und Datenschutz, einschließlich der Verschlüsselung von Verbindungen mit SSL/TLS, finden Sie unter [Datenschutz in Amazon RDS](DataDurability.md).
**Topics**
+ [Verwenden von SSL mit einer PostgreSQL-DB-Instance](PostgreSQL.Concepts.General.SSL.md)
+ [Aktualisierung von Anwendungen für die Verbindung mit PostgreSQL-DB-Instances mithilfe neuer Zertifikate SSL/TLS](ssl-certificate-rotation-postgresql.md)
# Verwenden von SSL mit einer PostgreSQL-DB-Instance
Amazon RDS unterstützt die Secure Socket Layer (SSL)-Verschlüsselung für PostgreSQL-DB-Instances. Sie können die PostgreSQL-Verbindung zwischen Ihren Anwendungen und Ihren PostgreSQL-DB-Instances mit SSL verschlüsseln. Standardmäßig verwendet und erwartet RDS für PostgreSQL, dass sich alle Clients über SSL/TLS verbinden, aber Sie können dies auch verlangen. RDS für PostgreSQL unterstützt Transport Layer Security (TLS) in den Versionen 1.1, 1.2 und 1.3.
Allgemeine Informationen zum SSL-Support und zu PostgreSQL-Datenbanken finden Sie unter [SSL-Support](https://www.postgresql.org/docs/11/libpq-ssl.html) in der PostgreSQL-Dokumentation. Informationen zur Verwendung einer SSL-Verbindung über JDBC finden Sie unter [Konfigurieren des Clients](https://jdbc.postgresql.org/documentation/head/ssl-client.html) in der PostgreSQL-Dokumentation.
SSL-Unterstützung ist in allen AWS Regionen für PostgreSQL verfügbar. Amazon RDS erzeugt ein SSL-Zertifikat für Ihre DB-Instance, wenn die Instance erstellt wird. Wenn Sie die SSL-Zertifikatsverifizierung aktivieren, enthält das SSL-Zertifikat den Endpunkt der DB-Instance als Allgemeinen Namen (Common Name, CN) für das SSL-Zertifikat, sodass es vor Spoofing-Angriffen schützt.
**Topics**
+ [Herstellen einer Verbindung mit einer PostgreSQL-DB-Instance über SSL](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [Erfordern einer SSL-Verbindung zu einer PostgreSQL-DB-Instance](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [Bestimmen des SSL-Verbindungsstatus](#PostgreSQL.Concepts.General.SSL.Status)
+ [SSL-Verschlüsselungssammlungen in RDS für PostgreSQL](#PostgreSQL.Concepts.General.SSL.Ciphers)
## Herstellen einer Verbindung mit einer PostgreSQL-DB-Instance über SSL
**So stellen Sie über SSL eine Verbindung zu einer PostgreSQL-DB-Instance her**
1. Laden Sie das Zertifikat herunter.
Informationen zum Herunterladen von Zertifikaten finden Sie unter [](UsingWithRDS.SSL.md).
1. Stellen Sie über SSL eine Verbindung zu einer PostgreSQL-DB-Instance her.
Wenn Sie eine Verbindung über SSL herstellen, kann Ihr Client entscheiden, ob die Zertifikatskette überprüft werden soll. Wenn Ihre Verbindungsparameter `sslmode=verify-ca` oder `sslmode=verify-full` angeben, verlangt Ihr Client, dass sich die RDS CA-Zertifikate im Trust Store befinden oder von der Verbindungs-URL referenziert werden. Diese Anforderung dient zur Prüfung der Zertifikatskette, die Ihr Datenbankzertifikat signiert.
Wenn ein Client wie psql oder JDBC mit SSL-Unterstützung konfiguriert ist, versucht dieser zunächst standardmäßig, die Verbindung zur Datenbank über SSL herzustellen. Wenn der Client keine Verbindung über SSL herstellen kann, stellt er die Verbindung ohne SSL her. Der für libpq-basierte Clients (wie psql) und JDBC verwendete `sslmode`-Standardmodus ist unterschiedlich. Die libpq-basierten und JDBC-Clients verwenden standardmäßig `prefer`.
Verwenden Sie den Parameter `sslrootcert`, um auf das Zertifikat zu verweisen, beispielsweise `sslrootcert=rds-ssl-ca-cert.pem`.
Das folgende Beispiel veranschaulicht die Verwendung von `psql`, um eine Verbindung mit SSL und Zertifikatsüberprüfung mit einer PostgreSQL-DB-Instance herzustellen.
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## Erfordern einer SSL-Verbindung zu einer PostgreSQL-DB-Instance
Mit dem Parameter `rds.force_ssl` können Sie es erforderlich machen, dass Verbindungen zu Ihrer PostgreSQL-DB-Instance SSL verwenden müssen. Der Standardwert des Parameters `rds.force_ssl` ist für RDS für PostgreSQL 15 und höher auf „1 (ein)“ festgelegt. Bei allen anderen Hauptversionen von RDS für PostgreSQL bis Version 14 ist der Standardwert des Parameters auf „0 (aus)“ festgelegt. Sie können den `rds.force_ssl` Parameter auf 1 (on) setzen, damit er SSL/TLS für Verbindungen zu Ihrem DB-Cluster erforderlich ist. Sie können den Parameter `rds.force_ssl` auf 1 (ein) stellen und damit erforderlich machen, dass Verbindungen zu Ihrer PostgreSQL-DB-Instance SSL verwenden müssen.
Wenn Sie den Wert dieses Parameters ändern möchten, müssen Sie eine benutzerdefinierte DB-Parametergruppe erstellen. Anschließend ändern Sie den Wert für `rds.force_ssl` in Ihrer benutzerdefinierten DB-Parametergruppe in `1`, um diese Funktion zu aktivieren. Wenn Sie die benutzerdefinierte DB-Parametergruppe vorbereiten, bevor Sie Ihre RDS-for-PostgreSQL-DB-Instance erstellen, können Sie sie während des Erstellungsprozesses (anstelle einer Standardparametergruppe) auswählen. Wenn Sie diesen Schritt ausführen, nachdem Ihre RDS-for-PostgreSQL-DB-Instance bereits ausgeführt wird, müssen Sie die Instance neu starten, damit diese die benutzerdefinierte Parametergruppe verwendet. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Wenn die `rds.force_ssl`-Funktion auf Ihrer DB-Instance aktiv ist, werden Verbindungsversuche ohne SSL mit der folgenden Meldung abgelehnt:
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## Bestimmen des SSL-Verbindungsstatus
Der verschlüsselte Status Ihrer Verbindung wird auf dem Anmelde-Banner angezeigt, wenn Sie sich mit der DB-Instance verbinden:
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Sie können auch die Erweiterung `sslinfo` laden und dann die Funktion `ssl_is_used()` aufrufen, um festzustellen, ob SSL verwendet wird. Die Funktion gibt `t` zurück, wenn für die Verbindung SSL genutzt wird. Andernfalls gibt sie `f` zurück.
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Wenn Sie detailliertere Informationen erhalten möchten, können Sie die folgende Abfrage verwenden, um Informationen von `pg_settings` abzurufen:
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
Sie können auch alle Informationen über die SSL-Nutzung Ihrer RDS-for-PostgreSQL-DB-Instance nach Prozess, Client und Anwendung sammeln, indem Sie die folgende Abfrage verwenden:
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
Wenn Sie die Cipher identifizieren möchten, die für Ihre SSL-Verbindung verwendet wird, können Sie folgende Abfrage erstellen:
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Weitere Informationen zur Option `sslmode` finden Sie unter [Datenbankverbindung-Steuerungsfunktionen](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) in der *PostgreSQL-Dokumentation*.
## SSL-Verschlüsselungssammlungen in RDS für PostgreSQL
Bei Verwendung von TLS 1.2 und früheren Versionen gibt der PostgreSQL-Konfigurationsparameter [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL) die Kategorien von Verschlüsselungs-Suiten an, die für SSL-Verbindungen mit der Datenbank zulässig sind.
In RDS für PostgreSQL 16 und höher können Sie den Parameter `ssl_ciphers` so ändern, dass bestimmte Werte aus den zulässigen Verschlüsselungs-Suiten verwendet werden. Dies ist ein dynamischer Parameter, der keinen Neustart der Datenbank-Instance erfordert. Verwenden Sie entweder die Amazon-RDS-Konsole oder den folgenden AWS -CLI-Befehl, um die zulässigen Verschlüsselungs-Suiten anzuzeigen:
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
In der folgenden Tabelle sind sowohl die standardmäßigen als auch die zulässigen Verschlüsselungs-Suiten für Versionen aufgeführt, die benutzerdefinierte Konfigurationen unterstützen.
| PostgreSQL-Engine-Version | Standardwerte für die ssl\$1cipher-Suite | Zulässige benutzerdefinierte Werte für die ssl\$1cipher-Suite |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 14 | HIGH:\$1aNULL:\$13DES | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 13 | HIGH:\$1aNULL:\$13DES | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 12 | HIGH:\$1aNULL:\$13DES | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 11.4 und höhere Nebenversionen | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 11,1, 11,2 | HIGH:MEDIUM:\$13DES:\$1aNULL | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 10.9 und höhere Nebenversionen | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
| 10.7 und niedrigere Nebenversionen | HIGH:MEDIUM:\$13DES:\$1aNULL | Benutzerdefinierte ssl\$1ciphers werden nicht unterstützt. |
Um alle Instance-Verbindungen für die Verwendung der Verschlüsselungs-Suite `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` zu konfigurieren, ändern Sie die Parametergruppe wie im folgenden Beispiel gezeigt:
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
In diesem Beispiel wird eine ECDSA-Verschlüsselung verwendet, bei der die Instance eine Zertifizierungsstelle mit ECC (Elliptic Curve Cryptography, elliptische Kurven-Kryptografie) nutzen muss, um eine Verbindung herzustellen. Informationen zu den von Amazon RDS bereitgestellten Zertifizierungsstellen finden Sie unter [Zertifizierungsstellen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities).
Sie können die verwendeten Verschlüsselungen mithilfe der unter [Bestimmen des SSL-Verbindungsstatus](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status) beschriebenen Methoden überprüfen.
Verschlüsselungen können je nach Kontext unterschiedliche Namen haben:
+ Die zulässigen Verschlüsselungen, die Sie in der Parametergruppe konfigurieren können, werden mit ihren IANA-Namen bezeichnet.
+ Die Anmeldebanner `sslinfo` und `psql` verweisen auf Verschlüsselungen, die ihre OpenSSL-Namen verwenden.
Standardmäßig ist der Wert von `ssl_max_protocol_version` in RDS für PostgreSQL 16 und höher TLS v1.3. Sie müssen den Wert dieses Parameters auf TLS v1.2 festlegen, da TLS v1.3 die im Parameter `ssl_ciphers` angegebenen Verschlüsselungskonfigurationen nicht verwendet. Wenn Sie den Wert auf TLS v1.2 festlegen, verwenden Verbindungen nur die Verschlüsselungen, die Sie in `ssl_ciphers` definiert haben.
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
Um sich zu vergewissern, dass Datenbankverbindungen SSL verwenden, legen Sie `rds.force_ssl parameter` in der Parametergruppe auf 1 fest. Weitere Informationen zu Parametern und Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html).
# Aktualisierung von Anwendungen für die Verbindung mit PostgreSQL-DB-Instances mithilfe neuer Zertifikate SSL/TLS
Zertifikate, die für Secure Socket Layer oder Transport Layer Security verwendet werden (SSL/TLS) typically have a set lifetime. When service providers update their Certificate Authority (CA) certificates, clients must update their applications to use the new certificates. Following, you can find information about how to determine if your client applications use SSL/TLSum eine Verbindung zu Ihrer Amazon RDS for PostgreSQL PostgreSQL-DB-Instance herzustellen). Sie finden auch Informationen darüber, wie Sie prüfen können, ob diese Anwendungen das Serverzertifikat überprüfen, wenn sie eine Verbindung herstellen.
**Anmerkung**
Eine Client-Anwendung, die so konfiguriert ist, dass sie das Serverzertifikat vor der SSL/TLS Verbindung verifiziert, muss über ein gültiges CA-Zertifikat im Trust Store des Clients verfügen. Aktualisieren Sie den Client-Truststore bei Bedarf für neue Zertifikate.
Nach der Aktualisierung der CA-Zertifikate in den Trust Stores Ihrer Client-Anwendung können Sie die Zertifikate auf Ihren DB-Instances rotieren. Es wird nachdrücklich empfohlen, diese Verfahren vor der Implementierung in Produktionsumgebungen in einer Nicht-Produktionsumgebung zu testen.
Weitere Informationen zur Zertifikatrotation finden Sie unter [Ihr SSL/TLS Zertifikat rotieren](UsingWithRDS.SSL-certificate-rotation.md). Weitere Informationen zum Herunterladen von Zertifikaten finden Sie unter [](UsingWithRDS.SSL.md). Hinweise zur Verwendung SSL/TLS mit PostgreSQL-DB-Instances finden Sie unter. [Verwenden von SSL mit einer PostgreSQL-DB-Instance](PostgreSQL.Concepts.General.SSL.md)
**Topics**
+ [Ermitteln, ob Anwendungen Verbindungen mit PostgreSQL-DB-Instances über SSL herstellen](#ssl-certificate-rotation-postgresql.determining-server)
+ [Ermitteln, ob ein Client zum Herstellen von Verbindungen Zertifikatverifizierungen erfordert](#ssl-certificate-rotation-postgresql.determining-client)
+ [Aktualisieren des Trust Stores Ihrer Anwendung](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [Verwenden von SSL/TLS Verbindungen für verschiedene Arten von Anwendungen](#ssl-certificate-rotation-postgresql.applications)
## Ermitteln, ob Anwendungen Verbindungen mit PostgreSQL-DB-Instances über SSL herstellen
Prüfen Sie die DB-Instance-Konfiguration auf den Wert des Parameters `rds.force_ssl`. Standardmäßig ist der Parameter `rds.force_ssl` für DB-Instances, die PostgreSQL-Versionen vor Version 15 verwenden, auf `0` (aus) festgelegt. Standardmäßig ist `rds.force_ssl` für DB-Instances, die PostgreSQL Version 15 oder höhere Hauptversionen verwenden, auf `1` (ein) festgelegt. Wenn der `rds.force_ssl` Parameter auf `1` (on) gesetzt ist, müssen Clients ihn SSL/TLS für Verbindungen verwenden. Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Wenn Sie die RDS PostgreSQL-Version 9.5 oder eine höhere Hauptversion verwenden und `rds.force_ssl` nicht auf `1` festgelegt ist, fragen Sie die Ansicht `pg_stat_ssl` ab, um auf Verbindungen zu prüfen, die SSL verwenden. Beispielsweise gibt die folgende Abfrage nur SSL-Verbindungen und Informationen zu den Clients zurück, die SSL verwenden.
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
Nur Zeilen, die SSL/TLS Verbindungen verwenden, werden mit Informationen über die Verbindung angezeigt. Dies ist eine Beispielausgabe.
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
Diese Abfrage zeigt nur die aktuellen Verbindungen zum Zeitpunkt der Abfrage an. Das Fehlen von Ergebnissen weist nicht darauf hin, dass es keine Anwendungen gibt, die SSL-Verbindungen verwenden. Möglicherweise werden zu anderen Zeitpunkten weitere SSL-Verbindungen hergestellt.
## Ermitteln, ob ein Client zum Herstellen von Verbindungen Zertifikatverifizierungen erfordert
Wenn ein Client wie psql oder JDBC mit SSL-Unterstützung konfiguriert ist, versucht dieser zunächst standardmäßig, die Verbindung zur Datenbank über SSL herzustellen. Wenn der Client keine Verbindung über SSL herstellen kann, stellt er die Verbindung ohne SSL her. Der für libpq-basierte Clients (wie psql) und JDBC verwendete `sslmode`-Standardmodus wird auf `prefer` festgelegt. Das Zertifikat auf dem Server wird nur verifiziert, wenn `sslrootcert` angegeben und die Einstellung für `sslmode` auf `verify-ca` oder `verify-full` festgelegt ist. Wenn das Zertifikat ungültig ist, wird ein Fehler ausgelöst.
Verwenden Sie `PGSSLROOTCERT` zur Verifizierung des Zertifikats mit der Umgebungsvariablen `PGSSLMODE`, wobei `PGSSLMODE` auf `verify-ca` oder `verify-full` festgelegt ist.
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
Verwenden Sie das Argument `sslrootcert` zur Verifizierung des Zertifikats mit `sslmode` im Verbindungszeichenfolgenformat, wobei `sslmode` auf `verify-ca` oder `verify-full` festgelegt ist, um das Zertifikat zu verifizieren.
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
Wenn Sie beispielsweise in vorherigen Fall ein ungültiges Stammzertifikat verwenden, wird Ihnen im Client einen Fehler ähnlich dem folgenden angezeigt.
```
psql: SSL error: certificate verify failed
```
## Aktualisieren des Trust Stores Ihrer Anwendung
Informationen zur Aktualisierung des Vertrauensspeichers für PostgreSQL-Anwendungen finden Sie unter [Sichere TCP/IP Verbindungen mit SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) in der PostgreSQL-Dokumentation.
Informationen zum Herunterladen des Stammverzeichnisses finden Sie unter [](UsingWithRDS.SSL.md).
Beispiele für Skripte, die Zertifikate importieren, finden Sie unter [Beispielskript für den Import von Zertifikaten in Ihren Trust Store](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Anmerkung**
Wenn Sie den Trust Store aktualisieren, können Sie ältere Zertifikate beibehalten und die neuen Zertifikate einfach hinzufügen.
## Verwenden von SSL/TLS Verbindungen für verschiedene Arten von Anwendungen
Im Folgenden finden Sie Informationen zur Verwendung von SSL/TLS Verbindungen für verschiedene Arten von Anwendungen:
+ **psql**
Der Client wird über die Befehlszeile durch die Angabe von Optionen als Verbindungszeichenfolge oder Umgebungsvariablen aufgerufen. Für SSL/TLS Verbindungen sind die relevanten Optionen `sslmode` (Umgebungsvariable`PGSSLMODE`), `sslrootcert` (Umgebungsvariable`PGSSLROOTCERT`) relevant.
Die vollständige Liste der Optionen finden Sie unter [Parameter Key Words](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS) in der PostgreSQL-Dokumentation. Die vollständige Liste der Umgebungsvariablen finden Sie unter [Environment Variables](https://www.postgresql.org/docs/current/libpq-envars.html) in der PostgreSQL-Dokumentation.
+ **pgAdmin**
Dieser browserbasierte Client bietet eine benutzerfreundlichere Oberfläche zum Herstellen von Verbindungen mit PostgreSQL-Datenbanken.
Informationen zum Konfigurieren von Verbindungen finden Sie in der [pgAdmin-Dokumentation](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html).
+ **JDBC**
JDBC ermöglicht Datenbankverbindungen mit Java-Anwendungen.
Allgemeine Informationen zum Herstellen von Verbindungen mit PostgreSQL-Datenbanken über JDBC finden Sie unter [Connecting to the Database](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database) in der JDBC-Treiber-Dokumentation von PostgreSQL. Informationen zum Herstellen von Verbindungen über SSL/TLS finden Sie unter [Configuring the Client](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client) in der JDBC-Treiber-Dokumentation von PostgreSQL.
+ **Python**
Eine verbreitet für die Herstellung von Verbindungen mit PostgreSQL-Datenbanken verwendete Python-Bibliothek ist `psycopg2`.
Informationen zum Verwenden von `psycopg2` finden Sie in der [psycopg2-Dokumentation](https://pypi.org/project/psycopg2/). Ein kurzes Tutorial zum Herstellen von Verbindungen mit PostgreSQL-Datenbanken finden Sie unter [Psycopg2-Tutorial](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial). Informationen zu den vom Verbindungsbefehl akzeptierten Optionen finden Sie unter [psycopg2-Modulinhalte](http://initd.org/psycopg/docs/module.html#module-psycopg2).
**Wichtig**
Nachdem Sie festgestellt haben, dass Ihre Datenbankverbindungen Ihren Anwendungs-Truststore verwenden, SSL/TLS und Ihren Anwendungs-Truststore aktualisiert haben, können Sie Ihre Datenbank so aktualisieren, dass sie die rds-ca-rsa 2048-g1-Zertifikate verwendet. Anleitungen hierzu finden Sie in Schritt 3 unter [Aktualisieren des CA-Zertifikats durch Ändern der DB-Instanceoder des DB-Clusters](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
# Verwenden der Kerberos-Authentifizierung mit Amazon RDS für PostgreSQL
Sie können Kerberos verwenden, um Benutzer zu authentifizieren, wenn sie sich mit Ihrer DB-Instance mit PostgreSQL verbinden. Konfigurieren Sie dazu Ihre so, dass sie AWS Directory Service for Microsoft Active Directory für die Kerberos-Authentifizierung verwendet wird. AWS Directory Service for Microsoft Active Directory wird auch genannt. AWS Managed Microsoft AD Es ist eine Funktion, die mit verfügbar ist Directory Service. Weitere Informationen finden Sie unter [Was ist Directory Service?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) im *AWS Directory Service Administratorhandbuch*.
Erstellen Sie zunächst ein AWS Managed Microsoft AD Verzeichnis zum Speichern von Benutzeranmeldeinformationen. Anschließend stellen Sie Ihrer PostgreSQL-DB-Instance die Active Directory Domain und weitere Informationen zur Verfügung. Wenn Benutzer sich mit PostgreSQL-DB-Instances authentifizieren, werden Authentifizierungsanforderungen an das AWS Managed Microsoft AD -Verzeichnis weitergeleitet.
Wenn Sie alle Ihre Anmeldeinformationen im selben Verzeichnis aufbewahren, können Sie Zeit und Mühe sparen. Sie haben einen zentralen Ort für die Speicherung und Verwaltung von Anmeldeinformationen für mehrere DB-Instances. Die Verwendung eines Verzeichnisses kann auch Ihr allgemeines Sicherheitsprofil verbessern.
Außerdem können Sie von Ihrem eigenen On-Premises Microsoft Active Directory auf Anmeldeinformationen zugreifen. Dazu erstellen Sie eine vertrauensvolle Domain-Beziehung, damit das AWS Managed Microsoft AD -Verzeichnis Ihrem On-Premises Microsoft Active Directory vertraut. Auf diese Weise können Ihre Benutzer auf Ihre PostgreSQL--Instances mit derselben Windows Single Sign-On-Oberfläche (SSO) zugreifen, die sie auch für den Zugriff auf Workloads in Ihrem lokalen Netzwerk verwenden.
Eine Datenbank kann die Kennwortauthentifizierung oder die Kennwortauthentifizierung mit Kerberos- oder (IAM) -Authentifizierung verwenden. AWS Identity and Access Management Weitere Informationen zur IAM-Authentifizierung finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md).
**Anmerkung**
RDS für PostgreSQL unterstützt keine Kerberos-Authentifizierung für Active-Directory-Gruppen.
**Topics**
+ [Verfügbarkeit von Regionen und Versionen](#postgresql-kerberos.RegionVersionAvailability)
+ [Übersicht über die Kerberos-Authentifizierung für PostgreSQL-DB-Instances](#postgresql-kerberos-overview)
+ [Einrichten der Kerberos-Authentifizierung für PostgreSQL-DB-Instances](postgresql-kerberos-setting-up.md)
+ [Verwaltung eines RDS für PostgreSQL-DB-Instance) in einer Active Directory-Domäne](postgresql-kerberos-managing.md)
+ [Herstellen einer Verbindung zu PostgreSQL mit Kerberos-Authentifizierung](postgresql-kerberos-connecting.md)
## Verfügbarkeit von Regionen und Versionen
Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen über die Verfügbarkeit von Versionen und Regionen von RDS für PostgreSQL mit Kerberos-Authentifizierung finden Sie unter [Unterstützte Regionen und DB-Engines für die Kerberos-Authentifizierung in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Übersicht über die Kerberos-Authentifizierung für PostgreSQL-DB-Instances
Um die Kerberos-Authentifizierung für PostgreSQL-DB-Instances einzurichten, führen Sie die folgenden Schritte aus, die später näher erläutert werden:
1. Wird verwendet AWS Managed Microsoft AD , um ein Verzeichnis zu erstellen. AWS Managed Microsoft AD Sie können die AWS-Managementkonsole, oder die Directory Service API verwenden AWS CLI, um das Verzeichnis zu erstellen. Stellen Sie sicher, dass Sie die relevanten ausgehenden Ports in der Verzeichnissicherheitsgruppe öffnen, damit das Verzeichnis mit der kommunizieren kann.
1. Erstellen Sie eine Rolle, die RDS-Zugriff gewährt, um Anrufe in Ihr AWS Managed Microsoft AD Verzeichnis zu tätigen. Erstellen Sie dazu eine AWS Identity and Access Management (IAM-) Rolle, die die verwaltete IAM-Richtlinie verwendet. `AmazonRDSDirectoryServiceAccess`
Damit die IAM-Rolle Zugriff gewährt, muss der Endpunkt AWS -Security-Token-Service (AWS STS) in der richtigen AWS Region für Ihr Konto aktiviert sein. AWS AWS STS Endpunkte sind standardmäßig in allen aktiv AWS-Regionen, und Sie können sie ohne weitere Aktionen verwenden. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Aktivierung und Deaktivierung AWS STS in einer AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate).
1. Erstellen und konfigurieren Sie Benutzer im AWS Managed Microsoft AD Verzeichnis mithilfe der Microsoft Active Directory-Tools. Weitere Informationen zum Erstellen von Benutzern in Ihrem Active Directory finden Sie unter [Verwalten von Benutzern und Gruppen in AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) im *Directory Service Administratorhandbuch*.
1. Wenn Sie planen, das Verzeichnis und die DB-Instance in verschiedenen AWS Konten oder virtuellen privaten Clouds (VPCs) zu lokalisieren, konfigurieren Sie VPC-Peering. Weitere Informationen finden Sie unter [Was ist VPC Peering?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) im *Amazon VPC Peering Guide*.
1. Erstellen oder ändern Sie PostgreSQL-DB-Instances entweder über die Konsole, CLI oder RDS-API mit einer der folgenden Methoden:
+ [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md)
+ [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md)
+ [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md)
+ [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md)
Sie können die in derselben Amazon Virtual Private Cloud (VPC) wie das Verzeichnis oder in einem anderen AWS Konto oder einer anderen VPC lokalisieren. Wenn Sie die PostgreSQL-DB- erstellen oder ändern, gehen Sie wie folgt vor:
+ Geben Sie den Domänenbezeichner (`d-*`-Bezeichner) an, der beim Erstellen Ihres Verzeichnisses generiert wurde.
+ Geben Sie außerdem den Namen der IAM-Rolle an, die Sie erstellt haben.
+ Stellen Sie sicher, dass die Sicherheitsgruppe der DB-Instance eingehenden Datenverkehr von der Sicherheitsgruppe des Verzeichnisses empfangen kann.
1. Verwenden Sie die RDS-Master-Benutzer-Anmeldeinformationen, um sich mit PostgreSQL-DB-Instances zu verbinden. Erstellen Sie den Benutzer in PostgreSQL, der extern identifiziert werden soll. Extern identifizierte Benutzer können sich über die Kerberos-Authentifizierung bei der PostgreSQL-DB- anmelden.
# Einrichten der Kerberos-Authentifizierung für PostgreSQL-DB-Instances
Um die Kerberos-Authentifizierung einzurichten, führen Sie die folgenden Schritte aus.
**Topics**
+ [Schritt 1: Erstellen Sie ein Verzeichnis mit AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory)
+ [Schritt 2: (Optional) Erstellen Sie eine Vertrauensbeziehung zwischen Ihrem lokalen Active Directory und Directory Service](#postgresql-kerberos-setting-up.create-trust)
+ [Schritt 3: Erstellen Sie eine IAM-Rolle für RDS für den Zugriff auf Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [Schritt 4: Anlegen und Konfigurieren von Benutzern](#postgresql-kerberos-setting-up.create-users)
+ [Schritt 5: Aktivieren des VPC-übergreifenden Datenverkehrs zwischen dem Verzeichnis und der DB-Instance](#postgresql-kerberos-setting-up.vpc-peering)
+ [Schritt 6: Erstellen oder Ändern von PostgreSQL-DB-](#postgresql-kerberos-setting-up.create-modify)
+ [Schritt 7: Erstellen von PostgreSQL-Benutzern für Ihre Kerberos-Prinzipale](#postgresql-kerberos-setting-up.create-logins)
+ [Schritt 8: Konfigurieren eines PostgreSQL-Clients](#postgresql-kerberos-setting-up.configure-client)
## Schritt 1: Erstellen Sie ein Verzeichnis mit AWS Managed Microsoft AD
Directory Service erstellt ein vollständig verwaltetes Active Directory in der AWS Cloud. Wenn Sie ein AWS Managed Microsoft AD Verzeichnis erstellen, Directory Service erstellt zwei Domänencontroller und DNS-Server für Sie. Die Verzeichnisserver werden in verschiedenen Subnetzen in einer VPC erstellt. Diese Redundanz trägt dazu bei, dass Ihr Verzeichnis auch im Fehlerfall erreichbar bleibt.
Wenn Sie ein AWS Managed Microsoft AD Verzeichnis erstellen, führt der AWS Directory Service die folgenden Aufgaben in Ihrem Namen aus:
+ Richtet ein Active Directory in Ihrer VPC ein.
+ Erstellt ein Konto für den Verzeichnisadministrator mit dem Benutzernamen `Admin` und dem angegebenen Passwort. Mit diesem Konto verwalten Sie das Verzeichnis.
**Wichtig**
Stellen Sie sicher, dass Sie dieses Passwort speichern. Directory Service speichert dieses Passwort nicht und es kann nicht abgerufen oder zurückgesetzt werden.
+ Erstellt eine Sicherheitsgruppe für die Verzeichniscontroller. Die Sicherheitsgruppe muss die Kommunikation mit der PostgreSQL-DB- zulassen.
AWS Erstellt beim Start AWS Directory Service for Microsoft Active Directory eine Organisationseinheit (OU), die alle Objekte Ihres Verzeichnisses enthält. Diese OU erhält den NetBIOS-Namen, den Sie beim Erstellen des Verzeichnisses eingegeben haben, und befindet sich im Domänenstamm. Der Domänenstamm gehört und wird von diesem verwaltet AWS.
Das `Admin` Konto, das mit Ihrem AWS Managed Microsoft AD Verzeichnis erstellt wurde, verfügt über Berechtigungen für die gängigsten Verwaltungsaktivitäten Ihrer Organisationseinheit:
+ Erstellen, Aktualisieren oder Löschen von Benutzern
+ Hinzufügen von Ressourcen zu Ihrer Domäne, etwa Datei- oder Druckserver, und anschließendes Gewähren der zugehörigen Ressourcenberechtigungen für Benutzer in der OU
+ Zusätzliche OUs Container erstellen
+ Delegieren von Befugnissen
+ Wiederherstellen von gelöschten Objekten aus dem Active Directory-Papierkorb
+ Führen Sie Active Directory- und DNS-Module (Domain Name Service) für Windows PowerShell im Active Directory-Webdienst aus
Das `Admin`-Konto hat auch die Berechtigung, die folgenden domänenweiten Aktivitäten durchzuführen:
+ Verwalten von DNS-Konfigurationen (Hinzufügen, Entfernen oder Aktualisieren von Datensätzen, Zonen und Weiterleitungen)
+ Aufrufen von DNS-Ereignisprotokollen
+ Anzeigen von Sicherheitsereignisprotokollen
**Um ein Verzeichnis zu erstellen mit AWS Managed Microsoft AD**
1. Wählen Sie im Navigationsbereich [Directory Service -Konsole](https://console.aws.amazon.com/directoryservicev2/) den Eintrag **Directories (Verzeichnisse)** und wählen Sie **Set up directory (Verzeichnis einrichten)** aus.
1. Wählen Sie **AWS Managed Microsoft AD**. AWS Managed Microsoft AD ist die einzige Option, die derzeit für die Verwendung mit RDS unterstützt wird.
1. Wählen Sie **Weiter** aus.
1. Geben Sie auf der Seite **Enter directory information (Verzeichnisinformationen eingeben)** die folgenden Informationen ein:
**Edition**
Wählen Sie die Edition aus, die Ihre Anforderungen erfüllt.
**DNS-Name des Verzeichnisses**
Den vollständig qualifizierten Namen für das Verzeichnis, z. B. **corp.example.com**.
**NetBIOS-Name des Verzeichnisses**
Ein optionaler Kurzname für das Verzeichnis, z. B. `CORP`.
**Verzeichnisbeschreibung**
Eine optionale Beschreibung des Verzeichnisses.
**Administratorpasswort**
Das Passwort für den Verzeichnisadministrator. Mit der Verzeichniserstellung wird ein Administratorkonto mit dem Benutzernamen `Admin` und diesem Passwort angelegt.
Das Passwort für den Verzeichnisadministrator darf nicht das Wort "admin" enthalten. Beachten Sie beim Passwort die Groß- und Kleinschreibung und es muss 8 bis 64 Zeichen lang sein. Zudem muss es mindestens ein Zeichen aus dreien der vier folgenden Kategorien enthalten:
+ Kleinbuchstaben (a–z)
+ Großbuchstaben (A–Z)
+ Zahlen (0–9)
+ Nicht-alphanumerische Zeichen (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**Passwort bestätigen**
Geben Sie das Administratorpasswort erneut ein.
Stellen Sie sicher, dass Sie dieses Passwort speichern. Directory Service speichert dieses Passwort nicht und es kann nicht abgerufen oder zurückgesetzt werden.
1. Wählen Sie **Weiter** aus.
1. Geben Sie auf der Seite **Choose VPC and subnets (VPC und Subnetze wählen)** die folgenden Informationen an.
**VPC**
Wählen Sie die VPC für das Verzeichnis aus. Sie können PostgreSQL-DB-Instances in derselben VPC oder in einer anderen VPC erstellen.
**Subnetze**
Wählen Sie Subnetze für die Verzeichnis-Server aus. Die beiden Subnetze müssen zu verschiedenen Availability-Zonen gehören.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Verzeichnisinformationen. Wenn Änderungen erforderlich sind, klicken Sie auf **Previous (Zurück)** und nehmen Sie die Änderungen vor. Wenn die Informationen richtig sind, wählen Sie **Create directory (Verzeichnis erstellen)**.
![\[Seite „Directory details (Verzeichnisdetails)“\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
Es dauert einige Minuten, bis das Verzeichnis erstellt wurde. Wenn es erfolgreich erstellt wurde, ändert sich der Wert **Status** in **Active (Aktiv)**.
Um Informationen über das Verzeichnis anzuzeigen, wählen Sie die Verzeichnis-ID in der Verzeichnisauflistung aus. Notieren Sie sich den Wert **Directory ID**. Sie benötigen diesen Wert, wenn Sie Ihre PostgreSQL DB-Instance erstellen oder ändern.
![\[Abbildung der Detailseite\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## Schritt 2: (Optional) Erstellen Sie eine Vertrauensbeziehung zwischen Ihrem lokalen Active Directory und Directory Service
Wenn Sie Ihr eigenes lokales Microsoft Active Directory nicht verwenden möchten, fahren Sie mit for [Schritt 3: Erstellen Sie eine IAM-Rolle für RDS für den Zugriff auf Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole).
Um die Kerberos-Authentifizierung mit Ihrem lokalen Active Directory zu erhalten, müssen Sie eine vertrauensvolle Domänenbeziehung mithilfe einer Gesamtvertrauensstellung zwischen Ihrem lokalen Microsoft Active Directory und dem AWS Managed Microsoft AD Verzeichnis (erstellt in) einrichten. [Schritt 1: Erstellen Sie ein Verzeichnis mit AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory) Die Vertrauensstellung kann unidirektional sein, wobei das AWS Managed Microsoft AD Verzeichnis dem lokalen Microsoft Active Directory vertraut. Die Vertrauensstellung kann auch bidirektional erfolgen, wobei beide Active Directories einander vertrauen. *Weitere Informationen zum Einrichten von Vertrauensstellungen mithilfe von finden Sie unter [Wann Directory Service sollte eine Vertrauensstellung](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) eingerichtet werden? im Administratorhandbuch.AWS Directory Service *
**Anmerkung**
Wenn Sie ein lokales Microsoft Active Directory verwenden, stellen Windows-Clients eine Verbindung über den Domänennamen des Directory Service im Endpunkt her und nicht über rds.amazonaws.com her. Weitere Informationen hierzu finden Sie unter [Herstellen einer Verbindung zu PostgreSQL mit Kerberos-Authentifizierung](postgresql-kerberos-connecting.md).
Stellen Sie sicher, dass der lokale Microsoft Active Directory-Domänenname ein DNS-Suffix-Routing enthält, das der neu erstellten Vertrauensstellung entspricht. Im folgenden Screenshot wird ein Beispiel gezeigt.
![\[DNS-Routing entspricht der erstellten Vertrauensstellung\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## Schritt 3: Erstellen Sie eine IAM-Rolle für RDS für den Zugriff auf Directory Service
Damit Amazon RDS Sie anrufen Directory Service kann, benötigt Ihr AWS Konto eine IAM-Rolle, die die verwaltete IAM-Richtlinie verwendet. `AmazonRDSDirectoryServiceAccess` Diese Rolle ermöglicht es Amazon RDS, Aufrufe von Directory Service durchzuführen.
Wenn Sie mit dem eine DB-Instance erstellen AWS-Managementkonsole und Ihr Konsolen-Benutzerkonto über die `iam:CreateRole` entsprechende Berechtigung verfügt, erstellt die Konsole automatisch die benötigte IAM-Rolle. In diesem Fall lautet der Rollenname `rds-directoryservice-kerberos-access-role`. Andernfalls müssen Sie die IAM-Rolle manuell erstellen. Wenn Sie diese IAM-Rolle erstellen`Directory Service`, wählen Sie die AWS verwaltete Richtlinie aus und hängen Sie `AmazonRDSDirectoryServiceAccess` sie an.
Weitere Informationen zum Erstellen von IAM-Rollen für einen Dienst finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS Dienst](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*.
**Anmerkung**
Die für die Windows-Authentifizierung für RDS für Microsoft SQL Server verwendete IAM-Rolle kann nicht für Amazon RDS für PostgreSQL verwendet werden.
Alternativ können Sie Richtlinien mit den erforderlichen Berechtigungen erstellen, anstatt die verwaltete Richtlinie `AmazonRDSDirectoryServiceAccess` zu verwenden. In diesem Fall muss die IAM-Rolle die folgende IAM-Vertrauensrichtlinie haben.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Die Rolle muss auch über die folgende IAM-Rollenrichtlinie verfügen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Wenn Sie sich anmelden möchten AWS-Regionen, verwenden Sie regionsspezifische Dienstprinzipale in den Vertrauensrichtlinien für IAM-Rollen. Wenn Sie eine Vertrauensrichtlinie für Services in diesen Regionen erstellen, geben Sie den Regionalcode im Service-Prinzipal an.
Das folgende Beispiel zeigt eine Vertrauensrichtlinie, die regionsspezifischen Service-Prinzipale enthält.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Ersetzen Sie REGION-CODE durch den Code für Ihre spezifische Region. Verwenden Sie beispielsweise die folgenden Service-Prinzipale für die Region Asien-Pazifik (Melbourne):
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## Schritt 4: Anlegen und Konfigurieren von Benutzern
Sie können Benutzer mit dem Tool „Active Directory Users and Computers“ erstellen. Dieses Tool ist ein Active Directory Domain Service und ein Active Directory Lightweight Directory Service. Weitere Informationen finden Sie unter [Hinzufügen von Benutzern und Computern zur Active-Directory-Domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain). In diesem Fall handelt es sich bei Benutzern um Einzelpersonen oder andere Entitäten, z. B. um ihre Computer, die Teil der Domain sind und deren Identitäten im Verzeichnis verwaltet werden.
Um Benutzer in einem Directory Service Verzeichnis zu erstellen, müssen Sie mit einer Windows-basierten Amazon EC2 EC2-Instance verbunden sein, die Mitglied des Verzeichnisses ist. Directory Service Gleichzeitig müssen Sie als Benutzer angemeldet sein, der über Berechtigungen zum Erstellen von Benutzern verfügt. Weitere Informationen finden Sie unter [Erstellen eines Benutzers](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html) im *AWS Directory Service Administration Guide*.
## Schritt 5: Aktivieren des VPC-übergreifenden Datenverkehrs zwischen dem Verzeichnis und der DB-Instance
Wenn Sie beabsichtigen, das Verzeichnis und die DB-Instance in derselben VPC zu platzieren, überspringen Sie diesen Schritt und fahren Sie mit [Schritt 6: Erstellen oder Ändern von PostgreSQL-DB-](#postgresql-kerberos-setting-up.create-modify) fort.
[Wenn Sie planen, das Verzeichnis und die DB-Instance unterschiedlich zu lokalisieren VPCs, konfigurieren Sie den VPC-übergreifenden Verkehr mithilfe von VPC-Peering oder Transit Gateway.AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
Das folgende Verfahren ermöglicht den Datenverkehr zwischen VPCs mithilfe von VPC-Peering. Folgen Sie den Anleitungen unter [Was ist VPC Peering?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) im *Handbuch zu Amazon Virtual Private Cloud-Peering*.
**Aktivieren des VPC-übergreifenden Datenverkehrs mit VPC Peering**
1. Richten Sie geeignete VPC-Routing-Regeln ein, um sicherzustellen, dass Netzwerk-Datenverkehr in beide Richtungen fließen kann.
1. Stellen Sie sicher, dass die Sicherheitsgruppe der DB-Instance eingehenden Datenverkehr von der Sicherheitsgruppe des Verzeichnisses empfangen kann.
1. Stellen Sie sicher, dass keine ACL-Regel (Network Access Control List) zum Blockieren des Datenverkehrs vorhanden ist.
Wenn ein anderes AWS Konto Eigentümer des Verzeichnisses ist, müssen Sie das Verzeichnis gemeinsam nutzen.
**Um das Verzeichnis von mehreren AWS Konten gemeinsam zu nutzen**
1. *Beginnen Sie mit der gemeinsamen Nutzung des Verzeichnisses mit dem AWS Konto, unter dem die DB-Instance erstellt werden soll. Folgen Sie dazu den Anweisungen unter [Tutorial: Sharing your AWS Managed Microsoft AD-Directory for Seamless EC2 Domain-Join](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) im Directory Service Administrationshandbuch.*
1. Melden Sie sich mit dem Konto für die DB-Instance bei der Directory Service Konsole an und stellen Sie sicher, dass die Domain den `SHARED` Status hat, bevor Sie fortfahren.
1. Notieren Sie sich den Wert der **Verzeichnis-ID**, während Sie mit dem Konto für die DB-Instance bei der Directory Service Konsole angemeldet sind. Sie verwenden diese Verzeichnis-ID, um die DB-Instance mit der Domäne zu verbinden.
## Schritt 6: Erstellen oder Ändern von PostgreSQL-DB-
Erstellen oder ändern Sie PostgreSQL-DB-Instances für die Verwendung mit Ihrem Verzeichnis. Sie können die Konsole, CLI oder RDS-API verwenden, um DB-Instances einem Verzeichnis zuzuordnen. Sie können dafür eine der folgenden Möglichkeiten auswählen:
+ Erstellen Sie eine neue PostgreSQL-DB-Instance mithilfe der Konsole, des [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI-Befehls oder der Operation [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API. Detaillierte Anweisungen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
+ Ändern Sie eine vorhandene PostgreSQL-DB-Instance mithilfe der Konsole, des [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI-Befehls oder der Operation [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API. Detaillierte Anweisungen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
+ Stellen Sie mithilfe der Konsole, des CLI-Befehls -db-snapshot oder des API-Vorgangs Restore From RDS eine [restore-db-instance-fromPostgreSQL-DB-Instance aus einem DB-Snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) [wieder her DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html). DBSnapshot Detaillierte Anweisungen finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md).
+ Stellen Sie eine PostgreSQL-DB-Instance point-in-time mithilfe der Konsole, des Befehls [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI oder der Operation [Restore DBInstance ToPointInTime RDS API in a wieder her](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html). Detaillierte Anweisungen finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md).
Die Kerberos-Authentifizierung wird nur für PostgreSQL-DB--Instances in einer VPC unterstützt. Der DB-Cluster kann sich in derselben VPC wie das Verzeichnis oder in einer anderen VPC befinden. Die DB-Instance muss eine Sicherheitsgruppe verwenden, die ausgehenden Datenverkehr innerhalb der VPC des Verzeichnisses zulässt, damit die DB-Instance mit dem Verzeichnis kommunizieren kann.
### Konsole
Wenn Sie die Konsole verwenden, ändern oder wiederherstellen, um eine DB-Instance zu erstellen, wählen Sie im Abschnitt **Datenbankauthentifizierung** die Option **Passwort- und Kerberos-Authentifizierung** aus. Dann wählen Sie **Verzeichnis durchsuchen**. Wählen Sie das Verzeichnis aus oder wählen Sie **Erstellen eines neuen Verzeichnisses**, um den Directory Service zu verwenden.
![\[Auswahl von Kerberos für die Authentifizierung und Identifizierung des zu verwendenden Verzeichnisses.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
Wenn Sie den verwenden AWS CLI, sind die folgenden Parameter erforderlich, damit die das von Ihnen erstellte Verzeichnis verwenden kann:
+ Für den `--domain`-Parameter verwenden Sie den Domänenbezeichner („d-\$1“-Bezeichner), der beim Erstellen des Verzeichnisses generiert wurde.
+ Verwenden Sie für den `--domain-iam-role-name`-Parameter die von Ihnen erstellte Rolle, die die verwaltete IAM-Richtlinie `AmazonRDSDirectoryServiceAccess` verwendet.
Beispielsweise ändert der folgende CLI-Befehl eine DB-Instance zur Verwendung eines Verzeichnisses.
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**Wichtig**
Wenn Sie eine DB-Instance ändern, um die Kerberos-Authentifizierung zu aktivieren, starten Sie die DB-Instance neu, nachdem Sie die Änderung vorgenommen haben.
## Schritt 7: Erstellen von PostgreSQL-Benutzern für Ihre Kerberos-Prinzipale
Zu diesem Zeitpunkt ist Ihre DB-Instance von RDS für PostgreSQL mit der AWS Managed Microsoft AD -Domain verbunden. Die Benutzer, die Sie in dem Verzeichnis in [Schritt 4: Anlegen und Konfigurieren von Benutzern](#postgresql-kerberos-setting-up.create-users) erstellt haben, müssen als PostgreSQL-Datenbankbenutzer eingerichtet sein und über Berechtigungen verfügen, um sich bei der Datenbank anzumelden. Dazu melden Sie sich als Datenbankbenutzer mit `rds_superuser`-Rechten an. Wenn Sie beispielsweise beim Erstellen Ihrer DB-Instance von RDS für PostgreSQL die Standardeinstellungen akzeptiert haben, verwenden Sie `postgres`, wie in den folgenden Schritten gezeigt.
**So erstellen Sie PostgreSQL-Datenbankbenutzer für Ihre Kerberos-Prinzipale**
1. Verwenden Sie `psql`, um eine Verbindung mit dem DB-Instance-Endpunkt von RDS für PostgreSQL mit `psql` herzustellen. Im folgenden Beispiel wird das `postgres`-Standardkonto für die `rds_superuser`-Rolle verwendet.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Erstellen Sie einen Datenbankbenutzernamen für jeden Kerberos-Prinzipal (Active-Directory-Benutzername), der Zugriff auf die Datenbank haben soll. Verwenden Sie den kanonischen Benutzernamen (Identität), wie er in der Active-Directory-Instance definiert ist, d. h. einen `alias` in Kleinbuchstaben (Benutzername in Active Directory) und den Namen der Active-Directory-Domain für diesen Benutzernamen in Großbuchstaben. Der Active-Directory-Benutzername ist ein extern authentifizierter Benutzer. Setzen Sie den Namen daher in Anführungszeichen, wie im Folgenden gezeigt.
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. Weisen Sie dem Datenbankbenutzer die `rds_ad`-Rolle zu.
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Nachdem Sie alle PostgreSQL-Benutzer für Ihre Active-Directory-Benutzeridentitäten erstellt haben, können Benutzer mit ihren Kerberos-Anmeldeinformationen auf die DB-Instance von RDS für PostgreSQL zugreifen.
Es ist erforderlich, dass die Datenbankbenutzer, die sich mit Kerberos authentifizieren, dies von Client-Computern aus tun, die Mitglieder der Active-Directory-Domain sind.
Datenbankbenutzer, denen die `rds_ad`-Rolle zugewiesen wurde, können nicht auch über die `rds_iam`-Rolle verfügen. Dies gilt auch für verschachtelte Mitgliedschaften. Weitere Informationen finden Sie unter [IAM-Datenbankauthentifizierungfür MariaDB, MySQL und PostgreSQL](UsingWithRDS.IAMDBAuth.md).
## Schritt 8: Konfigurieren eines PostgreSQL-Clients
Gehen Sie folgendermaßen vor, um einen PostgreSQL-Client zu konfigurieren:
+ Erstellen Sie eine krb5.conf-Datei (oder eine vergleichbare Datei), um auf die Domäne zu verweisen.
+ Stellen Sie sicher, dass der Datenverkehr zwischen dem Client-Host und fließen kann Directory Service. Verwenden Sie ein Netzwerk-Dienstprogramm wie Netcat für die folgenden Aufgaben:
+ Überprüfen Sie den Datenverkehr über DNS für Port 53.
+ Überprüfen Sie den Datenverkehr TCP/UDP für Port 53 und für Kerberos, einschließlich der Ports 88 und 464 für. Directory Service
+ Stellen Sie sicher, dass der Datenverkehr zwischen dem Client-Host und der DB-Instance über den Datenbank-Port fließen kann. Verwenden Sie beispielsweise psql, um eine Verbindung herzustellen und auf die Datenbank zuzugreifen.
Im Folgenden finden Sie einen krb5.conf-Beispielinhalt für. AWS Managed Microsoft AD
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
Nachfolgend ein Beispiel für den Inhalt von krb5.conf für ein lokales Microsoft Active Directory.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Verwaltung eines RDS für PostgreSQL-DB-Instance) in einer Active Directory-Domäne
Sie können die Konsole, die CLI oder die RDS-API verwenden, um Ihre DB-Instance und ihre Beziehung zu Ihrem Microsoft Active Directory zu verwalten. Sie können z. B. ein Active Directory zuordnen, um die Kerberos-Authentifizierung zu aktivieren. Sie können auch die Zuordnung für ein Active Directory entfernen, um die Kerberos-Authentifizierung zu deaktivieren. Sie können auch DB-Instances verschieben, die von einem Microsoft Active Directory zu einem anderen extern authentifiziert werden.
Sie können z. B. mithilfe der CLI Folgendes tun:
+ Verwenden Sie den CLI-Befehl, um erneut zu versuchen, die Kerberos-Authentifizierung für eine fehlgeschlagene Mitgliedschaft zu aktivieren. [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) Geben Sie die Verzeichnis-ID der aktuellen Mitgliedschaft für die Option `--domain` an.
+ Verwenden Sie den [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI-Befehl, um die Kerberos-Authentifizierung auf einer DB-Instance zu deaktivieren. Geben Sie `none` für die Option `--domain` an.
+ Verwenden Sie den [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI-Befehl, um eine DB-Instance von einer Domain in eine andere zu verschieben. Geben Sie die Domänen-ID der neuen Domäne für die Option `--domain` an.
## Grundlegendes zur Domänenmitgliedschaft
Nachdem Sie Ihre DB-Instance erstellt oder geändert haben, wird er zu einem Mitglied der Domäne. Sie können den Status der Domänenmitgliedschaft in der Konsole oder durch Ausführen des [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI-Befehls anzeigen. Der Status der DB-Instance kann einer der folgenden sein:
+ `kerberos-enabled` – Für die DB-Instance ist die Kerberos-Authentifizierung aktiviert.
+ `enabling-kerberos`— AWS ist dabei, die Kerberos-Authentifizierung für diese DB-Instance zu aktivieren.
+ `pending-enable-kerberos` – Das Aktivieren der Kerberos-Authentifizierung ist für diese DB-Instance ausstehend.
+ `pending-maintenance-enable-kerberos`— AWS wird versuchen, die Kerberos-Authentifizierung auf der DB-Instance während des nächsten geplanten Wartungsfensters zu aktivieren.
+ `pending-disable-kerberos` – Das Deaktivieren der Kerberos-Authentifizierung ist für diese DB-Instance ausstehend.
+ `pending-maintenance-disable-kerberos`— AWS wird versuchen, die Kerberos-Authentifizierung auf der DB-Instance während des nächsten geplanten Wartungsfensters zu deaktivieren.
+ `enable-kerberos-failed`— Ein Konfigurationsproblem AWS verhinderte die Aktivierung der Kerberos-Authentifizierung auf der DB-Instance. Beheben Sie das Konfigurationsproblem, bevor Sie den Befehl zum Ändern der DB-Instance erneut ausgeben.
+ `disabling-kerberos`— AWS ist dabei, die Kerberos-Authentifizierung auf dieser DB-Instance zu deaktivieren.
Eine Anfrage zur Aktivierung der Kerberos-Authentifizierung kann wegen eines Netzwerkverbindungsproblems oder einer falschen IAM-Rolle fehlschlagen. In einigen Fällen kann der Versuch, die Kerberos-Authentifizierung zu aktivieren, fehlschlagen, wenn Sie eine DB-Instance erstellen oder ändern. Wenn dies passiert, stellen Sie sicher, dass Sie die richtige IAM-Rolle verwenden, und ändern Sie dann die DB-Instance, um der Domäne beizutreten.
**Anmerkung**
Nur die Kerberos-Authentifizierung mit RDS für PostgreSQL sendet Datenverkehr zu den DNS-Servern der Domäne. Alle anderen DNS-Anfragen werden als ausgehender Netzwerkzugriff auf Ihre DB-Instances mit PostgreSQL behandelt. Weitere Hinweise zum ausgehenden Netzwerkzugriff mit RDS für PostgreSQL finden Sie unter [Verwenden eines benutzerdefinierten DNS-Servers für ausgehenden Netzwerkzugriff.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md).
# Herstellen einer Verbindung zu PostgreSQL mit Kerberos-Authentifizierung
Sie können sich über die pgAdmin-Schnittstelle oder über eine Befehlszeilenschnittstelle wie psql per Kerberos-Authentifizierung mit PostgreSQL verbinden. Weitere Informationen zum Herstellen von Verbindungen finden Sie unter [Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird](USER_ConnectToPostgreSQLInstance.md) . Informationen zum Abrufen des Endpunkts, der Portnummer und anderer Details, die für die Verbindung benötigt werden, finden Sie unter [Herstellen einer Verbindung zu einer PostgreSQL-DB-Instance](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL).
**Anmerkung**
GSSAPI-Authentifizierung und Verschlüsselung in PostgreSQL werden von der Kerberos-Bibliothek `libkrb5.so` implementiert. Features wie `postgres_fdw` und `dblink` beruhen ebenfalls auf dieser Bibliothek für ausgehende Verbindungen mit Kerberos-Authentifizierung oder -Verschlüsselung.
## pgAdmin
Um pgAdmin für die Verbindung zu PostgreSQL mit Kerberos-Authentifizierung zu verwenden, führen Sie die folgenden Schritte aus:
1. Starten Sie die Anwendung pgAdmin auf Ihrem Client-Computer.
1. Klicken Sie auf der Registerkarte **Dashboard** auf **Add New Server** (Neuen Server hinzufügen).
1. Geben Sie im Dialogfeld **(Erstellen – Server)** auf der Registerkarte **Allgemein** einen Namen für den Server in pgAdmin ein.
1. Geben Sie auf der Registerkarte **Connection** (Verbindung) die folgenden Informationen aus der Datenbank von RDS für PostgreSQL ein:
+ Geben Sie für **Host** den Endpunkt für die DB-Instance von RDS für PostgreSQL Ein Endpunkt sieht in etwa wie folgt aus:
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Um von einem Windows-Client aus eine Verbindung zu einem lokalen Microsoft Active Directory herzustellen, verwenden Sie den Domänennamen des AWS Managed Active Directory anstelle des `rds.amazonaws.com` Host-Endpunkts. Nehmen wir zum Beispiel an, der Domänenname für das AWS verwaltete Active Directory lautet`corp.example.com`. Für **Host** würde der Endpunkt wie folgt angegeben werden:
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ Geben Sie unter **Port** den zugewiesenen Port ein.
+ Geben Sie unter **Wartungsdatenbank** den Namen der initialen Datenbank ein, mit der sich der Client verbinden soll.
+ Geben Sie unter **Benutzername** den Benutzernamen ein, den Sie für die Kerberos-Authentifizierung in [Schritt 7: Erstellen von PostgreSQL-Benutzern für Ihre Kerberos-Prinzipale](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins) eingegeben haben.
1. Wählen Sie **Speichern**.
## Psql
Um psql für die Verbindung mit PostgreSQL mit Kerberos-Authentifizierung zu verwenden, führen Sie die folgenden Schritte aus:
1. Führen Sie an einer Eingabeaufforderung den folgenden Befehl aus.
```
kinit username
```
Ersetzen Sie *`username`* durch den Benutzernamen. Geben Sie in der Eingabeaufforderung das im Microsoft Active Directory für den Benutzer gespeicherte Passwort ein.
1. Wenn die PostgreSQL-DB-Instance eine öffentlich zugängliche VPC verwendet, geben Sie eine IP-Adresse für Ihren DB-Instance-Endpunkt in Ihrer `/etc/hosts`-Datei auf dem EC2-Client ein. Die folgenden Befehle rufen beispielsweise die IP-Adresse ab und fügen sie dann in die `/etc/hosts`-Datei ein.
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Wenn Sie eine lokale Microsoft Active Directory von einem Windows-Client verwenden, müssen Sie eine Verbindung über einen speziellen Endpunkt herstellen. Anstatt die Amazon-Domain `rds.amazonaws.com` im Host-Endpunkt zu verwenden, verwenden Sie den Domainnamen des AWS Managed Active Directory.
Nehmen wir zum Beispiel an, der Domainname für Ihr AWS Managed Active Directory lautet`corp.example.com`. Verwenden Sie dann das Format `PostgreSQL-endpoint.AWS-Region.corp.example.com` für den Endpunkt und legen Sie es in der `/etc/hosts`-Datei ab.
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. Verwenden Sie den folgenden psql-Befehl, um sich bei einer PostgreSQL-DB-Instance anzumelden, der/die in Active Directory integriert ist.
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
Um sich beim PostgreSQL DB-Cluster von einem Windows-Client aus unter Verwendung eines lokalen Active Directory anzumelden, verwenden Sie den folgenden psql-Befehl mit dem Domänennamen aus dem vorhergehenden Schritt (`corp.example.com`):
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# Verwenden eines benutzerdefinierten DNS-Servers für ausgehenden Netzwerkzugriff.
Amazon RDS for PostgreSQL unterstützt den ausgehenden Netzwerkzugriff auf Ihre DB-Instances und erlaubt Domain-Name-Service-Auflösung (DNS-Auflösung) aus einem benutzerdefinierten DNS-Server, der im Besitz des Kunden ist. Sie können nur vollständig geeignete Domänenamen aus Ihrer DB-Instance von RDS for PostgreSQL über Ihren benutzerdefinierten DNS-Server auflösen.
**Topics**
+ [Aktivieren der benutzerdefinierten DNS-Auflösung](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [Deaktivieren der benutzerdefinierten DNS-Auflösung](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [Einrichten eines benutzerdefinierten DNS-Servers](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## Aktivieren der benutzerdefinierten DNS-Auflösung
Um die DNS-Auflösung in Ihrer Kunden-VPC zu aktivieren, weisen Sie Ihrer Instance von RDS for PostgreSQL zunächst eine benutzerdefinierte DB-Parametergruppe zu. Aktivieren Sie dann den `rds.custom_dns_resolution`-Parameter, indem Sie ihn auf 1 setzen, und starten Sie dann die DB-Instance neu, damit die Änderungen durchgeführt werden können.
## Deaktivieren der benutzerdefinierten DNS-Auflösung
Um die DNS-Auflösung in Ihrer Kunden-VPC auszuschalten, deaktivieren Sie zuerst den `rds.custom_dns_resolution`-Parameter Ihrer benutzerdefinierten DB-Parametergruppe, indem Sie ihn auf 0 setzen. Starten Sie dann die DB-Instance neu, damit die Änderungen durchgeführt werden können.
## Einrichten eines benutzerdefinierten DNS-Servers
Nachdem Sie Ihren benutzerdefinierten DNS-Namensserver eingerichtet haben, dauert es bis zu 30 Minuten, um die Änderungen an Ihre DB-Instance zu übertragen. Nachdem die Änderungen an Ihre DB-Instance übertragen wurden, wird ausgehender Datenverkehr, der eine DNS-Abfrage tätigen muss, Ihren DNS-Server über Port 53 abrufen.
**Anmerkung**
Wenn Sie keinen benutzerdefinierten DNS-Server einrichten und `rds.custom_dns_resolution` auf 1 festgelegt ist, werden Hosts mithilfe einer privaten Amazon-Route-53-Zone aufgelöst. Weitere Informationen finden Sie unter [Arbeiten mit privat gehosteten Zonen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
**Richten Sie einen benutzerdefinierten DNS-Server für Ihre DB-Instance von RDS for PostgreSQL wie folgt ein:**
1. Legen Sie in dem Ihrer VPC beigefügten Dynamic-Host-Configuration-Protocol(DHCP)-Optionsset die Option `domain-name-servers` für die IP-Adresse Ihres DNS-Namensservers fest. Weitere Informationen finden Sie unter [DHCP-Optionssets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
**Anmerkung**
Die Option `domain-name-servers` akzeptiert bis zu vier Werte, Ihre Amazon-RDS-DB-Instance verwendet jedoch nur den ersten Wert.
1. Stellen Sie sicher, dass Ihr DNS-Server die Suchabfragen auflösen kann, einschließlich DNS-Namen, Amazon EC2-private-DNS-Namen und benutzerspezifischen DNS-Namen. Wenn der ausgehende Datenverkehr DNS-Abfragen beinhaltet, die Ihr DNS-Server nicht handhaben kann, müssen für Ihren DNS-Server angemessene DNS-Provider für einen Upstream konfiguriert sein.
1. Konfigurieren Sie Ihren DNS-Server, um User Datagram Protocol (UDP)-Antworten in der Größenordnung von 512 Bytes oder weniger zu erhalten.
1. Konfigurieren Sie Ihren DNS-Server, um Transmission Control Protocol (TCP)-Antworten in der Größenordnung von 1024 Bytes oder weniger zu erhalten.
1. Konfigurieren Sie Ihren DNS-Server, um eingehenden Datenverkehr aus Ihrer Amazon RDS-DB-Instance über Port 53 zu erlauben. Wenn sich Ihr DNS-Server in einer Amazon VPC befindet, muss die VPC über eine Sicherheitsgruppe verfügen, die eingehende Regeln für das Erlauben von UDP und TCP über Port 53 beinhaltet. Wenn sich Ihr DNS-Server nicht in einer Amazon VPC befindet, muss er geeignete Firewall-Einstellungen besitzen, die eingehenden UDP- und TCP-Datenverkehr auf Port 53 zulassen.
Weitere Informationen finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) und unter [Hinzufügen und Entfernen von Regeln](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
1. Konfigurieren Sie die VPC Ihrer Amazon-RDS-DB-Instance, um ausgehenden Datenverkehr über Port 53 zu erlauben. Ihre VPC muss über eine Sicherheitsgruppe mit ausgehenden Regeln verfügen, die UDP- und TCP-Übertragungen über Port 53 erlauben.
Weitere Informationen finden Sie unter [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) (Sicherheitsgruppen für Ihre VPC) und [Adding and removing rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) (Hinzufügen und Entfernen von Regeln) im *Amazon-VPC-Benutzerhandbuch*.
1. Stellen Sie sicher, dass der Routing-Pfad zwischen der Amazon-RDS-DB-Instance und dem DNS-Server korrekt konfiguriert ist, um DNS-Datenverkehr zu erlauben.
Wenn sich die Amazon RDS-DB-Instance und der DNS-Server nicht in der selben VPC befinden, stellen Sie außerdem sicher, dass eine Peer-to-Peer-Verbindung zwischen ihnen eingerichtet ist. Weitere Informationen finden Sie unter [Was ist VPC Peering?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) im *Amazon VPC Peering Guide*.
# Upgrades der DB-Engine von RDS für PostgreSQL
Es gibt zwei Arten von Upgrades für Ihre PostgreSQL-Datenbank:
+ Betriebssystemupdates – Amazon RDS muss gelegentlich das Ihrer Datenbank zugrunde liegende Betriebssystem aktualisieren, um Sicherheitsmängel zu beheben oder Betriebssystemänderungen anzuwenden. Sie können mithilfe der RDS-Konsole AWS Command Line Interface (AWS CLI) oder der RDS-API entscheiden, wann Amazon RDS Betriebssystemupdates einführt. Weitere Informationen zu Betriebssystem-Aktualisierungen finden Sie unter [Updates auf einen anwenden](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
+ Datenbank-Engine-Upgrades – Wenn Amazon RDS eine neue Version einer Datenbank-Engine unterstützt, können Sie Ihre Datenbanken auf die neue Version upgraden.
Eine *Datenbank* ist in diesem Zusammenhang eine DB-Instance von RDS für PostgreSQ oder ein Multi-AZ-DB-Cluster.
Es gibt zwei Arten von Engine-Upgrades für PostgreSQL-Datenbanken: Hauptversion-Upgrades und Unterversion-Upgrades.
**Hauptversions-Upgrades**
*Hauptversions-Upgrades* können Datenbankänderungen enthalten, die nicht mit vorhandenen Anwendungen rückwärts kompatibel sind. Daher müssen Sie Hauptversions-Upgrades Ihrer Datenbanken manuell durchführen. Sie können ein Hauptversions-Upgrade starten, indem Sie Ihre DB-Instance oder Ihren Multi-AZ-DB-Cluster ändern. Bevor Sie ein Hauptversion-Upgrade durchführen, sollten Sie die Schritte befolgen, die unter [Auswählen einer Hauptversion für ein Upgrade von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) beschrieben werden.
Amazon RDS verarbeitet Hauptversion-Upgrades mit Multi-AZ wie folgt:
+ **Bereitstellung der DB-Instance mit Multi-AZ** – Amazon RDS aktualisiert die primäre und alle Standby-Instances gleichzeitig. Ihre Datenbank ist möglicherweise für einige Minuten nicht verfügbar, während das Upgrade abgeschlossen wird.
+ **Bereitstellung eines DB-Clusters mit Multi-AZ** – Amazon RDS aktualisiert die Reader- und Writer-Instances gleichzeitig. Ihre Datenbank ist möglicherweise für einige Minuten nicht verfügbar, während das Upgrade abgeschlossen wird.
Wenn Sie eine DB-Instance mit Lesereplikaten in der Region aktualisieren. aktualisiert Amazon RDS die Replikate zusammen mit der primären DB-Instance.
Amazon RDS aktualisiert keine Lesereplikate von Multi-AZ-DB-Clustern. Bei Hauptversion-Upgrades eines DB-Clusters mit Multi-AZ ändert sich der Replikationsstatus der Lesereplikate in **Beendet**. Sie müssen die Lesereplikate nach Abschluss des Upgrades manuell löschen und neu erstellen.
Sie können die Ausfallzeit, die für ein Upgrade einer Hauptversion erforderlich ist, minimieren, indem Sie eine blue/green Bereitstellung verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md).
**Unterversion-Upgrades**
*Nebenversions-Upgrades* enthalten dagegen nur Änderungen, die mit vorhandenen Anwendungen abwärtskompatibel sind. Sie können ein Nebenversions-Upgrade manuell starten, indem Sie Ihre Datenbank ändern. Alternativ können Sie beim Erstellen oder Ändern einer Datenbank die Option **Automatisches Unterversions-Upgrade** aktivieren. Hierdurch wird Ihre Datenbank von Amazon RDS automatisch aktualisiert, nachdem die neue Version getestet und genehmigt wurde.
Amazon RDS verarbeitet Unterversion-Upgrades mit Multi-AZ wie folgt:
+ **Bereitstellung der DB-Instance mit Multi-AZ** – Amazon RDS aktualisiert die primäre und alle Standby-Instances gleichzeitig. Ihre Datenbank ist möglicherweise für einige Minuten nicht verfügbar, während das Upgrade abgeschlossen wird.
+ **Bereitstellung eines DB-Clusters mit Multi-AZ** – Amazon RDS aktualisiert die Reader-DB-Instances nacheinander. Dann wechselt eine der Reader-DB-Instances zur neuen Writer-DB-Instance. Amazon RDS aktualisiert anschließend die alte Writer-Instance (die nun eine Reader-Instance ist). DB-Cluster mit Multi-AZ reduzieren die Ausfallzeit bei Unterversion-Upgrades in der Regel auf etwa 35 Sekunden. Bei Verwendung mit dem RDS-Proxy können Sie die Ausfallzeit weiter auf eine Sekunde oder weniger reduzieren. Weitere Informationen finden Sie unter [Amazon RDS-Proxy ](rds-proxy.md). Alternativ können Sie einen Open-Source-Datenbank-Proxy wie [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/) oder den [AWS Advanced JDBC [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/)Wrapper Driver verwenden.
Wenn Ihre Datenbank Lesereplikate verwendet, müssen Sie alle Lesereplikate aktualisieren, bevor Sie die Quell-Instance oder den Quell-Cluster aktualisieren.
Weitere Informationen finden Sie unter [Automatische Unterversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md). Informationen zur manuellen Durchführung eines Unterversionsupgrades finden Sie unter [Manuelles Upgraden der Engine-Version](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Weitere Informationen über Datenbank-Engine-Versionen und die Richtlinie zur Ablehnung von Datenbank-Engine-Versionen finden Sie unter [Datenbank-Engine-Versionen](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions) im Amazon RDS. FAQs
**Topics**
+ [Überlegungen zu PostgreSQL-Upgrades](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [Finden gültiger Upgrade-Ziele](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [PostgreSQL-Versionsnummern](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [RDS-Versionsnummern in RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [Auswählen einer Hauptversion für ein Upgrade von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [Automatische Unterversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [Überwachung von RDS für PostgreSQL-Engine-Upgrades mit Ereignissen](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## Überlegungen zu PostgreSQL-Upgrades
Um Ihre Datenbanken sicher zu aktualisieren, verwendet Amazon RDS das Dienstprogramm `pg_upgrade`, das in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/pgupgrade.html) beschrieben ist.
Wenn Ihr Aufbewahrungszeitraum für Backups größer als 0 ist, erstellt Amazon RDS während des Upgrade-Prozesses zwei DB-Snapshots. Der erste DB-Snapshot gehört zur Datenbank, bevor Änderungen im Rahmen des Upgrades vorgenommen wurden. Wenn das Upgrade bei Ihren Datenbanken nicht funktioniert, können Sie diesen Snapshot wiederherstellen, um eine Datenbank zu erstellen, auf der die alte Version ausgeführt wird. Der zweite DB-Snapshot wird nach Abschluss des Upgrades übernommen. Diese DB-Snapshots werden automatisch gelöscht, sobald die Aufbewahrungsfrist für Backups abgelaufen ist.
**Anmerkung**
Amazon RDS nimmt während des Upgrade-Vorgangs nur dann DB-Snapshots auf, wenn Sie für den Aufbewahrungszeitraum des Backups Ihrer Datenbank einen Wert größer als 0 festgelegt haben. Informationen zum Ändern des Aufbewahrungszeitraums für Backups für eine DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). Sie können keinen benutzerdefinierten Aufbewahrungszeitraum für Backups für Multi-AZ-DB-Cluster konfigurieren.
Wenn Sie ein Hauptversions-Upgrade einer DB-Instance durchführen, werden auch alle in der Region befindlichen Lesereplikate automatisch aktualisiert. Nach dem Start des Upgrade-Workflows warten die Lesereplikate auf den erfolgreichen Abschluss des `pg_upgrade` auf der primären DB-Instance. Dann wartet das Upgrade der primären DB-Instance auf den Abschluss der Upgrades der Lesereplikate. Bis das Upgrade abgeschlossen ist, treten Ausfälle auf. Bei Upgrades der Hauptversion eines Multi-AZ-DB-Clusters ändert sich der Replikationsstatus der Lesereplikate in **Beendet**.
Nachdem ein Upgrade abgeschlossen ist, können Sie nicht zur vorherigen Version der DB-Engine zurückkehren. Wenn Sie zur vorherigen Version zurückkehren möchten, stellen Sie den DB-Snapshot wieder her, der vor dem Upgrade erstellt wurde, um eine neue Datenbank zu erstellen.
## Finden gültiger Upgrade-Ziele
Wenn Sie das verwenden, AWS-Managementkonsole um eine Datenbank zu aktualisieren, werden die gültigen Upgrade-Ziele für die Datenbank angezeigt. Sie können auch den folgenden AWS CLI Befehl verwenden, um die gültigen Upgrade-Ziele für eine Datenbank zu identifizieren:
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Um beispielsweise die gültigen Upgrade-Ziele für eine PostgreSQL-Datenbank der Version 16.1 zu identifizieren, führen Sie den folgenden Befehl aus: AWS CLI
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# PostgreSQL-Versionsnummern
Die Versionsnummerierungssequenz für die PostgreSQL-Datenbank-Engine lautet wie folgt:
+ Für PostgreSQL-Versionen 10 und höher weist die Engine-Versionsnummer das Format *Hauptversion.Unterversion* auf. Die Hauptversionsnummer ist der ganzzahlige Teil der Versionsnummer. Die Nebenversionsnummer ist der Nachkommabereich der Versionsnummer.
Ein Upgrade der Hauptversion erhöht den ganzzahligen Teil der Versionsnummer, z. B. ein Upgrade von 10.*Nebenversion* auf 11.*Nebenversion*.
+ Für PostgreSQL-Versionen vor Version 10 weist die Engine-Versionsnummer das Format *Hauptversion.Hauptversion.Unterversion* auf. Die Engine-Hauptversionsnummer ist sowohl die Ganzzahl als auch der erste Nachkommateil der Versionsnummer. 9.6 ist beispielsweise eine Hauptversion. Die Nebenversionsnummer ist der dritte Teil der Versionsnummer. Beispiel: Für Version 9.6.12 ist die 12 die Nebenversionsnummer.
Ein Upgrade der Hauptversion erhöht den Hauptteil der Versionsnummer. Beispielsweise ist ein Upgrade von *9.6*.12 auf 11.14 ein Upgrade der Hauptversion, wobei *9.6* und *11* die Hauptversionsnummern sind.
Informationen zur Versionsnummerierung von RDS Extended Support finden Sie unter [Versionsnamen bei Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming).
# RDS-Versionsnummern in RDS für PostgreSQL
RDS-Versionsnummern verwenden das Benennungsschema `major.minor.patch`. Eine RDS-Patch-Version enthält wichtige Korrekturen, die einer Nebenversion nach ihrer Veröffentlichung hinzugefügt werden. Informationen zur Versionsnummerierung von RDS Extended Support finden Sie unter [Versionsnamen bei Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming).
Wenn Sie die Amazon-RDS-Versionsnummer Ihrer Datenbank ermitteln möchten, müssen Sie zunächst die `rds_tools`-Erweiterung mit folgendem Befehl erstellen:
```
CREATE EXTENSION rds_tools;
```
Ab der Veröffentlichung von PostgreSQL Version 15.2-R2 können Sie die RDS-Versionsnummer Ihrer Datenbank von RDS für PostgreSQL mit der folgenden SQL-Abfrage ermitteln:
```
postgres=> SELECT rds_tools.rds_version();
```
Wenn Sie beispielsweise eine Datenbank von RDS für PostgreSQL 15.2 abfragen, wird Folgendes zurückgegeben:
```
rds_version
----------------
15.2.R2
(1 row)
```
# Auswählen einer Hauptversion für ein Upgrade von RDS für PostgreSQL
Hauptversions-Upgrades können Änderungen enthalten, die nicht mit früheren Versionen der Datenbank rückwärtskompatibel sind. Neue Funktionalität kann dazu führen, dass Ihre vorhandenen Anwendungen nicht mehr ordnungsgemäß funktionieren. Aus diesem Grund wendet Amazon-RDS-Hauptversions-Upgrades nicht automatisch an. Um ein Hauptversions-Upgrade durchzuführen, ändern Sie Ihre Datenbank manuell. Testen Sie alle Upgrades sorgfältig, um sicherzustellen, dass Ihre Anwendungen ordnungsgemäß funktionieren, bevor Sie das Upgrade auf Ihre Produktionsdatenbanken anwenden. Wenn Sie ein PostgreSQL-Hauptversions-Upgrade durchführen, werden jedoch die folgenden Schritte empfohlen, die unter beschrieben werde [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Wenn Sie eine Single-AZ-DB-Instance- oder eine Multi-AZ-DB-Instance-Bereitstellung von PostgreSQL auf die nächste Hauptversion aktualisieren, werden alle Lesereplikate, die mit der Datenbank verknüpft sind, ebenfalls auf diese nächste Hauptversion aktualisiert. In einigen Fällen können Sie beim Upgrade auf eine höhere Hauptversion springen. Wenn das Upgrade eine Hauptversion überspringt, werden die Lesereplikate auch auf diese Ziel-Hauptversion aktualisiert. Upgrades auf Version 11, die andere Hauptversionen überspringen, haben gewisse Einschränkungen. Die Details finden Sie in den unter [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md) beschriebenen Schritten.
Die meisten PostgreSQL-Erweiterungen werden während eines PostgreSQL-Engine-Upgrades nicht aktualisiert. Diese müssen separat aktualisiert werden. Weitere Informationen finden Sie unter [Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
Sie können herausfinden, welche Hauptversionen für Ihre RDS for PostgreSQL-Datenbank verfügbar sind, indem Sie die folgende AWS CLI Abfrage ausführen:
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
In der folgenden Tabelle finden Sie eine Zusammenfassung der verfügbaren Versionen. Ein Sternchen (\$1) in der Versionsnummer bedeutet, dass die Version nicht mehr unterstützt wird. Wenn Ihre aktuelle Version nicht mehr unterstützt wird, empfehlen wir Ihnen, auf das neueste Upgrade-Ziel der Unterversion oder auf eines der anderen verfügbaren Upgrade-Ziele für diese Version zu aktualisieren.
| Aktuelle Quellversion | Upgrade-Ziele |
| --- | --- |
| 17.6 | Keine |
| 17,5 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17,4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1, 17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16,10 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16,9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16,8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16,7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16,6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.5\$1, 16.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16,3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 16.2\$1, 16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) |
| 15,14 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15,13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12, 15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15,10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15,8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15,7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version167), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version165), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 15.6\$1, 15.5\$1, 15.4\$1, 15.3\$1, 15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) |
| 14,19 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14,18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14,19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17, 14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14,15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14,13 | [16,4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14,12 | [16,3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 14.11\$1, 14.10\$1, 14.9\$1, 14.8\$1, 14.7\$1, 14.6\$1, 14.5\$1, 14.4\$1, 14.3\$1, 14.2\$1, 14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) |
| 13,22 | [17,6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16,10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15,14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14,19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13,21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13,22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20, 13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18, 13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13,16 | [16,4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15,8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13,15 | [16,3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 13.14\$1, 13.13\$1, 13.12\$1, 13.11\$1, 13.10\$1, 13.9\$1, 13.8\$1, 13.7\$1, 13.6\$1, 13.5\$1, 13.4\$1, 13.3\$1, 13.2\$1, 13.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22, 12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1, 12.18\$1, 12.17\$1, 12.16\$1, 12.15\$1, 12.14\$1, 12.13\$1, 12.12\$1, 12.11\$1, 12.10\$1, 12.9\$1, 12.8\$1, 12.7\$1, 12.6\$1, 12.5\$1, 12.4\$1, 12.3\$1, 12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22, 11.21\$1, 11.20\$1, 11.19\$1, 11.18\$1, 11.17\$1, 11.16\$1, 11.15\$1, 11.14\$1, 11.13\$1, 11.12\$1, 11.11\$1, 11.10\$1, 11.9\$1, 11.8\$1, 11.7\$1, 11.6\$1, 11.5\$1, 11.4\$1, 11.2\$1, 11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418), [11.22-rds.20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509), [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
\$1 Diese Version wird nicht mehr unterstützt.
# Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL
Wir empfehlen den folgenden Vorgang bei der Durchführung eines Hauptversions-Upgrades in einer Datenbank von Amazon RDS für PostgreSQL:
1. **Bereithalten einer versionskompatiblen Parametergruppe** – Wenn Sie eine benutzerdefinierte Parametergruppe verwenden, haben Sie zwei Optionen. Sie können eine Standardparametergruppe für die neue DB-Engine-Version angeben. Oder Sie können eine eigene benutzerdefinierte Parametergruppe für die neue DB-Engine-Version erstellen. Weitere Informationen erhalten Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md) und [Arbeiten mit DB-Cluster-Parametergruppen für Multi-AZ-DB-Cluster](USER_WorkingWithDBClusterParamGroups.md).
1. **Nach nicht unterstützten Datenbankklassen suchen** – Überprüfen Sie, ob die Instance-Klasse Ihrer Datenbank mit der PostgreSQL-Version kompatibel ist, auf die Sie aktualisieren. Weitere Informationen finden Sie unter [Unterstützte DB-Engines für DB-Instance-Klassen](Concepts.DBInstanceClass.Support.md).
1. **Auf nicht unterstützte Verwendung prüfen:**
+ **Vorbereitete Transaktionen**: Übernehmen Sie oder machen Sie alle offenen vorbereiteten Transaktionen rückgängig, bevor Sie ein Upgrade durchführen.
Mit der folgenden Abfrage können Sie sicherstellen, dass für Ihre Datenbank keine geöffneten vorbereiteten Transaktionen vorhanden sind.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ **Reg\$1-Datentypen** – Entfernen Sie alle Anwendungen der *reg\$1*-Datentypen, bevor Sie versuchen, einen Upgrade durchzuführen. Bis auf `regtype` und `regclass` ist kein Upgrade der *reg\$1*-Datentypen möglich. Das Dienstprogramm `pg_upgrade` kann diesen Datentyp nicht beibehalten, der von Amazon RDS für das Upgrade verwendet wird.
Um zu überprüfen, dass keine Anwendungen der nicht unterstützten *reg\$1*-Datentypen vorhanden sind, geben Sie für jede Datenbank die folgende Abfrage aus.
```
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid
AND NOT a.attisdropped
AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
'pg_catalog.regprocedure'::pg_catalog.regtype,
'pg_catalog.regoper'::pg_catalog.regtype,
'pg_catalog.regoperator'::pg_catalog.regtype,
'pg_catalog.regconfig'::pg_catalog.regtype,
'pg_catalog.regdictionary'::pg_catalog.regtype)
AND c.relnamespace = n.oid
AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
1. **Suchen nach ungültigen Datenbanken:**
+ Stellen Sie sicher, dass keine ungültigen Datenbanken vorhanden sind. Die Spalte `datconnlimit` im Katalog `pg_database` enthält den Wert `-2`, um Datenbanken, die während eines `DROP DATABASE`-Vorgangs unterbrochen wurden, als ungültig zu kennzeichnen.
Verwenden Sie die folgende Abfrage, um nach ungültigen Datenbanken zu suchen:
```
SELECT datname FROM pg_database WHERE datconnlimit = - 2;
```
+ Die vorherige Abfrage gibt ungültige Datenbanknamen zurück. Sie können `DROP DATABASE invalid_db_name;` verwenden, um ungültige Datenbanken zu entfernen. Sie können auch den folgenden Befehl verwenden, um ungültige Datenbanken zu entfernen:
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
Weitere Informationen zu ungültigen Datenbanken finden Sie unter [Verstehen des Verhaltens der Selbstbereinigung bei ungültigen Datenbanken](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html).
1. **Umgang mit logischen Replikations-Slots** – Ein Upgrade ist nicht möglich, wenn die Datenbank über logische Replikations-Slots verfügt. Logische Replikations-Slots werden normalerweise für die AWS DMS -Migration verwendet und zum Replizieren Datenbanktabellen in Data Lakes, BI-Tools und anderen Zielen. Stellen Sie vor dem Upgrade sicher, dass Sie den Zweck aller verwendeten logischen Replikations-Slots kennen, und bestätigen Sie, dass sie gelöscht werden können. Wenn die logischen Replikations-Slots noch verwendet werden, sollten Sie sie nicht löschen, und Sie können mit dem Upgrade nicht fortfahren.
Wenn die logischen Replikations-Slots nicht benötigt werden, können Sie sie mit folgendem SQL-Befehl löschen:
```
SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);
```
Für die Einrichtung von logische Replikationsszenarien, die die `pglogical`-Erweiterung verwenden, müssen außerdem Slots gelöscht werden, damit ein Hauptversions-Upgrade erfolgreich durchgeführt werden kann. Informationen zum Identifizieren und Löschen von Slots, die mit der `pglogical`-Erweiterung erstellt wurden, finden Sie unter [Verwaltung logischer Replikationsslots für ](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
Bei Quellversion 17 und höher non-read-replicas können die eingeschalteten logischen Replikationssteckplätze durch Upgrades beibehalten werden. Logische Replikationsslots, die auf Read Replicas erstellt wurden, werden bei Upgrades nicht beibehalten.
Stellen Sie sicher, dass alle Transaktionen und logischen Decodierungsnachrichten aus dem Steckplatz abgerufen wurden, bevor Sie das Upgrade starten. Wenn nicht verbrauchte Write-Ahead-Protokolldateien (WAL) in den Steckplätzen für logische Replikation vorhanden sind, schlägt das Upgrade fehl und es wird eine Meldung angezeigt, die die problematischen Steckplätze identifiziert. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-upgrade.html).
Stellen Sie bei Multi-AZ-Clustern mit Quellversionen vor 17.8 oder 18.2 sicher, dass diese Option deaktiviert ist. `flow_control` Weitere Informationen finden Sie unter [Ein- und Ausschalten der Flusskontrolle für Multi-AZ-DB-Cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag). Sie können die Flusskontrolle ausschalten, indem Sie die Erweiterung aus `shared_preload_libraries` entfernen und Ihre DB-Instance neu starten.
1. **Behandlung von Lesereplikaten** – Bei einem Upgrade Single-AZ-DB-Instance- oder Multi-AZ-DB-Instance-Bereitstellung werden neben der primären DB-Instance auch die Lesereplikate in der Region aktualisiert. Amazon RDS aktualisiert keine Lesereplikate von Multi-AZ-DB-Clustern.
Lesereplikate können nicht separat aktualisiert werden. Wenn möglich, kann dies zu Situationen führen, in denen die primären und die Replikat-Datenbanken unterschiedliche PostgreSQL-Hauptversionen haben. Lesereplika-Upgrades können jedoch die Ausfallzeit der primären DB-Instance erhöhen. Um ein Lesereplikat-Upgrade zu verhindern, befördern Sie das Replikat zu einer eigenständigen Instance oder löschen Sie es, bevor Sie den Upgrade-Prozess starten.
Der Upgrade-Prozess erstellt die Parametergruppe des Lesereplikats auf der Grundlage der aktuellen Parametergruppe des Lesereplikats neu. Sie können eine benutzerdefinierte Parametergruppe erst dann auf ein Lesereplikat anwenden, wenn die Aktualisierung abgeschlossen ist, indem Sie das Lesereplikat modifizieren. Weitere Informationen über Lesereplikate finden Sie unter [Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
1. **Umgang mit großen Objekten** — In PostgreSQL werden große Objekte (auch bekannt als BLOBs) verwendet, um große binäre Objekte (wie Dateien, Bilder, Videos usw.) zu speichern und zu verwalten, die größer sind als die maximale Größe, die für reguläre Spaltendatentypen zulässig ist. Weitere Informationen finden Sie in der Dokumentation zu [PostgreSQL Large Objects](https://www.postgresql.org/docs/current/largeobjects.html).
Bei einem Upgrade kann der Arbeitsspeicher knapp werden und es kann fehlschlagen, wenn es Millionen großer Objekte gibt und die Instanz diese während eines Upgrades nicht verarbeiten kann. Der Upgrade-Prozess für die PostgreSQL-Hauptversion besteht aus zwei großen Phasen: dem Dumping des Schemas über pg\$1dump und dem Wiederherstellen über pg\$1restore. Wenn Ihre Datenbank Millionen großer Objekte enthält, müssen Sie sicherstellen, dass Ihre Instanz über ausreichend Speicher verfügt, um pg\$1dump und pg\$1restore während eines Upgrades zu verarbeiten, und sie auf einen größeren Instanztyp skalieren.
Bevor Sie mit einem Upgrade beginnen, überprüfen Sie, ob Ihre Datenbank große Objekte enthält. Der Katalog `pg_largeobject_metadata` enthält Metadaten, die großen Objekten zugeordnet sind. Die eigentlichen großen Objektdaten werden in gespeichert`pg_largeobject`. Verwenden Sie die folgende Abfrage, um die Anzahl der großen Objekte zu überprüfen:
```
SELECT count(*) FROM pg_largeobject_metadata;
```
Informationen zum Bereinigen vorhandener großer Objekte oder verwaister großer Objekte finden Sie unter [Große Objekte mit dem Modul lo verwalten](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html).
Wenn Sie ein Upgrade auf eine Hauptversion planen, empfehlen wir, einen Instanztyp mit mindestens 32 GB Arbeitsspeicher zu verwenden, wenn Ihre Datenbank 25 bis 30 Millionen große Objekte enthält. Diese Empfehlung basiert auf unseren Tests und kann je nach Ihrer spezifischen Arbeitslast und Datenbankkonfiguration variieren. Wenn Ihre Datenbank zusätzliche Objekte (wie Tabellen, Indizes oder materialisierte Ansichten) enthält, empfehlen wir, einen größeren Instance-Typ auszuwählen, um eine optimale Leistung während des Upgrade-Prozesses sicherzustellen.
1. **Handhabung von Null-ETL-Integrationen** – Wenn Sie bereits über eine [Null-ETL-Integration](zero-etl.md) verfügen, [löschen Sie diese](zero-etl.deleting.md), bevor Sie ein Upgrade einer Hauptversion durchführen. Erstellen Sie nach Abschluss des Upgrades die Integration neu.
Bei den Quellversionen Major 17 und höher kann die Zero-ETL-Integration während des Upgrades beibehalten werden.
1. **Durchführen einer Sicherung** – Wir empfehlen, vor dem Upgrade der Hauptversion eine Sicherung durchzuführen, damit Sie über einen bekannten Wiederherstellungspunkt für Ihre Datenbank verfügen. Wenn der Wert des Aufbewahrungszeitraums für Ihre Sicherung größer als 0 ist, erstellt der Upgrade-Vorgang vor und nach der Aktualisierung DB-Snapshots Ihrer Datenbank. Informationen über das Ändern Ihres Aufbewahrungszeitraums für Backups finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md) und [Ändern eines Multi-AZ-DB-Clusters für Amazon RDS](modify-multi-az-db-cluster.md).
Informationen zum manuellen Durchführen der Sicherung finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md) und [Erstellen eines DB-Cluster-Snapshots mit Multi-AZ für Amazon RDS](USER_CreateMultiAZDBClusterSnapshot.md).
1. **Aktualisieren bestimmter Erweiterungen vor dem Upgrade der Hauptversion** – Wenn Sie planen, eine Hauptversion mit dem Upgrade zu überspringen, müssen Sie bestimmte Erweiterungen aktualisieren *bevor* Sie das Upgrade der Hauptversion durchführen. Zum Beispiel überspringt ein Upgrade von den Versionen 9.5.x oder 9.6.x auf die Versionen 11.x eine Hauptversion. Zu den zu aktualisierenden Erweiterungen gehören PostGIS und zugehörige Erweiterungen für die Verarbeitung räumlicher Daten.
+ `address_standardizer`
+ `address_standardizer_data_us`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
Sie können aufgrund der `rdkit`-Inkompatibilität nicht direkt auf PostgreSQL-Version 17 aktualisieren, wenn Sie `rdkit`-Version 4.6.0 und niedriger sowie PostgreSQL-Version 16 und niedriger verwenden. Im Folgenden finden Sie die Upgrade-Optionen:
+ Wenn Sie PostgreSQL-Version 13 und niedriger verwenden, müssen Sie zuerst ein Hauptversion-Upgrade auf Version 14.14 und höhere 14-Versionen, 15.9 und höhere 15-Versionen oder 16.5 und höhere 16-Versionen durchführen und dann das Upgrade auf PostgreSQL-Version 17.
+ Wenn Sie PostgreSQL-Version 14, 15 oder 16 verwenden, müssen Sie zuerst ein Unterversion-Upgrade auf Version 14.14 und höhere 14-Versionen, 15.9 und höhere 15-Versionen oder 16.5 und höhere 16-Versionen durchführen und dann das Upgrade auf PostgreSQL-Version 17.
Führen Sie den folgenden Befehl für jede von Ihnen verwendete Erweiterung aus:
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Weitere Informationen finden Sie unter [Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md). Weitere Informationen über PostGIS-Upgrades finden Sie unter [Schritt 6: Upgrade der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. **Löschen Sie bestimmte Erweiterungen vor dem Upgrade der Hauptversion** — Erweiterungen, die in der Zielversion nicht unterstützt werden, müssen gelöscht werden. Andernfalls schlägt das Upgrade fehl.
Die `plrust` Erweiterung wird ab RDS PostgreSQL 18 entfernt. [Die `postgis_topology` Erweiterung ist in den RDS PostgreSQL-Versionen 18.1 und 18.2 aufgrund bekannter Probleme [[1](https://trac.osgeo.org/postgis/ticket/5983)], [2] nicht verfügbar.](https://trac.osgeo.org/postgis/ticket/6016) Diese Erweiterungen müssen vor dem Upgrade entfernt werden.
Ein Upgrade, bei dem eine Hauptversion auf Version 11.x übersprungen wird, unterstützt die Aktualisierung der `pgRouting` Erweiterung nicht. Ein Upgrade von den Versionen 9.4.x, 9.5.x oder 9.6.x auf 11.x-Versionen überspringt eine Hauptversion. Es ist sicher, die Erweiterung `pgRouting` zu verwerfen zu lassen und sie nach dem Upgrade wieder auf eine kompatible Version zu installieren. Für die Erweiterungsversionen, auf die Sie aktualisieren können, lesen Sie [Unterstützte PostgreSQL-Erweiterungsversionen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Die Erweiterungen `tsearch2` und `chkpass` werden für PostgreSQL ab Version 11 nicht mehr unterstützt.
Mit der folgenden Abfrage können Sie überprüfen, ob eine Erweiterung installiert ist:
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **Löschen unbekannter Datentypen** – Löschen Sie `unknown`-Datentypen in Abhängigkeit von der Zielversion.
PostgreSQL-Version 10 unterstützt den `unknown`-Datentyp nicht mehr. Wenn eine Datenbank der Version 9.6 den Datentyp `unknown` verwendet, wird bei einem Upgrade auf eine Version 10 eine Fehlermeldung wie die folgende angezeigt:
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
Verwenden Sie die folgende SQL, um den `unknown`-Datentyp in Ihrer Datenbank zu finden, damit Sie die betroffene Spalte entfernen oder in einen unterstützten Datentyp ändern können:
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
1. **Durchführen eines Upgrade-Trockenlaufs** – Wir empfehlen dringend, ein Hauptversionsupgrade auf einem Duplikat Ihrer Produktionsdatenbank zu testen, bevor Sie das Upgrade auf Ihrer Produktionsdatenbank durchführen. Sie können die Ausführungspläne auf der duplizierten Testdatenbank auf mögliche Regressionen des Ausführungsplans überwachen und deren Leistung bewerten. Um eine doppelte Testinstanz zu erstellen, können Sie Ihre Datenbank entweder aus einem aktuellen Snapshot point-in-time wiederherstellen oder Ihre Datenbank auf den letzten wiederherstellbaren Zeitpunkt zurücksetzen.
Für weitere Informationen siehe [Wiederherstellung aus einem Snapshot](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring) oder [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md). Informationen zu Multi-AZ-DB-Clustern finden Sie unter [Wiederherstellen von einem Snapshot in einem Multi-AZ-DB-Cluster](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md) oder [Wiederherstellen eines Multi-AZ-DB-Clusters zu einer bestimmten Zeit](USER_PIT.MultiAZDBCluster.md).
Weitere Einzelheiten zum Durchführen des Upgrades finden Sie unter [Manuelles Upgraden der Engine-Version](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Beachten Sie beim Upgrade einer Datenbank der Version 9.6 auf Version 10, dass PostgreSQL 10 standardmäßig parallele Abfragen aktiviert. Sie können die Auswirkungen von Parallelverarbeitung *vor* dem Upgrade testen, indem Sie den Parameter `max_parallel_workers_per_gather` in Ihrer Testdatenbank auf 2 ändern.
**Anmerkung**
Der Standardwert für `max_parallel_workers_per_gather`-Parameter in der `default.postgresql10`-DB-Parametergruppe lautet 2.
Weitere Informationen finden Sie unter [Parallel Query](https://www.postgresql.org/docs/10/parallel-query.html) in der PostgreSQL-Dokumentation. Um die Parallelverarbeitung in Version 10 zu deaktivieren, setzen Sie den Parameter `max_parallel_workers_per_gather` auf 0.
Während des Upgrades der Hauptversion werden die Datenbanken `public` und `template1` und das Schema `public` in jeder Datenbank vorübergehend umbenannt. Diese Objekte erscheinen in den Protokollen mit ihrem ursprünglichen Namen und einer zufälligen Zeichenfolge, die angehängt wird. Die Zeichenfolge wird so hinzugefügt, dass benutzerdefinierte Einstellungen wie `locale` und `owner` während des Upgrades der Hauptversion erhalten bleiben. Sobald das Upgrade abgeschlossen ist, werden die Objekte in ihre ursprünglichen Namen umbenannt.
**Anmerkung**
Während des Upgrade-Vorgangs für die Hauptversion können Sie keine point-in-time Wiederherstellung Ihrer DB-Instance oder Ihres Multi-AZ-DB-Clusters durchführen. Nachdem das Upgrade von Amazon RDS durchgeführt wurde, wird eine automatische Sicherung der Datenbank vorgenommen. Sie können eine point-in-time Wiederherstellung zu den Zeiten vor Beginn des Upgrades und nach Abschluss der automatischen Sicherung Ihrer Datenbank durchführen.
1. **Wenn ein Upgrade mit Fehlern bei der Vorprüfung fehlschlägt, beheben Sie die Probleme** – Während des Upgrades der Hauptversion führt Amazon RDS für PostgreSQL zunächst eine Vorprüfung durch, um alle Probleme zu identifizieren, die dazu führen könnten, dass das Upgrade fehlschlägt. Das Vorprüfverfahren überprüft alle potenziell nicht kompatiblen Bedingungen in allen Datenbanken der Instance.
Wenn die Vorprüfung auf ein Problem stößt, wird ein Protokollereignis erstellt, das anzeigt, dass die Vorprüfung für das Upgrade fehlgeschlagen ist. Die Details des Vorprüfprozesses befinden sich in einem Upgrade-Protokoll mit dem Namen `pg_upgrade_precheck.log` für alle Datenbanken einer Datenbank. Amazon RDS hängt einen Zeitstempel an den Dateinamen an. Weitere Informationen zum Anzeigen von Protokollen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
Wenn ein Lesereplikat-Upgrade bei der Vorprüfung fehlschlägt, wird die Replikation auf dem fehlgeschlagenen Lesereplikat unterbrochen und das Lesereplikat in den Status "beendet" versetzt. Löschen Sie das Lesereplikat und erstellen Sie ein neues Lesereplikat auf der Grundlage der aktualisierten primären DB-Instance.
Beheben Sie alle im Vorprüfprotokoll identifizierten Probleme und versuchen Sie dann erneut das Hauptversionsupgrade. Im Folgenden finden Sie ein Beispiel für ein Vorprüfprotokoll.
```
------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.
* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.
* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].
* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
1. **Wenn ein Lesereplikat-Upgrade während des Upgrades der Datenbank fehlschlägt, beheben Sie das Problem** – Ein fehlgeschlagenes Lesereplikat wird in den Zustand `incompatible-restore` versetzt und die Replikation auf der Datenbank wird beendet. Löschen Sie das Lesereplikat und erstellen Sie ein neues Lesereplikat auf der Grundlage der aktualisierten primären DB-Instance.
**Anmerkung**
Amazon RDS aktualisiert keine Lesereplikate für Multi-AZ-DB-Cluster. Bei Upgrades der Hauptversion eines DB-Clusters mit Multi-AZ ändert sich der Replikationsstatus der Lesereplikate in **Beendet**.
Ein Lesereplikat-Upgrade kann aus den folgenden Gründen fehlschlagen:
+ Sie konnte die primäre DB-Instance auch nach einer Wartezeit nicht einholen.
+ Es befand sich in einem beendeten oder inkompatiblen Lebenszyklusstatus, z. B. „Speicher voll“, „Inkompatible Wiederherstellung“ usw.
+ Als das Upgrade der primären DB-Instance begann, lief auf der Lesereplikat bereits ein separates Upgrade der Unterversion.
+ Das Lesereplikat verwendete inkompatible Parameter.
+ Das Lesereplikat war nicht in der Lage, mit der primären DB-Instance zu kommunizieren, um den Datenordner zu synchronisieren.
1. **Upgrade Ihrer Produktionsdatenbank** – Wenn das Upgrade der Hauptversion erfolgreich durchgeführt wurde, sollten Sie in der Lage sein, Ihre Produktionsdatenbank sicher zu aktualisieren. Weitere Informationen finden Sie unter [Manuelles Upgraden der Engine-Version](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
1. Führen Sie die `ANALYZE`-Operation aus, um die Tabelle `pg_statistic` zu aktualisieren. Führen Sie diesen Schritt für jede Datenbank auf all Ihren PostgreSQL-Datenbanken durch. Optimizer-Statistiken werden während eines Hauptversionsupgrades nicht übertragen, daher müssen Sie alle Statistiken neu generieren, um Leistungsprobleme zu vermeiden. Führen Sie den Befehl ohne Parameter aus, um Statistiken für alle regulären Tabellen in der aktuellen Datenbank wie folgt zu generieren:
```
ANALYZE VERBOSE;
```
Das Flag `VERBOSE` ist optional, aber wenn Sie es verwenden, wird Ihnen der Fortschritt angezeigt. Weitere Informationen finden Sie unter [ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html) in der PostgreSQL-Dokumentation.
Wenn Sie bestimmte Tabellen analysieren, anstatt ANALYZE VERBOSE zu verwenden, führen Sie den Befehl ANALYZE für jede Tabelle wie folgt aus:
```
ANALYZE table_name;
```
Analysieren Sie bei partitionierten Tabellen immer die übergeordnete Tabelle. Dieser Prozess beinhaltet Folgendes:
+ Automatisches Stichprobenverfahren für Zeilen in allen Partitionen
+ Rekursives Aktualisieren der Statistiken für jede Partition
+ Verwalten wichtiger Planungsstatistiken auf übergeordneter Ebene
In übergeordneten Tabellen werden zwar keine tatsächlichen Daten gespeichert, ihre Analyse ist jedoch für die Abfrageoptimierung von entscheidender Bedeutung. Wenn ANALYZE nur auf einzelnen Partitionen ausgeführt wird, kann dies zu einer schlechten Abfrageleistung führen, da der Optimierer nicht über die umfassenden Statistiken verfügt, die für eine effiziente partitionsübergreifende Planung erforderlich sind.
**Anmerkung**
Führen Sie ANALYZE nach dem Upgrade auf Ihrem System aus, um Leistungsprobleme zu vermeiden.
Nachdem das Upgrade der Hauptversion abgeschlossen ist, empfehlen wir Folgendes:
+ Bei einem PostgreSQL-Upgrade werden keine PostgreSQL-Erweiterungen aktualisiert. Informationen zum Upgrade von Erweiterungen finden Sie unter [Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ Verwenden Sie optional Amazon RDS, um zwei Protokolle anzuzeigen, die das Dienstprogramm `pg_upgrade` erstellt. Diese sind `pg_upgrade_internal.log` und `pg_upgrade_server.log`. Amazon RDS hängt einen Zeitstempel an den Dateinamen für diese Protokolle an. Sie können diese Protokolle wie jedes andere Protokoll einsehen. Weitere Informationen finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
Sie können die Upgrade-Protokolle auch auf Amazon CloudWatch Logs hochladen. Weitere Informationen finden Sie unter [PostgreSQL-Protokolle in Amazon Logs veröffentlichen CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
+ Um sicherzustellen, dass alles wie erwartet funktioniert, testen Sie Ihre Anwendung auf der aktualisierten Datenbank mit ähnlichem Workload. Nachdem das Upgrade bestätigt wurde, können Sie diese Testinstance löschen.
# Automatische Unterversion-Upgrades von RDS für PostgreSQL
Wenn Sie beim Erstellen oder Ändern einer DB-Instance oder eines Multi-AZ-DB-Clusters die Option **Automatisches Unterversion-Upgrade** aktivieren, können Sie Ihre Datenbank automatisch aktualisieren lassen.
Amazon RDS unterstützt auch Upgrade-Rollout-Richtlinien zur Verwaltung automatischer Upgrades kleinerer Versionen für mehrere Datenbankressourcen und AWS-Konten. Weitere Informationen finden Sie unter [Verwendung der AWS Organizations Upgrade-Rollout-Richtlinie für automatische Upgrades kleinerer Versionen](RDS.Maintenance.AMVU.UpgradeRollout.md).
Für jede Major-Version von RDS für PostgreSQL wird von RDS eine Minor-Version als automatische Upgradeversion gekennzeichnet. Nachdem eine Minor-Version von Amazon RDS getestet und freigegeben wurde, erfolgt das Upgrade der Minor-Version automatisch während Ihres Wartungsfensters. RDS legt nicht automatisch neuere freigegebene Minor-Versionen als die automatische Upgradeversion fest. Bevor RDS eine neuere automatische Upgradeversion bestimmt, werden mehrere Kriterien berücksichtigt, wie beispielsweise die folgenden:
+ Bekannte Sicherheitsprobleme
+ Fehler in der PostgreSQL-Community-Version
+ Gesamtflottenstabilität seit Erscheinen der Minor-Version
Sie können den folgenden AWS CLI Befehl verwenden, um die aktuelle automatische Minor-Upgrade-Zielversion für eine angegebene PostgreSQL-Nebenversion in einem bestimmten Bereich zu ermitteln. AWS-Region
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Der folgende AWS CLI Befehl bestimmt beispielsweise das automatische kleinere Upgrade-Ziel für die PostgreSQL-Nebenversion 16.1 in den USA Ost (Ohio) AWS-Region (us-east-2).
Für Linux, macOS oder Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Für Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Ihre Ausgabe sieht Folgendem ähnlich.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
In diesem Beispiel ist der `AutoUpgrade`-Wert `True` für PostgreSQL-Version 16.3. Das automatische Unterversion-Upgrade-Ziel ist daher PostgreSQL-Version 16.3, die in der Ausgabe hervorgehoben wird.
Eine PostgreSQL-Datenbank wird während Ihres Wartungsfensters automatisch aktualisiert, wenn die folgenden Kriterien erfüllt sind:
+ Für die Datenbank ist die Option **Automatisches Unterversion-Upgrade** aktiviert.
+ Die Datenbank führt eine Unterversion der DB-Engine aus, die niedriger ist als die aktuelle Unterversion des automatischen Upgrades.
Weitere Informationen finden Sie unter [Automatisches Upgraden der Engine-Unterversion](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
**Anmerkung**
Bei einem PostgreSQL-Upgrade werden keine PostgreSQL-Erweiterungen aktualisiert. Informationen zum Upgrade von Erweiterungen finden Sie unter [Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
# Aktualisieren von PostgreSQL-Erweiterungen in Datenbank von RDS für PostgreSQL
Bei einem PostgreSQL-Engine-Upgrade werden die meisten PostgreSQL-Erweiterungen nicht aktualisiert. Um eine Erweiterung nach einem Upgrade auf eine Nebenversion zu aktualisieren, verwenden Sie den Befehl `ALTER EXTENSION UPDATE`.
**Anmerkung**
Hinweise zum Aktualisieren der PostGIS-Erweiterung finden Sie unter [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Schritt 6: Upgrade der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
Um die `pg_repack`-Erweiterung zu aktualisieren, entfernen Sie die Erweiterung und erstellen Sie eine neue Version in der aktualisierten Datenbank. Weitere Informationen finden Sie unter [pg\$1repack installation](https://reorg.github.io/pg_repack/) in der `pg_repack`-Dokumentation.
Um eine Erweiterung zu aktualisieren, verwenden Sie den folgenden Befehl.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Eine Liste unterstützter Versionen von PostgreSQL-Erweiterungen finden Sie unter [Unterstützte PostgreSQL-Erweiterungsversionen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Um Ihre derzeit installierten Erweiterungen aufzulisten, verwenden Sie den PostgreSQL-Katalog [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) in dem folgenden Befehl.
```
SELECT * FROM pg_extension;
```
Um eine Liste der spezifischen Erweiterungsversionen anzuzeigen, die zur Installation verfügbar sind, verwenden Sie die PostgreSQL-Ansicht [pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) in dem folgenden Befehl.
```
SELECT * FROM pg_available_extension_versions;
```
# Überwachung von RDS für PostgreSQL-Engine-Upgrades mit Ereignissen
Wenn Sie die Engine-Version einer RDS for PostgreSQL-Datenbank aktualisieren, gibt Amazon RDS in jeder Phase des Prozesses ein bestimmtes Ereignis aus. Um den Fortschritt eines Upgrades zu verfolgen, können Sie diese Ereignisse anzeigen oder abonnieren.
Weitere Informationen zu RDS-Ereignissen finden Sie unter[Überwachung von Amazon-RDS-Ereignissen](working-with-events.md).
Ausführliche Informationen zu einem bestimmten Amazon RDS-Ereignis, das während Ihres Engine-Upgrades auftritt, finden Sie unter[Amazon RDS-Ereigniskategorien und Ereignisnachrichten ](USER_Events.Messages.md).
# Aktualisieren einer Engine-Version für PostgreSQL-DB-Snapshots
Mit Amazon RDS können Sie einen DB-Snapshot für das Speicher-Volume Ihrer PostgreSQL-DB-Instance erstellen. Wenn Sie einen DB-Snapshot erstellen, basiert dieser auf der Engine-Version, die von der Amazon-RDS-Instance verwendet wird. Sie können die Engine-Version für Ihre DB-Snapshots aktualisieren.
Wenn Sie einen DB-Snapshot wiederherstellen, der auf eine neue Engine-Version aktualisiert wurde, sollten Sie prüfen, ob das Upgrade erfolgreich durchgeführt wurde. Weitere Informationen zu größeren Versionsaktualisierungen finden Sie unter [Upgrades der DB-Engine von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md). Informationen zum Wiederherstellen eines DB-Snapshots finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md).
Sie können manuelle DB-Snapshots aktualisieren, die verschlüsselt oder nicht verschlüsselt sind.
Verwenden Sie das folgende AWS CLI Beispiel, um die verfügbaren Engine-Versionen für Ihren RDS for PostgreSQL-DB-Snapshot anzuzeigen.
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
Weitere Informationen zu verfügbaren Engine-Versionen für DB-Snapshots für RDS für PostgreSQL finden Sie unter [Auswählen einer Hauptversion für ein Upgrade von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**Anmerkung**
Sie können keine Upgrades für DB-Snapshots durchführen, die durch automatisierte Sicherungsvorgänge erstellt wurden.
## Konsole
**So führen Sie ein Upgrade eines DB-Snapshots durch**
1. Melden Sie sich bei der an AWS-Managementkonsole und ö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 die Option **Snapshots**.
1. Wählen Sie den Snapshot für die Aktualisierung aus.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Upgrade Snapshot (Snapshot aktualisieren)**. Die Seite **Upgrade snapshot (Snapshot aktualisieren)** erscheint.
1. Wählen Sie zum Aktualisieren **New engine version (Neue Engine-Version)**.
1. Wählen Sie **Save changes (Änderungen speichern)**, um den Snapshot zu aktualisieren.
Während des Upgrades werden alle Snapshot-Aktionen für diesen DB-Snapshot deaktiviert. Außerdem wird der Status des DB-Snapshots von **available** (verfügbar) in **upgraden...** geändert. Wenn der Vorgang abgeschlossen wurde, wird der Status in **active** (aktiv) geändert. Wenn das Upgrade für den DB-Snapshot aufgrund einer Beschädigung des Snapshots nicht durchgeführt werden kann, wird der Status in **unavailable** (nicht verfügbar) geändert. Sie können den Snapshot aus diesem Zustand nicht wiederherstellen.
**Anmerkung**
Wenn die Aktualisierung des DB-Snapshots fehlschlägt, wird der Snapshot wieder in seinen ursprünglichen Zustand zurückgebracht.
## AWS CLI
Verwenden Sie den AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)Befehl, um einen DB-Snapshot auf eine neue Version der Datenbank-Engine zu aktualisieren.
**Parameters**
+ `--db-snapshot-identifier`: die Kennung des DB-Snapshots, für den das Upgrade durchgeführt werden soll Die Kennung muss ein eindeutiger Amazon-Ressourcenname (ARN) sein. Weitere Informationen finden Sie unter [Amazon-Ressourcennamen (ARN) in Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version`: Die Engine-Version, auf die das Upgrade des DB-Snapshots durchgeführt werden soll
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Für Windows:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## RDS-API
Um einen DB-Snapshot auf eine neue Version der Datenbank-Engine zu aktualisieren, rufen Sie den Amazon DBSnapshot RDS-API-Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) auf.
+ `DBSnapshotIdentifier`: die Kennung des DB-Snapshots, für den das Upgrade durchgeführt werden soll Die Kennung muss ein eindeutiger Amazon-Ressourcenname (ARN) sein. Weitere Informationen finden Sie unter [Amazon-Ressourcennamen (ARN) in Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion`: Die Engine-Version, auf die das Upgrade des DB-Snapshots durchgeführt werden soll
# Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL
Sie können Lesevorgänge für Ihre DB-Instances von Amazon RDS für PostgreSQL skalieren, indem Sie den Instances Lesereplikate hinzufügen. Wie bei anderen Datenbank-Engines von Amazon RDS verwendet RDS für PostgreSQL die nativen Replikationsmechanismen von PostgreSQL, um Lesereplikate im Hinblick auf Änderungen an der Quell-DB auf dem neuesten Stand zu halten. Allgemeine Informationen zu Lesereplikaten und Amazon RDS finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten in RDS für PostgreSQL.
## Read Replica-Beschränkungen unter PostgreSQL
Für PostgreSQL-Lesereplikate gelten folgende Beschränkungen:
+ PostgreSQL-Lesereplikate sind schreibgeschützt. Auch wenn ein Lesereplikat keine beschreibbare DB-Instance ist, können Sie es zu einer eigenständigen RDS-for-PostgreSQL-DB-Instance hochstufen. Der Prozess kann jedoch nicht rückgängig gemacht werden.
+ Sie können kein Lesereplikat aus einem anderen Lesereplikat erstellen, falls auf Ihrer RDS-for-PostgreSQL-DB-Instance eine frühere PostgreSQL-DB-Version als 14.1 ausgeführt wird. RDS für PostgreSQL unterstützt kaskadierende Lesereplikate nur in RDS für PostgreSQL Version 14.1 und höher. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Wenn Sie ein PostgreSQL-Lesereplikat hochstufen, wird es zu einer beschreibbaren DB-Instance. Es empfängt keine Write-Ahead Log (WAL)-Dateien von einer DB-Quell-Instance mehr und ist keine schreibgeschützte Instance mehr. Sie können neue Lesereplikate aus der hochgestuften DB-Instance erstellen wie für jede andere RDS-for-PostgreSQL-DB-Instance. Weitere Informationen finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
+ Wenn Sie ein PostgreSQL-Lesereplikat aus einer Replikationskette (eine Reihe kaskadierender Lesereplikate) heraus hochstufen, erhalten alle vorhandenen Downstream-Lesereplikate weiterhin automatisch WAL-Dateien von der hochgestuften Instance. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Wenn keine Benutzertransaktionen auf der Quell-DB-Instance laufen, meldet das zugehörige PostgreSQL-Lesereplikat eine Replikationsverzögerung von bis zu fünf Minuten. Die Replikatverzögerung wird berechnet als `currentTime - lastCommitedTransactionTimestamp`, was bedeutet, dass, wenn keine Transaktionen verarbeitet werden, der Wert der Replikatverzögerung für einen bestimmten Zeitraum steigt, bis das Write-Ahead-Log (WAL)-Segment wechselt. Standardmäßig wechselt RDS für PostgreSQL das WAL-Segment alle 5 Minuten, was zu einem Transaktionsdatensatz und einer Verringerung der gemeldeten Verzögerung führt.
+ Sie können keine automatisierten Backups für PostgreSQL-Lesereplikate für RDS für PostgreSQL Versionen vor 14.1 aktivieren. Automatisierte Backups für Lesereplikate werden nur für RDS für PostgreSQL 14.1 und höhere Versionen unterstützt. Erstellen Sie für RDS für PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen.
+ Point-in-time Recovery (PITR) wird für Read Replicas nicht unterstützt. Sie können PITR nur mit einer primären (Writer-) Instance und nicht mit einem Lesereplikat verwenden. Weitere Informationen hierzu finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md).
+ Lesereplikate für PostgreSQL-Version 12 und niedriger werden während des 60–90-tägigen Wartungsfensters automatisch neu gestartet, um die Passwortrotation anzuwenden. Wenn das Replikat vor dem geplanten Neustart die Verbindung zur Quelle verliert, wird es trotzdem neu gestartet, um die Replikation fortzusetzen. Bei PostgreSQL-Version 13 und höher kann es bei Lesereplikaten während der Passwortrotation zu kurzen Unterbrechungen und erneuten Verbindungen bei der Replikation kommen.
# Konfiguration von Read Replicas mit PostgreSQL
RDS for PostgreSQL verwendet die native PostgreSQL-Streaming-Replikation, um eine schreibgeschützte Kopie einer Quell-DB-Instance zu erstellen. Diese Read-Replica-DB-Instance ist eine asynchron erstellte physische Replikation der Quell-DB-Instance. Sie wird von einer speziellen Verbindung erstellt, die Write-Ahead Log (WAL)-Daten zwischen der Quell-DB-Instance und dem Lesereplikat übermittelt. Weitere Informationen finden Sie unter [Streaming-Replikation](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) in der PostgreSQL-Dokumentation.
PostgreSQL streamt Datenbankänderungen asynchron über diese sichere Verbindung, während sie auf der Quell-DB-Instance vorgenommen werden. Sie können die Kommunikation von Ihren Clientanwendungen zur Quell-DB-Instance oder zu allen Lesereplikaten verschlüsseln, indem Sie den Parameter `ssl` auf `1` festlegen. Weitere Informationen finden Sie unter [Verwenden von SSL mit einer PostgreSQL-DB-Instance](PostgreSQL.Concepts.General.SSL.md).
PostgreSQL verwendet eine *Replikations*-Rolle, um die Streaming-Replikation durchzuführen. Die Rolle besitzt Berechtigungen, kann jedoch nicht für das Ändern von Daten verwendet werden. PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation.
Sie können ein PostgreSQL-Lesereplikat erstellen, ohne den Betrieb oder die Benutzer der Quell-DB-Instance zu beeinträchtigen. Amazon RDS legt die erforderlichen Parameter und Berechtigungen für die Quell-DB-Instance und das Lesereplikat ohne Auswirkungen auf den Service fest. Ein Snapshot von der Quell-DB-Instance wird erstellt und zum Erstellen des Lesereplikats verwendet. Wenn Sie das Lesereplikat irgendwann in der Zukunft löschen, tritt kein Ausfall auf.
Sie können bis zu 15 Lesereplikate von einer Quell-DB-Instance innerhalb derselben Region erstellen. Ab RDS for PostgreSQL 14.1 können Sie auch bis zu drei Ebenen von Lesereplikaten in einer Kette (Kaskade) aus einer Quell-DB-Instance erstellen. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). In allen Fällen müssen für die Quell-DB-Instance automatisierte Backups konfiguriert sein. Dazu legen Sie den Aufbewahrungszeitraum für Sicherungen in Ihrer DB-Instance auf einen anderen Wert als 0 fest. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
Sie können Lesereplikate für Ihre DB-Instance von RDS for PostgreSQL in derselben AWS-Region wie Ihre Quell-DB-Instance erstellen. Dies wird als *regionale* Replikation bezeichnet. Sie können Read Replicas auch in einer anderen AWS-Regionen als der Quell-DB-Instance erstellen. Dies wird als *regionsübergreifende* Replikation bezeichnet. Weitere Informationen zum Einrichten von regionsübergreifenden Lesereplikaten finden Sie unter [Erstellen einer Read Replica in einem anderen AWS-Region](USER_ReadRepl.XRgn.md). Die verschiedenen Mechanismen, die den Prozess für die regionale und regionsübergreifende Replikation unterstützen, unterscheiden sich je nach RDS-for-PostgreSQL-Version geringfügig, wie in [Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md) erläutert.
Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über die selbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie unbedingt auch die Lesereplikate.
Amazon RDS überschreibt alle nicht-kompatiblen Parameter in einem Lesereplikat, wenn diese das Lesereplikat vom Hochfahren abhalten. Nehmen Sie beispielsweise an, dass der Wert des Parameters `max_connections` auf der Quell-DB-Instance höher als auf dem Lesereplikat ist. In diesem Fall aktualisiert Amazon RDS den Parameter auf dem Lesereplikat, sodass er denselben Wert wie auf der Quell-DB-Instance hat.
Read Replicas von RDS for PostgreSQL haben Zugriff auf externe Datenbanken, die über Foreign Data Wrappers (FDWs) auf der Quell-DB-Instance verfügbar sind. Angenommen, Ihre RDS-for-PostgreSQL-DB-Instance verwendet den Wrapper `mysql_fdw` für den Zugriff auf Daten von RDS for MySQL. In diesem Fall können Ihre Lesereplikate auch auf diese Daten zugreifen. Zu den weiteren unterstützten FDWs gehören, und. `oracle_fdw` `postgres_fdw` `tds_fdw` Weitere Informationen finden Sie unter [Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Verwenden von RDS-for-PostgreSQL-Lesereplikate mit Multi-AZ-Konfigurationen
Sie können ein Lesereplikat aus einer Single-AZ- oder Multi-AZ-DB-Instance erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten mit einem Standby-Replikat zu verbessern. Ein *Standby-Replikat* ist ein dediziertes Lesereplikat, das die Workload übernehmen kann, wenn die Quell-DB ausfällt. Sie können Ihr Standby-Replikat nicht dazu verwenden, Leseverkehr bereitzustellen. Sie können jedoch Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie unter [Bereitstellungen von Multi-AZ-DB-Instances für Amazon RDS](Concepts.MultiAZSingleStandby.md).
Wenn die Quell-DB-Instance einer Multi-AZ-Bereitstellung ein Failover auf eine Standby-Instance vornimmt, wechseln die zugehörigen Lesereplikate zur Verwendung der Standby-Instance (jetzt primär) als Replikationsquelle. Die Lesereplikate müssen möglicherweise je nach RDS-for-PostgreSQL-Version wie folgt neu gestartet werden:
+ **PostgreSQL 13 und höhere Versionen** – Ein Neustart ist nicht erforderlich. Die Lesereplikate werden automatisch mit der neuen Primär-Instance synchronisiert. In einigen Fällen legt Ihre Clientanwendung jedoch die Details des Domain Name Service (DNS) für Ihre Lesereplikate im Zwischenspeicher ab. Falls ja, setzen Sie den Wert time-to-live (TTL) auf weniger als 30 Sekunden. Damit wird verhindert, dass das Lesereplikat eine veraltete IP-Adresse beibehält (wodurch verhindert wird, dass es mit der neuen Primär-Instance synchronisiert wird). Weitere Informationen über diese und andere bewährte Methoden finden Sie unter [Grundlegende Anleitungen für den Amazon-RDS-Betrieb](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 und alle früheren Versionen** – Die Lesereplikate werden nach einem Failover auf das Standby-Replikat automatisch neu gestartet, da der Standby (jetzt primär) eine andere IP-Adresse und einen anderen Instance-Namen hat. Durch den Neustart wird das Lesereplikat mit der neuen Primär-Instance synchronisiert.
Weitere Informationen zu Failover finden Sie unter [Failover einer Multi-AZ-DB-Instance für Amazon RDS](Concepts.MultiAZ.Failover.md). Weitere Informationen dazu, wie Lesereplikate in einer Multi-AZ-Bereitstellung funktionieren, finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
Wenn Sie Failover-Unterstützung für ein Lesereplikat bereitstellen möchten, können Sie ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt dann eine Standby-Version des Replikats in einer anderen Availability Zone. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.
# Logische Dekodierung auf einem Lesereplikat
RDS für PostgreSQL unterstützt die logische Replikation aus Standbys mit PostgreSQL 16.1. Auf diese Weise können Sie eine logische Dekodierung aus einem schreibgeschützten Standby erstellen, wodurch die Last für die primäre DB-Instance reduziert wird. Sie können eine höhere Verfügbarkeit für Ihre Anwendungen erreichen, die Daten zwischen mehreren Systemen synchronisieren müssen. Dieses Feature steigert die Leistung Ihres Data Warehouse und Ihrer Datenanalyse.
Außerdem sorgen Replikationsslots in einem bestimmten Standby dafür, dass dieses Standby zur primären Instance hochgestuft wird. Das bedeutet, dass im Falle eines Failovers einer primären DB-Instance oder der Hochstufung einer Standby-Instance zur neuen primären Instance die Replikationsslots bestehen bleiben und die ehemaligen Standby-Subscriber davon nicht betroffen sind.
**So erstellen Sie eine logische Dekodierung auf einem Lesereplikat**
1. **Logische Replikation aktivieren** – Um eine logische Dekodierung auf einem Standby zu erstellen, müssen Sie die logische Replikation auf Ihrer Quell-DB-Instance und deren physischem Replikat aktivieren. Weitere Informationen finden Sie unter [Konfiguration von Read Replicas mit PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **So aktivieren Sie die logische Replikation für eine neu erstellte DB-Instance von RDS für PostgreSQL** – Erstellen Sie eine neue benutzerdefinierte DB-Parametergruppe und legen Sie den statischen Parameter `rds.logical_replication` auf `1` fest. Ordnen Sie dann diese DB-Parametergruppe der Quell-DB-Instance und ihrem physischen Lesereplikat zu. Weitere Informationen finden Sie unter [Verknüpfen einer DB-Parametergruppe mit einer DB-Instance in Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **So aktivieren Sie die logische Replikation für eine bestehende DB-Instance von RDS für PostgreSQL** – Ändern Sie die benutzerdefinierte DB-Parametergruppe der Quell-DB-Instance und ihres physischen Lesereplikats, um den statischen Parameter `rds.logical_replication` auf `1` festzulegen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Anmerkung**
Sie müssen die DB-Instances neu starten, um diese Parameteränderungen anzuwenden.
Sie können die folgende Abfrage verwenden, um die Werte für `wal_level` und `rds.logical_replication` auf der Quell-DB-Instance und ihrem physischen Lesereplikat zu überprüfen.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Tabelle in der Quelldatenbank erstellen** – Stellen Sie in Ihrer Quell-DB-Instance eine Verbindung zur Datenbank her. Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird](USER_ConnectToPostgreSQLInstance.md).
Verwenden Sie die folgenden Abfragen, um eine Tabelle in Ihrer Quelldatenbank zu erstellen und Werte einzufügen:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Publikation für die Quelltabelle erstellen** – Verwenden Sie die folgende Abfrage, um eine Publikation für die Tabelle in der Quell-DB-Instance zu erstellen.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Verwenden Sie eine SELECT-Abfrage, um die Details der Publikation zu überprüfen, die sowohl auf der Quell-DB-Instance als auch auf der physischen Lesereplikat-Instance erstellt wurde.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Abonnement aus einer logischen Replikat-Instance erstellen** – Erstellen Sie eine weitere DB-Instance von RDS für PostgreSQL als logische Replikat-Instance. Stellen Sie sicher, dass die VPC richtig eingerichtet ist, damit diese logische Replikat-Instance auf die physische Lesereplikat-Instance zugreifen kann. Weitere Informationen finden Sie unter [Amazon VPC und Amazon RDS](USER_VPC.md). Wenn Ihre Quell-DB-Instance inaktiv ist, können Verbindungsprobleme auftreten, und die primäre DB-Instance sendet die Daten nicht in die Standby-Instance.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Verwenden Sie eine SELECT-Abfrage, um die Details des Abonnements auf der logischen Replikat-Instance zu überprüfen.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Status des logischen Replikationsslots überprüfen** – Sie können den physischen Replikationsslot nur auf Ihrer Quell-DB-Instance sehen.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Auf Ihrer Lesereplikat-Instance können Sie jedoch den logische Replikationsslot und die Änderungen am Wert `confirmed_flush_lsn` sehen, wenn die Anwendung aktiv logische Änderungen verarbeitet.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL
Ab Version 14.1 unterstützt RDS für PostgreSQL kaskadierende Lesereplikate. Mit *kaskadierenden Lesereplikaten* können Sie Lesereplikate skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für PostgreSQL verursachen. Aktualisierungen des WAL-Protokolls werden von der Quell-DB-Instance nicht an jedes Lesereplikat gesendet. Stattdessen sendet jedes Lesereplikat Replica einer kaskadierenden Serie WAL-Log-Updates an das nächste Lesereplikat in der Reihe. Damit wird die Belastung der Quell-DB-Instance reduziert.
Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für PostgreSQL WAL-Daten an das erste Lesereplikat in der Kette. Dieses Lesereplikat sendet dann WAL-Daten an das zweite Replikat in der Kette usw. Das Endergebnis ist, dass alle Lesereplikate in der Kette die Änderungen von der DB-Instance von RDS für PostgreSQL aufweisen, jedoch ohne Overhead ausschließlich auf der Quell-DB-Instance zu verursachen.
Sie können eine Reihe von bis zu drei Lesereplikaten in einer Kette von einer Quell-DB-Instance von RDS für PostgreSQL erstellen. Angenommen, Sie haben eine DB-Instance von RDS for PostgreSQL 14.1, `rpg-db-main`. Sie haben die folgenden Möglichkeiten:
+ Beginnend mit `rpg-db-main` erstellen Sie das erste Lesereplikat in der Kette `read-replica-1`.
+ Als Nächstes erstellen Sie ab `read-replica-1` das nächste Lesereplikat in der Kette `read-replica-2`.
+ Schließlich erstellen Sie ab `read-replica-2` das nächste Lesereplikat in der Kette `read-replica-3`.
Sie können kein weiteres Lesereplikat über dieses dritte kaskadierende Lesereplikat hinaus in der Reihe für `rpg-db-main` erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für PostgreSQL bis zum Ende einer Reihe kaskadierender Lesereplikate kann aus höchstens vier DB-Instances bestehen.
Damit die Kaskadierung von Lesereplikaten funktioniert, aktivieren Sie automatische Backups auf Ihrem RDS für PostgreSQL. Erstellen Sie zuerst das Lesereplikat und aktivieren Sie dann automatische Backups auf der DB-Instance von RDS für PostgreSQL. Der Prozess ist der gleiche wie bei anderen Amazon-RDS-DB-Engines. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
Wie bei jedem Lesereplikat können Sie ein Lesereplikat, das Teil einer Kaskade ist, hochstufen. Wenn Sie ein Lesereplikat aus einer Kette von Lesereplikaten hochstufen, wird dieses Replikat aus der Kette entfernt. Angenommen, Sie möchten einen Teil der Workload von Ihrer `rpg-db-main`-DB-Instance zu einer neuen Instance verschieben, die nur von der Buchhaltung verwendet wird. Ausgehend von der Kette von drei Lesereplikaten aus dem Beispiel entscheiden Sie sich, `read-replica-2` hochzustufen. Die Kette ist wie folgt betroffen:
+ Durch Hochstufen von `read-replica-2` wird es aus der Replikationskette entfernt.
+ Es ist jetzt eine vollständige read/write DB-Instance.
+ Die Replizierung auf `read-replica-3` wird fortgesetzt wie vor der Hochstufung.
+ Ihre `rpg-db-main` setzt die Replizierung auf `read-replica-1` fort.
Weitere Informationen über das Hochstufen von Lesereplikaten finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
**Anmerkung**
RDS für PostgreSQL unterstützt keine Hauptversions-Upgrades für kaskadierende Replikate. Bevor Sie ein Hauptversions-Upgrade durchführen, müssen Sie kaskadierende Replikate entfernen. Sie können sie nach Abschluss des Upgrades auf Ihrer Quell-DB-Instance und den Replikaten der ersten Ebene neu erstellen.
Für kaskadierende Lesereplikate unterstützt RDS für PostgreSQL 15 Lesereplikate für jede Quell-DB-Instance auf der ersten Replikationsebene und 5 Lesereplikate für jede Quell-DB-Instance auf der zweiten und dritten Replikationsebene.
# Erstellen regionsübergreifender kaskadierender Lesereplikate mit RDS für PostgreSQL
RDS für PostgreSQL unterstützt regionsübergreifende kaskadierende Lesereplikate. Sie können ein regionsübergreifendes Replikat aus der Quell-DB-Instance erstellen und dann daraus Replikate derselben Region generieren. Sie können auch ein Replikat derselben Region aus der Quell-DB-Instance erstellen und dann daraus regionsübergreifende Replikate erzeugen.
**Erstellen eines regionsübergreifenden Replikats und anschließendes Erstellen eines Replikats derselben Region**
Sie können eine DB-Instance von RDS für PostgreSQL mit Version 14.1 oder höher verwenden, `rpg-db-main`, um folgende Vorgänge durchzuführen:
1. Beginnen Sie mit `rpg-db-main` (USA-OST-1) und erstellen Sie das erste regionsübergreifende Lesereplikat in der Kette, `read-replica-1` (USA-WEST-2).
1. Verwenden Sie das erste regionsübergreifende `read-replica-1` (USA-WEST-2) und erstellen Sie das zweite Lesereplikat in der Kette, `read-replica-2` (USA-WEST-2).
1. Verwenden Sie `read-replica-2` und erstellen Sie das dritte Lesereplikat in der Kette, `read-replica-3` (USA-WEST-2).
**Erstellen eines Replikats derselben Region und anschließendes Erstellen eines regionsübergreifenden Replikats**
Sie können eine DB-Instance von RDS für PostgreSQL mit Version 14.1 oder höher verwenden, `rpg-db-main`, um folgende Vorgänge durchzuführen:
1. Beginnen Sie mit `rpg-db-main` (USA-OST-1) und erstellen Sie das erste Lesereplikat in der Kette, `read-replica-1` (USA-OST-1).
1. Verwenden Sie `read-replica-1` (USA-OST-1) und erstellen Sie das erste regionsübergreifende Lesereplikat in der Kette, `read-replica-2` (USA-WEST-2).
1. Verwenden Sie `read-replica-2` (USA-WEST-2) und erstellen Sie das dritte Lesereplikat in der Kette, `read-replica-3` (USA-WEST-2).
**Einschränkungen bei der Erstellung regionsübergreifender Lesereplikate**
+ Eine regionsübergreifende kaskadierende Kette von Datenbankreplikaten kann sich über maximal zwei Regionen mit maximal vier Ebenen erstrecken. Die vier Ebenen umfassen die Datenbankquelle und drei Lesereplikate.
**Vorteile der Verwendung von kaskadierenden Lesereplikaten**
+ Verbesserte Leseskalierbarkeit: Durch die Verteilung von Leseabfragen auf mehrere Replikate trägt die kaskadierende Replikation zum Lastenausgleich bei. Dies verbessert die Leistung, insbesondere bei leseintensiven Anwendungen, indem die Belastung der Writer-Datenbank verringert wird.
+ Geografische Verteilung: Kaskadierende Replikate können sich an verschiedenen geografischen Standorten befinden. Dies reduziert die Latenz für Benutzer, die sich weit von der Primärdatenbank entfernt befinden, und bietet ein lokales Lesereplikat, was die Leistung und das Benutzererlebnis verbessert.
+ Hochverfügbarkeit und Notfallwiederherstellung: Im Falle eines Ausfalls des primären Servers können Replikate zu primären Servern hochgestuft werden, wodurch die Kontinuität gewährleistet ist. Durch die kaskadierende Replikation wird dies noch weiter verbessert, indem mehrere Ebenen von Failover-Optionen bereitgestellt werden, wodurch sich die allgemeine Ausfallsicherheit des Systems verbessert.
+ Flexibilität und modulares Wachstum: Wenn das System wächst, können neue Replikate auf verschiedenen Ebenen hinzugefügt werden, ohne dass die Primärdatenbank umfassend neu konfiguriert werden muss. Dieser modulare Ansatz ermöglicht ein skalierbares und verwaltbares Wachstum der Replikationseinrichtung.
**Bewährte Methode für die Verwendung regionsübergreifender Lesereplikate**
+ Bevor Sie ein Replikat hochstufen, erstellen Sie zusätzliche Replikate. Das spart Zeit und ermöglicht eine effiziente Bewältigung der Workload.
# Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen
Wie in [Konfiguration von Read Replicas mit PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md) erläutert, verwendet RDS für PostgreSQL das native Streaming-Replikationsprotokoll von PostgreSQL, um WAL-Daten von der Quell-DB-Instance zu senden. Es sendet Quell-WAL-Daten an Lesereplikate sowohl für regionale als auch regionsübergreifende Lesereplikate. Mit Version 9.4 führte PostgreSQL physische Replikationsslots als unterstützenden Mechanismus für den Replikationsprozess ein.
Ein *physischer Replikationsslot* verhindert, dass eine Quell-DB-Instance WAL-Daten entfernt, bevor sie von allen Lesereplikaten verbraucht werden. Jedes Lesereplikat hat einen eigenen physischen Slot in der Quell-DB-Instance. Der Slot verfolgt das älteste WAL (nach logischer Sequenznummer, LSN), das möglicherweise vom Replikat benötigt wird. Nachdem alle Slots und DB-Verbindungen über eine bestimmte WAL (LSN) hinausgegangen sind, wird diese LSN zum Kandidaten für die Entfernung am nächsten Checkpunkt.
Amazon RDS verwendet Amazon S3, um WAL-Daten zu archivieren. Bei regionalen Lesereplikaten können Sie diese archivierten Daten verwenden, um das Lesereplikat bei Bedarf wiederherzustellen. Dies kann beispielsweise erforderlich werden, wenn die Verbindung zwischen Quell-DB und Lesereplikat aus irgendeinem Grund unterbrochen wird.
In der folgenden Tabelle finden Sie eine Zusammenfassung der Unterschiede zwischen PostgreSQL-Versionen und den unterstützenden Mechanismen für regional und regionsübergreifend, die von RDS für PostgreSQL verwendet werden.
| Version | Regional | Regionsübergreifend |
| --- | --- | --- |
| PostgreSQL 14.1 und höhere Versionen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 und niedrigere Versionen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Weitere Informationen finden Sie unter [Überwachen und Optimieren des Replikationsprozesses](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Grundlegendes zu Parametern, die die PostgreSQL-Replikation steuern
Die folgenden Parameter beeinflussen den Replikationsprozess und bestimmen, wie gut Lesereplikate mit der Quell-DB-Instance auf dem neuesten Stand bleiben:
**max\$1wal\$1senders**
Der Parameter `max_wal_senders` gibt die maximale Anzahl von Verbindungen an, die die Quell-DB-Instance gleichzeitig über das Streaming-Replikationsprotokoll unterstützen kann.
Der Standardwert variiert für Versionen von RDS für PostgreSQL:
+ Für die Versionen 13, 14 und 15 ist der Standardwert 20.
+ Für die Versionen 16 und höher ist der Standardwert 35.
Dieser Parameter sollte etwas höher als die tatsächliche Anzahl der Lesereplikate eingestellt werden. Wenn dieser Parameter für die Anzahl der Lesereplikate zu niedrig eingestellt ist, wird die Replikation beendet.
Weitere Informationen dazu finden Sie im Abschnitt [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) der PostgreSQL-Dokumentation.
`max_wal_senders` ist ein statischer Parameter, der einen Neustart der DB-Instance erfordert, damit die Änderungen wirksam werden.
**wal\$1keep\$1segments**
Der Parameter `wal_keep_segments` gibt die Anzahl der Write-Ahead Log (WAL)-Dateien an, die die Quell-DB-Instance im `pg_wal`-Verzeichnis speichert. Die Standardeinstellung ist 32.
Wenn `wal_keep_segments` nicht auf einen ausreichend großen Wert für Ihre Bereitstellung festgelegt ist, kann ein Lesereplikat so weit zurückbleiben, dass das Streaming der Replikation anhält. In diesem Fall generiert Amazon RDS einen Replikationsfehler und beginnt mit der Wiederherstellung des Lesereplikats. Dies geschieht, indem es die archivierten WAL-Daten der Quell-DB-Instance von Amazon S3 wiedergibt. Dieser Wiederherstellungsprozess wird fortgeführt, bis das Lesereplikat ausreichend nah am aktuellen Stand angekommen ist, um mit dem Streaming der Replikation fortfahren zu können. Sie können diesen Prozess unter [Beispiel: Wiederherstellen eines Lesereplikats nach einer ReplikationsunterbrechungenBeispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen](#USER_PostgreSQL.Replication.example-how-it-works) in Aktion sehen, wie er vom PostgreSQL-Protokoll erfasst wurde.
In PostgreSQL Version 13 wird der Parameter `wal_keep_segments` als `wal_keep_size` bezeichnet. Er dient dem gleichen Zweck wie `wal_keep_segments`, der Standardwert wird jedoch in Megabyte (MB) (2 048 MB) und nicht als Anzahl der Dateien angegeben. Weitere Informationen finden Sie unter [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) und [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) in der PostgreSQL-Dokumentation.
**max\$1slot\$1wal\$1keep\$1size**
Der Parameter `max_slot_wal_keep_size` steuert die Menge an WAL-Daten, die die RDS-for-PostgreSQL-DB-Instance im Verzeichnis `pg_wal` für Slots speichert. Dieser Parameter wird für Konfigurationen verwendet, die Replikationsslots nutzen. Der Standardwert für diesen Parameter ist `-1`, was bedeutet, dass es keine Begrenzung gibt, wie viele WAL-Daten auf der Quell-DB-Instance gespeichert werden. Weitere Informationen zur Überwachung Ihrer Replikationsslots finden Sie unter [Überwachen von Replikationsslots für Ihre RDS-for-PostgreSQL-DB-Instance](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Weitere Informationen zu diesem Parameter finden Sie unter [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) in der PostgreSQL-Dokumentation.
Sobald ein Stream, der WAL-Daten an ein Lesereplikat leitet, unterbrochen wird, wechselt PostgreSQL in den Wiederherstellungsmodus. Es stellt das Lesereplikat mithilfe archivierter WAL-Daten von Amazon S3 oder mithilfe der WAL-Daten, die mit dem Replikationsslot verknüpft sind, wieder her. Sobald dieser Vorgang abgeschlossen ist, nimmt PostgreSQL das Streaming der Replikation wieder auf.
### Beispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen
Im folgenden Beispiel finden Sie die Protokolldetails, die den Wiederherstellungsprozess für ein Lesereplikat veranschaulichen. Das Beispiel stammt von einer RDS for PostgreSQL-DB-Instance, auf der PostgreSQL Version 12.9 in derselben Version AWS-Region wie die Quell-DB ausgeführt wird, sodass keine Replikationsslots verwendet werden. Der Wiederherstellungsprozess ist derselbe wie für andere RDS-for-PostgreSQL-DB-Instances, die eine frühere PostgreSQL-Version als 14.1 mit regionalen Lesereplikaten ausführen.
Wenn das Lesereplikat den Kontakt zur Quell-DB-Instance verloren hat, zeichnet Amazon RDS das Problem im Protokoll als `FATAL: could not receive data from WAL stream`-Nachricht zusammen mit dem `ERROR: requested WAL segment ... has already been removed` auf. Wie in der fett gedruckten Zeile gezeigt, stellt Amazon RDS das Replikat wieder her, indem es eine archivierte WAL-Datei wiedergibt.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Wenn Amazon RDS genügend archivierte WAL-Daten wiedergegeben hat, damit das Replikat aufholt, wird das Streaming an das Lesereplikat fortgesetzt. Wenn das Streaming fortgesetzt wird, schreibt Amazon RDS einen Eintrag ähnlich wie folgenden in die Protokolldatei.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Festlegen der Parameter, die den gemeinsam genutzten Speicher steuern
Die von Ihnen festgelegten Parameter bestimmen die Größe des gemeinsam genutzten Speichers für die Nachverfolgung von Transaktionen IDs, Sperren und vorbereiteten Transaktionen. **Die Struktur des gemeinsam genutzten Speichers einer Standby-Instance muss der einer primären Instance entsprechen oder größer sein.** Dadurch wird sichergestellt, dass der gemeinsam genutzte Speicher der Ersteren während der Wiederherstellung nicht knapp wird. Wenn die Parameterwerte des Replikats niedriger sind als die Parameterwerte der primären Instance, passt Amazon RDS die Replikatparameter automatisch an und startet die Engine neu.
Die betroffenen Parameter sind:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Um RDS-Neustarts von Replikaten aufgrund von unzureichendem Speicher zu vermeiden, empfehlen wir, die Parameteränderungen in Form eines fortlaufenden Neustarts auf jedes Replikat anzuwenden. Sie müssen die folgenden Regeln anwenden, wenn Sie die Parameter festlegen:
+ **Erhöhen der Parameterwerte:**
+ Sie sollten immer zuerst die Parameterwerte aller Lesereplikate erhöhen und einen fortlaufenden Neustart aller Replikate durchführen. Wenden Sie dann die Parameteränderungen auf die primäre Instance an und führen Sie dann einen Neustart aus.
+ **Verringern der Parameterwerte:**
+ Sie sollten zuerst die Parameterwerte der primären Instance verringern und einen Neustart durchführen. Wenden Sie dann die Parameteränderungen auf alle zugehörigen Lesereplikate an und führen Sie einen fortlaufenden Neustart durch.
# Überwachen und Optimieren des Replikationsprozesses
Wir empfehlen dringend, Ihre RDS-for-PostgreSQL-DB-Instance und Lesereplikate routinemäßig zu überwachen. Sie müssen sicherstellen, dass Ihre Lesereplikate mit den Änderungen an der Quell-DB-Instance Schritt halten. Amazon RDS stellt Ihre Lesereplikate transparent wieder her, wenn Unterbrechungen des Replikationsprozesses auftreten. Es ist jedoch am besten, wenn keine Wiederherstellung erforderlich ist. Die Wiederherstellung mit Replikationsslots ist schneller als die Verwendung des Amazon-S3-Archivs, aber jeder Wiederherstellungsprozess kann die Leseleistung beeinträchtigen.
Um festzustellen, wie gut Ihre Lesereplikate mit der Quell-DB-Instance Schritt halten, können Sie folgende Schritte ausführen:
+ **Prüfen Sie den Wert für `ReplicaLag` zwischen Quell-DB-Instance und Replikaten.** *Replikatverzögerung* ist die Zeit in Sekunden, die ein Lesereplikat hinter seiner Quell-DB-Instance zurückbleibt. Diese Metrik gibt das Ergebnis der folgenden Abfrage zurück.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
Die Replikatverzögerung ist ein Hinweis darauf, wie gut ein Lesereplikat mit der Quell-DB-Instance Schritt hält. Dies ist die Latenz zwischen der Quell-DB-Instance und einem bestimmten Lesereplikat. Ein hoher Wert für die Replikatverzögerung kann auf eine Nichtübereinstimmung zwischen den DB-Instance-Klassen oder Speichertypen (oder beiden) hinweisen, die von der Quell-DB-Instance und ihren Lesereplikaten verwendet werden. Die DB-Instance-Klasse und die Speichertypen für die DB-Quellinstance und alle Lesereplikate sollten identisch sein.
Replikatverzögerung kann auch das Ergebnis intermittierender Verbindungsprobleme sein. Sie können die Replikationsverzögerung in Amazon überwachen, CloudWatch indem Sie sich die Amazon `ReplicaLag` RDS-Metrik ansehen. Für weitere Informationen über `ReplicaLag` und andere Metriken für Amazon RDS finden Sie unter [CloudWatch Amazon-Metriken für Amazon RDS](rds-metrics.md).
+ **Im PostgreSQL-Protokoll finden Sie Informationen, mit denen Sie Ihre Einstellungen anpassen können.** Das PostgreSQL-Protokoll erfasst an jedem Checkpoint die Anzahl der recycelten Transaktionsprotokolldateien, wie im folgenden Beispiel gezeigt.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Sie können diese Informationen verwenden, um herauszufinden, wie viele Transaktionsdateien in einem bestimmten Zeitraum recycelt werden. Sie können die Einstellung für `wal_keep_segments` bei Bedarf ändern. Angenommen, das PostgreSQL-Protokoll zeigt bei `checkpoint complete` für ein 5-Minuten-Intervall `35 recycled` an. In diesem Fall reicht der `wal_keep_segments`-Standardwert 32 nicht aus, um mit der Streaming-Aktivität Schritt zu halten, und wir empfehlen Ihnen, den Wert dieses Parameters zu erhöhen.
+ **Verwenden Sie Amazon CloudWatch , um Metriken zu überwachen, mit denen Replikationsprobleme vorhergesagt werden können.** Anstatt das PostgreSQL-Protokoll direkt zu analysieren, können Sie Amazon verwenden, CloudWatch um die gesammelten Metriken zu überprüfen. Sie können beispielsweise den Wert der Metrik `TransactionLogsGeneration` überprüfen, um zu sehen, wie viele WAL-Daten von der Quell-DB-Instance generiert werden. In einigen Fällen kann die Worklaod Ihrer DB-Instance WAL-Daten in großer Menge erzeugen. In diesem Fall müssen Sie möglicherweise die DB-Instance-Klasse für Ihre Quell-DB-Instance und Lesereplikate ändern. Die Verwendung einer Instance-Klasse mit hoher Netzwerkleistung (10 Gbit/s) kann die Verzögerung von Replikaten verringern.
## Überwachen von Replikationsslots für Ihre RDS-for-PostgreSQL-DB-Instance
Alle Versionen von RDS für PostgreSQL verwenden Replikationsslots für regionsübergreifende Lesereplikate. RDS für PostgreSQL 14.1 und höhere Versionen verwenden Replikationsslots für regionale Lesereplikate. Regionale Lesereplikate nutzen Amazon S3 auch dazu, WAL-Daten zu archivieren. Mit anderen Worten, wenn Ihre DB-Instance und Lesereplikate PostgreSQL 14.1 oder höher ausführen, stehen sowohl Replikationsslots als auch Amazon-S3-Archive für die Wiederherstellung des Lesereplikats zur Verfügung. Die Wiederherstellung eines Lesereplikats Replica mit seinem Replikationsslots ist schneller als die Wiederherstellung aus dem Amazon-S3-Archiv. Wir empfehlen daher, die Replikationsslots und zugehörige Metriken zu überwachen.
Sie können die Replikationsslots auf Ihren RDS-for-PostgreSQL-DB-Instances anzeigen, indem Sie die Ansicht `pg_replication_slots` wie folgt abfragen.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
Der `wal_status` `reserved` bedeutet, dass die Menge der vom Slot gespeicherten WAL-Daten innerhalb der Grenzen des Parameters `max_wal_size` liegt. Mit anderen Worten: Der Replikationsslots ist angemessen dimensioniert. Folgende Statuswerte sind außerdem möglich:
+ `extended` – Der Slot überschreitet die Einstellung `max_wal_size`, die WAL-Daten werden jedoch beibehalten.
+ `unreserved` – Der Slot verfügt nicht mehr über alle erforderlichen WAL-Daten. Ein Teil davon wird am nächsten Checkpoint entfernt.
+ `lost` – Einige erforderliche WAL-Daten wurden entfernt. Der Slot ist nicht mehr nutzbar.
Die Status `unreserved` und `lost` von `wal_status` werden nur angezeigt, wenn `max_slot_wal_keep_size` nicht negativ ist.
Die Ansicht `pg_replication_slots` zeigt Ihnen den aktuellen Status Ihrer Replikationsslots an. Um die Leistung Ihrer Replikationsslots zu bewerten, können Sie Amazon verwenden CloudWatch und die folgenden Metriken überwachen:
+ **`OldestReplicationSlotLag`** – Zeigt die Menge an Daten für das Write-Ahead-Protokoll (WAL) auf der Quelle an, die nicht vom Replikat mit der größten Verzögerung verbraucht wurde.
+ **`TransactionLogsDiskUsage`** – Zeigt an, wie viel Speicher für WAL-Daten verwendet wird. Wenn ein Lesereplikat erheblich zurückbleibt, kann der Wert dieser Metrik erheblich steigen.
Weitere Informationen zur Verwendung von Amazon CloudWatch und seinen Metriken für RDS for PostgreSQL finden Sie unter. [Überwachung von Amazon RDS mit Amazon CloudWatch](monitoring-cloudwatch.md) Weitere Informationen zur Überwachung des Streamings der Replikation auf Ihren RDS-for-PostgreSQL-DB-Instances finden Sie unter [Bewährte Methoden für die Amazon-RDS-PostgreSQL-Replikation](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) im *AWS -Datenbank-Blog*.
# Konfigurieren der verzögerten Replikation mit RDS für PostgreSQL
## Übersicht und Vorteile
Mit der verzögerten Replikation in RDS für PostgreSQL können Sie die Replikation von Datenänderungen von der Primärdatenbank auf einen oder mehrere Standby-Server (Lesereplikate) absichtlich verzögern. Dies bietet wertvollen Schutz vor beschädigten Daten, versehentlichem Datenverlust und fehlerhaften Transaktionen, die andernfalls sofort auf alle Replikate übertragen werden könnten.
Die verzögerte Replikation wird für die folgenden Versionen von RDS für PostgreSQL unterstützt:
+ 14.19 und höhere 14-Versionen
+ 15.14 und höhere 15-Versionen
+ 16.10 und höhere 16 Versionen
+ 17.6 und höhere 17-Versionen
Durch die Einführung einer Zeitverzögerung beim Replikationsprozess erhalten Sie die Möglichkeit, datenbezogene Vorfälle zu erkennen und darauf zu reagieren, bevor sie sich auf Ihren gesamten DB-Cluster auswirken. Hauptvorteile der verzögerten Replikation:
+ Ermöglicht die Wiederherstellung nach versehentlichen Löschvorgängen, Aktualisierungen oder anderen logischen Fehlern.
+ Bietet einen Puffer gegen die Ausbreitung beschädigter Daten im DB-Cluster.
+ Bietet einen möglichen zusätzlichen Wiederherstellungspunkt als Ergänzung zu herkömmlichen Backup-Strategien.
+ Ermöglicht es Ihnen, den Verzögerungszeitraum anhand der spezifischen Anforderungen und der Risikotoleranz Ihres Unternehmens zu konfigurieren.
## Aktivieren und Konfigurieren der verzögerten Replikation
Führen Sie diese Schritte aus, um die verzögerte Replikation auf einem Lesereplikat von RDS für PostgreSQL zu aktivieren:
**Anmerkung**
Verwenden Sie für kaskadierte Lesereplikate denselben Parameter `recovery_min_apply_delay` und führen Sie die unten beschriebenen Schritte aus.
**So aktivieren Sie die verzögerte Replikation**
1. Erstellen Sie eine neue benutzerdefinierte Parametergruppe oder ändern Sie eine vorhandene Parametergruppe. Weitere Informationen finden Sie unter [DB-Parametergruppen für DB-Instances von Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. Konfigurieren Sie den Parameter `recovery_min_apply_delay` in der Parametergruppe:
+ Legen Sie den Wert auf die gewünschte Verzögerung in Millisekunden fest. Zum Beispiel 3 600 000 für eine Verzögerung von 1 Stunde.
+ Zulässiger Bereich: 0 bis 86 400 000 ms (0 bis 24 Stunden)
+ Standard: 0
1. Wenden Sie die Parametergruppe auf die Lesereplikat-Instance an, die Sie für die verzögerte Replikation konfigurieren möchten.
1. Starten Sie die Lesereplikat-Instance neu, damit die Änderungen wirksam werden.
**Anmerkung**
Der `recovery_min_apply_delay`-Parameter ist dynamisch. Wenn Sie eine vorhandene Parametergruppe ändern, die bereits mit der Instance verknüpft ist, werden die Änderungen sofort wirksam, ohne dass ein Neustart erforderlich ist. Wenn Sie jedoch eine neue Parametergruppe auf die Instance anwenden, müssen Sie einen Neustart vornehmen, damit die Änderungen wirksam werden.
## Verwalten der Wiederherstellung von verzögerten Replikationen
Eine verzögerte Replikation ist besonders nützlich in Szenarien, in denen herkömmliche point-in-time Wiederherstellungsmethoden möglicherweise unzureichend oder zu zeitaufwändig sind.
Während des Zeitraums der verzögerten Replikation können Sie die folgenden PostgreSQL-Funktionen zum Verwalten des Wiederherstellungsprozesses verwenden:
+ `pg_wal_replay_pause()`: Fordert die Unterbrechung des Wiederherstellungsprozesses für das verzögerte Replikat an.
+ `pg_wal_replay_resume()`: Startet den Wiederherstellungsprozess neu, sofern er zuvor unterbrochen wurde.
+ `pg_is_wal_replay_paused()`: Überprüft, ob der Wiederherstellungsprozess derzeit unterbrochen ist.
+ `pg_get_wal_replay_pause_state()`: Ruft den aktuellen Status des Wiederherstellungsprozesses ab (nicht unterbrochen, Unterbrechung angefordert oder unterbrochen).
Benutzer mit der Rolle `rds_superuser` haben EXECUTE-Berechtigungen für `pg_wal_replay_pause()` und `pg_wal_replay_resume()`. Wenn andere Datenbankbenutzer Zugriff auf diese Funktionen benötigen, müssen Sie ihnen die Rolle `rds_superuser` gewähren. Weitere Informationen zur `rds_superuser`-Rolle finden Sie unter [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
Für den Zugriff auf andere Funktionen wie `pg_is_wal_replay_paused()` und `pg_get_wal_replay_pause_state()` ist die Rolle `rds_superuser` nicht erforderlich.
Sie können die folgenden Wiederherstellungszielparameter verwenden, um den Zeitpunkt, bis zu dem das verzögerte Replikat wiederhergestellt wird, genau zu steuern. Diese Parameter sind statisch und erfordern einen Neustart der Datenbank, damit die Änderungen wirksam werden:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Wichtig**
Sie können jeweils nur einen Wiederherstellungszielparameter angeben. Die Konfiguration mehrerer Wiederherstellungszielparameter in der Konfigurationsdatei führt zu einem Fehler.
## Überlegungen zur Planung
Berücksichtigen Sie bei der Planung der verzögerten Replikation mit RDS für PostgreSQL folgende Aspekte:
+ Während der automatischen Rotation der `rdsrepladmin`-Anmeldeinformationen (die alle 90 Tage erfolgt) können verzögerte Lesereplikate vorübergehend in den Status `REPLICATION_ERROR` wechseln. Wenn das verzögerte Replikat über genügend WAL-Protokolle verfügt, um die konfigurierte Verzögerung beizubehalten, kann der WAL-Empfängerprozess unterbrochen werden, was zu einer WAL-Akkumulation auf der Quelle führt. Sie sollten den Replikationsstatus auf dem Replikat und die Speichernutzung auf der Quelle überwachen, um zu verhindern, dass der Speicherplatz voll wird.
+ Wenn bei verzögerten Lesereplikaten Systemereignisse (wie Hochfahren oder Neustart) auftreten, wechseln sie in den Status `REPLICATION_ERROR`, in dem der WAL-Empfängerprozess inaktiv bleibt, bis der konfigurierte Verzögerungszeitraum abläuft. Dieses Verhalten kann zu einer WAL-Akkumulation auf der Quell-Instance führen, was möglicherweise einen vollen Speicher verursachen kann. Berücksichtigen Sie die folgenden vorbeugenden Maßnahmen:
+ Konfigurieren Sie CloudWatch Alarme, um die Speicherauslastung auf den Quell-Instances zu überwachen.
+ Aktivieren Sie die automatische Speicherskalierung, um eine unerwartete WAL-Expansion zu verarbeiten.
+ Legen Sie den Parameter `max_slot_wal_keep_size` auf der Quell-Instance fest, um die WAL-Beibehaltung pro Replikations-Slot zu begrenzen.
+ Überwachen Sie die Replikationsverzögerung und den Status des Replikations-Slots regelmäßig.
+ Längere Verzögerungen erhöhen die Anzahl der WAL-Protokolle auf den Replikaten und belegen dadurch mehr Speicherplatz. Überwachen Sie den Speicherplatz mithilfe von CloudWatch Alarmen, aktivieren Sie die auto-scaling oder catch Sie bei Bedarf Replikate nach.
+ Bei der Heraufstufung eines verzögerten Lesereplikats wird der Parameter `recovery_min_apply_delay` nicht berücksichtigt und alle ausstehenden WAL-Datensätze werden sofort angewendet.
+ Der Parameter `recovery_min_apply_delay` ist unabhängig von den einzelnen Ebenen einer kaskadierenden Replikationseinrichtung. Durch das Festlegen einer Verzögerung für ein Replikat nimmt die Verzögerung kaskadierter Replikate nicht zu.
Weitere Informationen finden Sie in der [Dokumentation zu Lesereplikaten von RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) und in der [Dokumentation zur Notfallwiederherstellung von RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Grundlagen zu Einschränkungen
Die verzögerte Replikation für Amazon RDS für PostgreSQL hat die folgenden Einschränkungen:
+ Für Blau/Grün-Bereitstellungen gelten bei der Konfiguration der verzögerten Replikation die folgenden Einschränkungen:
+ **Grüne Quell-Instance** – Der Parameter `recovery_min_apply_delay parameter` wird ignoriert, auch wenn er in der Parametergruppe konfiguriert ist. Alle Verzögerungseinstellungen auf der grünen Quell-Instance werden nicht wirksam.
+ **Grüne Replikat-Instance** – Der Parameter `recovery_min_apply_delay parameter` wird vollständig unterstützt und auf die PostgreSQL-Konfigurationsdatei angewendet. Die Verzögerungseinstellungen funktionieren während des Umstellungs-Workflows erwartungsgemäß.
+ Blue/Green RDS-Bereitstellungen für wichtige Versions-Upgrades
+ Bei Hauptversions-Upgrades werden alle verzögerten Lesereplikate automatisch beendet, damit die Quell-Instance mit dem Upgrade fortfahren kann, um für minimale Ausfallzeiten zu sorgen. Nachdem die Quell-Instance das Upgrade abgeschlossen hat, müssen Sie die verzögerten Replikate manuell neu erstellen.
+ Die verzögerte Replikation ist mit den folgenden Features nicht kompatibel.
+ Logische Replikation von RDS für PostgreSQL
+ Multi-AZ-Cluster von RDS für PostgreSQL (einschließlich der eingehenden und ausgehenden Replikation)
+ Aurora PostgreSQL
# Problembehebung für Lesereplikate von RDS für PostgreSQL
Im Folgenden finden Sie Tipps zur Problembehebung für einige häufige Probleme mit Lesereplikaten von RDS für PostgreSQL.
**Beenden der Abfrage, die die Lesereplikatsverzögerung verursacht hat**
Transaktionen, die im Transaktionsstatus entweder aktiv oder im Leerlauf sind und über einen längeren Zeitraum in der Datenbank ausgeführt werden, können den WAL-Replikationsprozess stören und dadurch die Replikationsverzögerung erhöhen. Achten Sie daher darauf, die Laufzeit dieser Transaktionen mit der PostgreSQL-Ansicht `pg_stat_activity` zu überwachen.
Führen Sie eine Abfrage auf der primären Instance ähnlich der folgenden aus, um die Prozess-ID (PID) der Abfrage zu ermitteln, die über einen längeren Zeitraum ausgeführt wird:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Nachdem Sie die PID der Abfrage identifiziert haben, können Sie wählen, ob Sie die Abfrage beenden möchten.
Führen Sie eine Abfrage auf der primären Instance ähnlich der folgenden aus, um die Abfrage zu beenden, die über einen längeren Zeitraum ausgeführt wird:
```
SELECT pg_terminate_backend(PID);
```
# Verbesserung der Abfrageleistung für RDS für PostgreSQL mit Amazon-RDS-optimierten Lesevorgängen
Mit Amazon-RDS-optimierten Lesevorgängen können Sie eine schnellere Abfrageverarbeitung für RDS für PostgreSQL erreichen. Eine DB-Instance von RDS für PostgreSQL oder ein Multi-AZ-DB-Cluster, die bzw. der RDS-optimierte Lesevorgänge verwendet, kann eine doppelt so schnelle Abfrageverarbeitung erreichen als eine DB-Instance bzw. ein DB-Cluster, die bzw. der diese Funktion nicht verwendet.
**Topics**
+ [Übersicht über RDS-optimierte Lesevorgänge in PostgreSQL](#USER_PostgreSQL.optimizedreads-overview)
+ [Anwendungsfälle für RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-use-cases)
+ [Bewährte Methoden für RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-best-practices)
+ [Verwenden von RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-using)
+ [Überwachen von DB-Instances, die RDS Optimized Reads verwenden](#USER_PostgreSQL.optimizedreads-monitoring)
+ [Einschränkungen für RDS-optimierte Lesevorgänge in PostgreSQL](#USER_PostgreSQL.optimizedreads-limitations)
## Übersicht über RDS-optimierte Lesevorgänge in PostgreSQL
Optimierte Lesevorgänge sind standardmäßig in den Versionen 15.2 und höher, 14.7 und höher sowie 13.10 und höher von RDS für PostgreSQL verfügbar, wenn Sie NVMe-basierte DB-Instance-Klassen verwenden. Hardwarespezifikationen, die angeben, welche Instances NVMe verwenden, finden Sie unter [Hardwarespezifikationen für DB-Instance-Klassen ](Concepts.DBInstanceClass.Summary.md).
Wenn Sie eine DB-Instance von RDS für PostgreSQL oder einen Multi-AZ-DB-Cluster verwenden, für die bzw. den RDS-optimierte Lesevorgänge aktiviert sind, erreicht Ihre DB-Instance bzw. Ihr DB-Cluster mit dem lokalen nicht-flüchtigen Memory Express (NVMe)-Blockspeicher, der auf Solid-State-Laufwerken (SSD) basiert, eine bis zu doppelt so schnelle Abfrageleistung. Sie können eine schnellere Abfrageverarbeitung erreichen, indem Sie die von PostgreSQL generierten temporären Tabellen im lokalen Speicher ablegen, wodurch der Datenverkehr zu Elastic Block Storage (EBS) über das Netzwerk reduziert wird.
In PostgreSQL werden temporäre Objekte einem temporären Namespace zugewiesen, der am Ende der Sitzung automatisch gelöscht wird. Der temporäre Namespace entfernt beim Löschen alle Objekte, die von der Sitzung abhängig sind, einschließlich schemaqualifizierter Objekte wie Tabellen, Funktionen, Operatoren oder sogar Erweiterungen.
In RDS für PostgreSQL ist der Parameter `temp_tablespaces` für diesen temporären Arbeitsbereich konfiguriert, in dem die temporären Objekte gespeichert sind.
Die folgenden Abfragen geben den Namen des Tablespace und seinen Speicherort zurück.
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
`rds_temp_tablespace` ist ein von RDS konfigurierter Tabellenbereich, der auf den lokalen NVMe-Speicher verweist. Sie können jederzeit zurück zum Amazon-EBS-Speicher wechseln, indem Sie diesen Parameter in der `Parameter group` ändern und AWS-Managementkonsole verwenden, um auf einen anderen Tablespace als `rds_temp_tablespace` zu verweisen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Sie können den SET-Befehl auch verwenden, um den Wert des Parameters `temp_tablespaces` mit dem SET-Befehl auf Sitzungsebene in `pg_default` zu ändern. Durch Ändern des Parameters wird der temporäre Arbeitsbereich wieder an Amazon EBS umgeleitet. Der Wechsel zurück zu Amazon EBS hilft, wenn der lokale Speicher für Ihre RDS-Instance oder Ihren Cluster nicht ausreicht, um eine bestimmte SQL-Operation auszuführen.
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## Anwendungsfälle für RDS Optimized Reads
Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge von Vorteil sein können:
+ Analytische Abfragen mit Common Table Expressions (CTEs), abgeleiteten Tabellen und Gruppierungsoperationen.
+ Lesereplikate, die die nicht optimierten Abfragen für eine Anwendung verarbeiten.
+ Bedarfsgesteuerte oder dynamische Berichtsabfragen mit komplexen Operationen wie GROUP BY und ORDER BY, für die nicht immer die entsprechenden Indizes verwendet werden können.
+ Andere Workloads, die interne temporäre Tabellen verwenden.
+ `CREATE INDEX`- oder `REINDEX`-Operationen zum Sortieren.
## Bewährte Methoden für RDS Optimized Reads
Nutzen Sie die folgenden bewährten Methoden für RDS Optimized Reads:
+ Fügen Sie Wiederholungslogik für schreibgeschützte Abfragen hinzu, falls diese aufgrund eines Fehlers wegen eines vollen Instance-Speichers während der Ausführung fehlschlagen.
+ Überwachen Sie den verfügbaren Speicherplatz im Instance-Speicher mit der CloudWatch-Metrik `FreeLocalStorage`. Wenn der Instance-Speicher aufgrund der Workload der DB-Instance oder des Multi-AZ-DB-Clusters sein Limit erreicht, ändern Sie die DB-Instance bzw. den DB-Cluster und verwenden Sie eine größere DB-Instance-Klasse.
## Verwenden von RDS Optimized Reads
Wenn Sie eine DB-Instance von RDS für PostgreSQL mit einer der NVMe-basierten DB-Instance-Klassen in einer Single-AZ-Bereitstellung, einer Multi-AZ-Bereitstellung oder einer Multi-AZ-DB-Cluster-Bereitstellung bereitstellen, verwendet die DB-Instance automatisch RDS-optimierte Lesevorgänge.
Weitere Informationen zur Multi-AZ-Bereitstellung finden Sie unter [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md).
Führen Sie einen der folgenden Schritte aus, um RDS Optimized Reads zu aktivieren:
+ Erstellen Sie eine DB-Instance oder einen Multi-AZ-DB-Cluster von RDS für PostgreSQL mit einer der NVMe-basierten DB-Instance-Klassen. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
+ Ändern Sie eine vorhandene DB-Instance oder einen Multi-AZ-DB-Cluster von RDS für PostgreSQL so, dass eine der NVMe-basierten DB-Instance-Klassen verwendet wird. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
RDS-optimierte Lesevorgänge sind in allen AWS-Regionen verfügbar, in denen eine oder mehrere der DB-Instance-Klassen mit lokalem NVMe-SSD-Speicher unterstützt werden. Weitere Informationen finden Sie unter [](Concepts.DBInstanceClass.md).
Um zu einer Instance mit nicht RDS-optimierten Lesevorgängen zurückzukehren, ändern Sie die DB-Instance-Klasse Ihrer RDS-Instance oder Ihres Clusters auf eine ähnliche Instance-Klasse, die nur EBS-Speicher für Ihre Datenbank-Workloads unterstützt. Wenn die aktuelle DB-Instance-Klasse beispielsweise db.r6gd.4xlarge ist, wählen Sie db.r6g.4xlarge aus, um zurückzuwechseln. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
## Überwachen von DB-Instances, die RDS Optimized Reads verwenden
Sie können DB-Instances, die RDS-optimierte Lesevorgänge verwenden, mit den folgenden CloudWatch-Metriken überwachen:
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Diese Metriken liefern Daten über den verfügbaren Instance-Speicher, die IOPS und den Durchsatz. Weitere Informationen zu diesen Metriken finden Sie unter [Metriken CloudWatch auf Amazon-Instanzebene für Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Wenn Sie die aktuelle Nutzung Ihres lokalen Speichers überwachen möchten, melden Sie sich bei Ihrer Datenbank an und führen Sie folgende Abfrage aus:
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
Weitere Informationen zu den temporären Dateien und ihrer Verwendung finden Sie unter [Verwalten temporärer Dateien mit PostgreSQL](PostgreSQL.ManagingTempFiles.md).
## Einschränkungen für RDS-optimierte Lesevorgänge in PostgreSQL
Für RDS-optimierte Lesevorgänge gilt die folgende Einschränkung in PostgreSQL:
+ Transaktionen können fehlschlagen, wenn der Instance-Speicher voll ist.
# Importieren von Daten in PostgreSQL in Amazon RDS
Angenommen, Sie verfügen über eine bestehende PostgreSQL-Bereitstellung, die Sie zu Amazon RDS verschieben möchten. Wie komplex diese Aufgabe ist, hängt von der Größe Ihrer Datenbank und den Arten von Datenbankobjekten ab, die Sie übertragen. Nehmen wir beispielsweise eine Datenbank mit mehreren Gigabyte an Datensätzen, einschließlich der gespeicherten Prozeduren und Auslöser. Eine solche Datenbank ist komplizierter als eine einfache Datenbank mit nur wenigen Megabyte an Testdaten und ohne Auslöser oder gespeicherten Prozeduren.
Unter den folgenden Bedingungen empfehlen wir Ihnen die Verwendung von nativen PostgreSQL-Datenbank-Migrationstools:
+ Sie möchten eine homogene Migration durchführen, bei der die Ausgangsdatenbank denselben Datenbank-Engine hat wie die Zieldatenbank.
+ Sie möchten eine komplette Datenbank migrieren.
+ Die nativen Tools erlauben Ihnen, Ihr System mit einer minimalen Ausfallzeit zu migrieren.
In den meisten anderen Fällen ist die Durchführung einer Datenbankmigration mit dem AWS Database Migration Service (AWS DMS) der beste Ansatz. AWS DMS kann Datenbanken ohne Ausfallzeiten migrieren und bei vielen Datenbank-Engines die fortlaufende Replikation fortsetzen, bis Sie bereit sind, zur Zieldatenbank zu wechseln. Mithilfe von AWS DMS können Sie entweder zu derselben Datenbank-Engine oder zu einer anderen Datenbank-Engine migrieren. Wenn Sie zu einer anderen Datenbank-Engine als Ihrer Quelldatenbank migrieren, können Sie die AWS Schema Conversion Tool ()AWS SCT verwenden. Sie verwenden AWS SCT es, um Schemaobjekte zu migrieren, die nicht von migriert wurden. AWS DMS Weitere Informationen zu AWS DMS finden Sie unter [Was ist? AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
Modifizieren Sie die DB-Parametergruppe so, dass sie *nur* die folgenden Einstellungen für Ihren Import enthält. Sie sollten die Parametereinstellungen testen, um festzustellen, welches die effizientesten Einstellungen für Ihre DB-Instance-Größe sind. Nach der Import abgeschlossen wurde, müssen Sie auch diese Parameter auf die Produktionswerte zurücksetzen.
Ändern Sie die Einstellungen für Ihre DB-Instance wie folgt:
+ Deaktivieren Sie die DB-Instance-Backups (Sicherungsaufbewahrung auf 0 setzen).
+ Deaktivieren Sie Multi-AZ.
Modifizieren Sie die DB-Parametergruppe so, dass sie die folgenden Einstellungen enthält. Sie sollten beim Importieren von Daten nur diese Einstellungen verwenden. Sie sollten die Parametereinstellungen testen, um festzustellen, welches die effizientesten Einstellungen für Ihre DB-Instance-Größe sind. Nach der Import abgeschlossen wurde, müssen Sie auch diese Parameter auf die Produktionswerte zurücksetzen.
| Parameter | Empfohlene Werte beim Importieren | Beschreibung |
| --- | --- | --- |
| `maintenance_work_mem` | 524288, 1048576, 2097152 oder 4194304 (in KB). Diese Einstellungen sind vergleichbar mit 512 MB, 1 GB, 2 GB und 4 GB. | Der Wert für diese Einstellung hängt von der Größe Ihres Hosts ab. Dieser Parameter wird während der CREATE INDEX-Anweisungen verwendet und jeder parallele Befehl kann so viel Speicherplatz benötigen. Berechnen Sie den besten Wert, sodass Sie diesen Wert nicht zu hoch einstellen und Gefahr laufen, keinen Speicherplatz mehr zu haben. |
| `max_wal_size` | 256 (für Version 9.6), 4096 (für Version 10 und höher) | Maximale Größe, um das WAL während automatischer Kontrollpunkte zunehmen zu lassen. Eine Erhöhung dieses Parameters kann den Zeitaufwand für die Wiederherstellung nach dem Absturz erhöhen. Dieser Parameter ersetzt `checkpoint_segments` für PostgreSQL 9.6 und höher. Für PostgreSQL-Version 9.6 liegt dieser Wert auf 16 MB-Einheiten. Bei späteren Versionen liegt der Wert bei 1 MB Einheiten. In Version 9.6 bedeutet das beispielsweise 128 Blöcke mit einer Größe von jeweils 16 MB. In Version 12.4 bedeutet das 2 048 Blöcke mit einer Größe von jeweils 1 MB. |
| `checkpoint_timeout` | 1800 | Der Wert für diese Einstellung erlaubt eine seltenere WAL-Rotation. |
| `synchronous_commit` | Aus | Deaktivieren Sie diese Einstellungen, um Schreibvorgänge zu beschleunigen. Wenn dieser Parameter auf „off“ gestellt wird, kann dadurch das Risiko von Datenverlusten bei einem Serverausfall steigen (stellen Sie FSYNC nicht auf „off“). |
| `wal_buffers` | 8192 | Dieser Wert wird in 8 KB-Einheiten angegeben. Dies wiederum erhöht Ihre WAL-Erzeugungsgeschwindigkeit |
| `autovacuum` | 0 | Deaktivieren Sie den Selbstbereinigungsparameter für PostgreSQL während dem Laden von Daten, sodass dieser keine Ressourcen verbraucht |
Verwenden Sie den Befehl `pg_dump -Fc` (komprimiert) oder den Befehl `pg_restore -j` (parallel) mit diesen Einstellungen.
**Anmerkung**
Der PostgreSQL-Befehl `pg_dumpall` erfordert super\$1user-Berechtigungen, die nicht gewährt werden, wenn Sie eine DB-Instance erstellen, sodass er nicht für das Importieren von Daten verwendet werden kann.
**Topics**
+ [Importieren einer PostgreSQL-Datenbank aus einer Amazon EC2-Instance](PostgreSQL.Procedural.Importing.EC2.md)
+ [Verwenden des Befehls \$1copy zum Importieren von Daten in eine Tabelle auf einer PostgreSQL-DB-Instance](PostgreSQL.Procedural.Importing.Copy.md)
+ [Importieren von Amazon S3 in eine DB-Instance von RDS für PostgreSQL](USER_PostgreSQL.S3Import.md)
+ [Transport von PostgreSQL-Datenbanken zwischen DB-Instances](PostgreSQL.TransportableDB.md)
# Importieren einer PostgreSQL-Datenbank aus einer Amazon EC2-Instance
Wenn Sie in einem PostgreSQL-Server auf einer Amazon-EC2-Instance Daten haben und diese in eine PostgreSQL-DB-Instance verschieben möchten, können Sie diesen Prozess zum Migrieren der Daten nutzen.
1. Erstellen Sie eine Datei mit pg\$1dump, die zu ladenden Daten enthält
1. Erstellen Sie die DB-Ziel-Instance
1. Verwenden Sie *psql*, um die Datenbank auf der DB-Instance zu erstellen und die Daten zu laden
1. Erstellen Sie einen DB-Snapshot der DB-Instance
Die folgenden Abschnitte enthalten weitere Informationen zu den oben aufgeführten Schritten.
## Schritt 1: Erstellen einer Datei, die zu ladenden Daten enthält, mit pg\$1dump
Das Dienstprogramm `pg_dump` verwendet den Befehl COPY, um ein Schema sowie eine Daten-Dumpdatei einer PostgreSQL-Datenbank zu erstellen. Das durch `pg_dump` erzeugte Dump-Skript lädt Daten in eine Datenbank mit demselben Namen und erstellt die Tabellen, Indizes und Fremdschlüssel. Sie können den Befehl `pg_restore` und den Parameter `-d` verwenden, um die Daten in einer Datenbank mit einem anderen Namen wiederherzustellen.
Bevor Sie die Daten-Dumpdatei erstellen, sollten Sie die zu dumpenden Tabellen abfragen, um die Zeilenanzahl zu ermitteln und diese in der DB-Ziel-Instance zu bestätigen.
Der folgende Befehl erstellt eine Dump-Datei mit dem Namen mydb2dump.sql für eine Datenbank mit dem Namen mydb2.
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## Schritt 2: Erstellen einer DB-Ziel-Instance
Erstellen Sie die DB-Ziel-Instance für PostgreSQL entweder über die Amazon-RDS-Konsole, AWS CLI oder über die API. Achten Sie darauf, dass beim Erstellen der Instance die Einstellung der Sicherungsaufbewahrung auf 0 festgelegt ist und deaktivieren Sie Multi-AZ. Dadurch wird der Datenimport beschleunigt. Bevor Sie die Daten dumpen können, müssen Sie eine Datenbank auf der Instance erstellen. Die Datenbank kann den gleichen Namen wie die in den Dumpdaten enthaltene Datenbank haben. Alternativ können Sie auch eine Datenbank mit einem anderen Namen erstellen. In diesem Fall verwenden Sie den Befehl `pg_restore` und den Parameter `-d`, um die Daten in einer Datenbank mit einem neuen Namen wiederherzustellen.
Beispielsweise können die folgenden Befehle für das Dumpen, Wiederherstellen und Umbenennen einer Datenbank verwendet werden.
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## Schritt 3: Verwenden von psql zum Erstellen der Datenbank auf der DB-Instance und zum Laden der Daten
Sie können dieselbe Verbindung nutzen, die Sie für die Ausführung des Befehls pg\$1dump verwendet haben, um eine Verbindung mit der DB-Ziel-Instance herzustellen und die Datenbank neu zu erstellen. Mit *psql* können Sie den Masterbenutzername und das Masterpasswort verwenden, um die Datenbank auf der DB-Instance zu erstellen
Im folgenden Beispiel wird *psql* sowie auch eine Dump-Datei mit dem Namen mydb2dump.sql verwendet, um eine Datenbank mit dem Namen mydb2 auf einer PostgreSQL-DB-Instance mit dem Namen mypginstance zu erstellen:
Für Linux, macOS oder Unix:
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Für Windows:
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
## Schritt 4: Erstellen Sie einen DB-Snapshot der DB-Instance
Sobald Sie verifiziert haben, dass die Daten in die DB-Instance geladen wurden, empfehlen wir Ihnen einen DB-Snapshot der PostgreSQL-DB-Ziel-Instance zu erstellen. -DB-Snapshots sind vollständige Backups von Ihrer DB-Instance, die für eine Backup Ihrer DB-Instance auf einen bekannten Zustand verwendet werden können. Ein DB-Snapshot, der sofort nach einem Ladevorgang erstellt wird, bewahrt Sie davor, die Daten bei einem Fehler erneut laden zu müssen. Einen solchen Snapshot können Sie auch als Ausgangspunkt für neue DB-Instances verwenden. Weitere Informationen zum Erstellen eines DB-Snapshots finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md).
# Verwenden des Befehls \$1copy zum Importieren von Daten in eine Tabelle auf einer PostgreSQL-DB-Instance
Der PostgreSQL-Befehl `\copy` ist ein Meta-Befehl, der im interaktiven `psql`-Client-Tool verfügbar ist. Sie können `\copy` verwenden, um Daten in eine Tabelle auf Ihrer DB-Instance von RDS für PostgreSQL zu importieren. Um den `\copy`-Befehl zu verwenden, müssen Sie zuerst die Tabellenstruktur auf der Ziel-DB-Instance erstellen, damit `\copy` ein Ziel für die zu kopierenden Daten hat.
Sie können `\copy` verwenden, um Daten aus einer CSV-Datei (durch Kommas getrennte Werte) zu laden, z. B. aus einer Datei, die exportiert und auf Ihrer Client-Workstation gespeichert wurde.
Um die CSV-Daten in die Ziel-DB-Instance von RDS für PostgreSQL zu importieren, stellen Sie zuerst über eine Verbindung mit der Ziel-DB-Instance her `psql`.
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
Führen Sie dann den `\copy`-Befehl mit den folgenden Parametern aus, um das Ziel für die Daten und ihr Format zu identifizieren.
+ `target_table` – Der Name der Tabelle, die die Daten erhalten soll, die aus der CSV-Datei kopiert werden.
+ `column_list` – Spaltenspezifikationen für die Tabelle.
+ `'filename'` – Der vollständige Pfad zur CSV-Datei auf Ihrer lokalen Workstation.
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
Wenn die CSV-Datei Spaltenüberschriften-Informationen enthält, können Sie diese Version des Befehls und der Parameter verwenden.
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
Wenn der `\copy`-Befehl fehlschlägt, gibt PostgreSQL Fehlermeldungen aus.
Erstellen Sie eine neue DB-Instance in der Datenbank-Vorschauumgebung mit dem Befehl `psql` und dem Metabefehl `\copy`, wie in den folgenden Beispielen gezeigt. In diesem Beispiel wird *source-table* als Name für die Quelltabelle verwendet, *source-table.csv* für die CSV-Datei und *target-db* für die Zieldatenbank:
Für Linux, macOS oder Unix:
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Für Windows:
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Alle Details zum `\copy`-Befehl finden Sie auf der [psql](http://www.postgresql.org/docs/current/static/app-psql.html)-Seite in der PostgreSQL-Dokumentation, im Bereich *Metabefehle*.
# Importieren von Amazon S3 in eine DB-Instance von RDS für PostgreSQL
Sie können Daten, die mit Amazon Simple Storage Service gespeichert wurden, in eine Tabelle auf einer RDS für PostgreSQL DB-Instance importieren. Um dies zu tun, installieren Sie zuerst die `aws_s3`-Erweiterung von RDS für PostgreSQL. Diese Erweiterung stellt die Funktionen bereit, die Sie zum Importieren von einem Amazon S3 Bucket verwenden. Ein *Bucket* ist ein Amazon S3 Container für Objekte und Dateien. Die Daten können sich in einer Datei mit kommagetrennten Werten (CSV), einer Textdatei oder einer komprimierten Datei (GZIP) befinden. Im Folgenden erfahren Sie, wie Sie die Erweiterung installieren und Daten aus Amazon S3 in eine Tabelle importieren.
Um von Simple Storage Service (Amazon S3) in RDS for PostgreSQL zu importieren, muss Ihre Datenbank PostgreSQL Version 10.7 oder höher verwenden.
Wenn Sie keine Daten in Amazon S3 gespeichert haben, müssen Sie zunächst einen Bucket erstellen und die Daten speichern. Weitere Informationen finden Sie in den folgenden Themen im *Benutzerhandbuch zum Amazon Simple Storage Service*.
+ [Erstellen Sie einen Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Hinzufügen eines Objekts zu einem Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
Das kontoübergreifende Importieren aus Amazon S3 wird unterstützt. Weitere Informationen finden Sie unter [Gewähren kontoübergreifender Berechtigungen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
Sie können den vom Kunden verwalteten Schlüssel für die Verschlüsselung verwenden, wenn Sie Daten aus S3 importieren. Weitere Informationen finden Sie unter [In AWS KMS gespeicherte KMS-Schlüssel](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
**Topics**
+ [Installieren der Erweiterung aws\$1s3](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [Übersicht über den Import von Daten aus Amazon S3-Daten](USER_PostgreSQL.S3Import.Overview.md)
+ [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [Daten von Amazon S3 in Ihren ) importieren](USER_PostgreSQL.S3Import.FileFormats.md)
+ [Funktionsreferenz](USER_PostgreSQL.S3Import.Reference.md)
# Installieren der Erweiterung aws\$1s3
Bevor Sie Amazon S3 mit Ihrer DB-Instance von RDS für PostgreSQL verwenden können müssen Sie die `aws_s3`-Erweiterung installieren. Diese Erweiterung bietet Funktionen zum Importieren von Daten aus einem Amazon S3. Sie bietet auch Funktionen zum Exportieren von Daten aus einer DB-Instance von RDS für PostgreSQL zu einem Amazon-S3-Bucket. Weitere Informationen finden Sie unter [Exportieren von Daten aus einem/einer RDS für PostgreSQL-DB-Instance zu Amazon S3](postgresql-s3-export.md). Die Erweiterung `aws_s3` hängt von einigen Hilfsfunktionen in der Erweiterung `aws_commons` ab, die bei Bedarf automatisch installiert wird.
**So installieren Sie die Erweiterung `aws_s3`**
1. Verwenden Sie psql (oder pgAdmin), um eine Verbindung mit der DB-Instance von RDS für PostgreSQL als Benutzer mit `rds_superuser`-Berechtigungen herzustellen. Wenn Sie beim Einrichten den Standardnamen beibehalten haben, stellen Sie eine Verbindung als `postgres` her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Führen Sie den folgenden Befehl aus, um die Erweiterung zu installieren.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Wenn Sie überprüfen möchten, ob die Erweiterung installiert wurde, können Sie psql-Metabefehl `\dx` verwenden.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Die Funktionen zum Importieren von Daten aus Amazon S3 und Exportieren von Daten nach Amazon S3 sind jetzt verfügbar.
# Übersicht über den Import von Daten aus Amazon S3-Daten
**So importieren Sie S3-Daten in Amazon RDS:**
Sammeln Sie zunächst die Details, die Sie der Funktion zur Verfügung stellen müssen. Dazu gehören der Name der Tabelle auf der Ihre RDS for PostgreSQL-DB-Instance sowie der Bucket-Name, der Dateipfad, der Dateityp und der AWS-Region Speicherort der Amazon S3 S3-Daten. Weitere Informationen finden Sie unter [Kopieren von Objekten ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
**Anmerkung**
Der mehrteilige Datenimport aus Amazon S3 wird derzeit nicht unterstützt.
1. Ermittelt den Namen der Tabelle, in die die `aws_s3.table_import_from_s3`-Funktion die Daten importieren soll. Mit dem folgenden Befehl wird beispielsweise eine Tabelle `t1` erstellt, die in späteren Schritten verwendet werden kann.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Rufen Sie die Details zum Amazon-S3-Bucket und die zu importierenden Daten ab. Öffnen Sie dazu die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)und wählen Sie **Buckets**. Suchen Sie den Bucket, der Ihre Daten enthält, in der Liste. Wählen Sie den Bucket aus, öffnen Sie die Seite Objektübersicht und wählen Sie dann Properties (Eigenschaften).
Notieren Sie sich den Namen, den Pfad AWS-Region, den und den Dateityp des Buckets. Sie benötigen den Amazon-Ressourcenname (ARN) später, um den Zugriff auf Amazon S3 über eine IAM-Rolle einzurichten. Weitere Informationen finden Sie unter [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](USER_PostgreSQL.S3Import.AccessPermission.md). In der folgenden Abbildung sehen Sie ein Beispiel.
![\[Bild eines Dateiobjekts in einem Amazon-S3-Bucket.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. Sie können den Pfad zu den Daten im Amazon S3 S3-Bucket überprüfen, indem Sie den AWS CLI Befehl verwenden`aws s3 cp`. Wenn die Informationen korrekt sind, lädt dieser Befehl eine Kopie der Amazon S3-Datei herunter.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Richten Sie Berechtigungen auf Ihrer DB-Instance von RDS für PostgreSQL ein, um den Zugriff auf die Datei im Amazon-S3-Bucket zu gestatten. Dazu verwenden Sie entweder eine AWS Identity and Access Management (IAM-) Rolle oder Sicherheitsanmeldedaten. Weitere Informationen finden Sie unter [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Geben Sie den Pfad und andere gesammelte Amazon S3-Objektdetails (siehe Schritt 2) an die `create_s3_uri`-Funktion zum Erstellen eines Amazon S3-URI-Objekts. Weitere Informationen zu dieser Funktion finden Sie unter [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). Es folgt ein Beispiel für die Erstellung dieses Objekts während einer psql-Sitzung.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
Im nächsten Schritt übergeben Sie dieses Objekt (`aws_commons._s3_uri_1`) an die `aws_s3.table_import_from_s3`-Funktion, um die Daten in die Tabelle zu importieren.
1. Rufen Sie die `aws_s3.table_import_from_s3`-Funktion zum Importieren der Daten aus Amazon S3 in Ihre Tabelle auf. Referenz-Informationen finden Sie unter [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). Beispiele finden Sie unter [Daten von Amazon S3 in Ihren ) importieren](USER_PostgreSQL.S3Import.FileFormats.md).
# Einrichten des Zugriffs auf einen Amazon-S3-Bucket
Um Daten aus einer Amazon S3-Datei zu importieren, erteilen Sie dem/der des RDS für PostgreSQL-DB-Clusters die Berechtigung, auf den Amazon S3-Bucket zuzugreifen, in dem sich die Datei befindet. Sie können den Zugriff auf einen Amazon S3-Bucket auf zwei Arten erlaubt, wie in den folgenden Themen beschrieben.
**Topics**
+ [Verwenden einer IAM-Rolle für den Zugriff auf einen Amazon S3-Bucket](#USER_PostgreSQL.S3Import.ARNRole)
+ [Verwenden von Sicherheitsanmeldeinformationen für den Zugriff auf einen Amazon S3-Bucket](#USER_PostgreSQL.S3Import.Credentials)
+ [Fehlerbehebung beim Zugriff auf Amazon S3](#USER_PostgreSQL.S3Import.troubleshooting)
## Verwenden einer IAM-Rolle für den Zugriff auf einen Amazon S3-Bucket
Bevor Sie Daten aus einer Amazon S3-Datei laden, geben Sie Ihrer -RDS für PostgreSQL DB-Instance die Berechtigung, auf den Amazon S3-Bucket der Datei zuzugreifen. Auf diese Weise müssen Sie keine zusätzlichen Anmeldeinformationen verwalten oder im [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3)-Funktionsaufruf angeben.
Erstellen Sie dazu eine IAM-Richtlinie, die den Zugriff auf den Amazon S3-Bucket ermöglicht. Erstellen Sie eine IAM-Rolle und hängen Sie die Richtlinie an die Rolle an. Weisen Sie dann die IAM-Rolle Ihrer DB Instance zu.
**So geben Sie einer RDS for PostgreSQL DB-Instance über eine IAM-Rolle Zugriff auf Amazon S3:**
1. Erstellen Sie eine IAM-Richtlinie.
Diese Richtlinie enthält die Bucket- und Objektberechtigungen, die Ihrer -RDS für PostgreSQL DB-Instance den Zugriff auf Amazon S3 ermöglichen.
Nehmen Sie die folgenden erforderlichen Aktionen in die Richtlinie auf, um die Übertragung von Dateien von einem Amazon S3-Bucket nach Amazon RDS zu ermöglichen:
+ `s3:GetObject`
+ `s3:ListBucket`
Nehmen Sie die folgenden Ressourcen in die Richtlinie auf, um den Amazon S3-Bucket und Objekte im Bucket zu identifizieren. Dies zeigt das Amazon Resource Name (ARN) Format für den Zugriff auf Amazon S3 an.
+ arn:aws:s3::: *amzn-s3-demo-bucket*
+ arn:aws:s3::: /\$1 *amzn-s3-demo-bucket*
Weitere Informationen zum Erstellen einer IAM-Richtlinie für RDS für PostgreSQL finden Sie unter [Erstellen und Verwenden einer IAM-Richtlinie für den IAM-Datenbankzugriff](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Siehe auch [Tutorial: Erstellen und Anfügen Ihrer ersten vom Kunden verwalteten Richtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) im *IAM-Benutzerhandbuch*.
Der folgende AWS CLI Befehl erstellt eine IAM-Richtlinie mit diesen Optionen. `rds-s3-import-policy` Sie gewährt Zugriff auf einen Bucket namens *amzn-s3-demo-bucket*.
**Anmerkung**
Notieren Sie sich den Amazon-Ressourcennamen (ARN) der Richtlinie, der vom Befehl zurückgegeben wurde. Sie benötigen den ARN in einem nachfolgenden Schritt, in dem Sie die Richtlinie an eine IAM-Rolle anhängen.
**Example**
Für Linux, macOS oder Unix:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Für Windows:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Erstellen Sie eine IAM-Rolle.
Sie tun dies, damit Amazon RDS in Ihrem Namen diese IAM-Rolle übernehmen kann, um auf Ihre Amazon S3-Buckets zuzugreifen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
Wir empfehlen die Verwendung von `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` und `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` globaler Bedingungskontext-Schlüssel in ressourcenbasierten Richtlinien, um die Berechtigungen des Dienstes auf eine bestimmte Ressource zu beschränken. Dies ist der effektivste Weg, um sich vor dem [verwirrtes Stellvertreterproblem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) zu schützen.
Wenn Sie sowohl globale Kontextschlüssel nutzen und der `aws:SourceArn`-Wert enthält die Konto-ID, muss der `aws:SourceAccount`-Wert und das Konto im `aws:SourceArn`-Wert die gleiche Konto-ID verwenden, wenn er in der gleichen Richtlinienanweisung verwendet wird.
+ Verwenden von `aws:SourceArn` wenn Sie einen serviceübergreifenden Zugriff für eine einzelne Ressource wünschen.
+ Verwenden von `aws:SourceAccount` wenn Sie zulassen möchten, dass eine Ressource in diesem Konto mit der betriebsübergreifenden Verwendung verknüpft wird.
Verwenden Sie in der Richtlinie den `aws:SourceArn` globalen Kontextschlüssel mit dem vollständigen ARN der Ressource. Das folgende Beispiel zeigt, wie Sie dazu den AWS CLI Befehl verwenden, um eine Rolle mit dem Namen `rds-s3-import-role` zu erstellen.
**Example**
Für Linux, macOS oder Unix:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Für Windows:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Fügen Sie die erstellte IAM-Richtlinie der IAM-Rolle an, die Sie erstellt haben.
Mit dem folgenden AWS CLI Befehl wird die im vorherigen Schritt erstellte Richtlinie der Rolle `rds-s3-import-role` Replace `your-policy-arn` mit dem Richtlinien-ARN zugeordnet, den Sie in einem früheren Schritt notiert haben.
**Example**
Für Linux, macOS oder Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Für Windows:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Fügen Sie die IAM-Rolle der DB Instance hinzu.
Dazu verwenden Sie das AWS-Managementkonsole oder AWS CLI, wie im Folgenden beschrieben.
### Konsole
**So fügen Sie eine IAM-Rolle für eine PostgreSQL DB--Instance über die Konsole hinzu:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie den Namen der PostgreSQL DB--Instance aus, um ihre Details anzuzeigen.
1. Wählen Sie auf der Registerkarte **Connectivity & Security** im Bereich **Manage IAM roles** (IAM-Rollen verwalten) die Rolle aus, die unter **Add IAM roles (IAM-Rollen hinzufügen) zu diesen Instances** hinzugefügt werden soll.
1. Wählen Sie unter **Feature (Funktion)** die Option **s3Import** aus.
1. Wählen Sie **Rolle hinzufügen**.
### AWS CLI
**So fügen Sie eine IAM-Rolle für eine PostgreSQL-DB-Instance mithilfe der CLI hinzu**
+ Verwenden Sie den folgenden CLI-Befehl, um die IAM-Rolle zur RDS für PostgreSQL DB-Instance mit dem Namen `my-db-instance` hinzuzufügen. Ersetzen Sie *`your-role-arn`* durch den Rollen-ARN, den Sie im vorherigen Schritt notiert haben. Verwenden Sie `s3Import` für den Wert der `--feature-name`-Option.
**Example**
Für Linux, macOS oder Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Für Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### RDS-API
Um eine IAM-Rolle für eine mithilfe der Amazon RDS-API hinzuzufügen, rufen Sie den Vorgang auf.
## Verwenden von Sicherheitsanmeldeinformationen für den Zugriff auf einen Amazon S3-Bucket
Wenn Sie es vorziehen, können Sie Sicherheitsanmeldeinformationen verwenden, um den Zugriff auf einen Amazon S3-Bucket zu ermöglichen, anstatt den Zugriff mit einer IAM-Rolle zu ermöglichen. Dazu geben Sie die `credentials`-Parameter im [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3)-Funktionsaufruf an.
Der `credentials` Parameter ist eine Struktur vom Typ`aws_commons._aws_credentials_1`, die Anmeldeinformationen enthält. AWS Verwenden Sie die Funktion [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials), um den Zugriffs- und den Geheimschlüssel in einer `aws_commons._aws_credentials_1`-Struktur festzulegen, wie nachfolgend dargestellt.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
Nachdem Sie die `aws_commons._aws_credentials_1 `-Struktur erstellt haben, verwenden Sie die Funktion [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) mit dem Parameter `credentials`, um die Daten zu importieren, wie nachfolgend gezeigt.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
Sie können auch den Funktionsaufruf [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) in den Funktionsaufruf `aws_s3.table_import_from_s3` einbinden.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Fehlerbehebung beim Zugriff auf Amazon S3
Wenn Sie beim Versuch, Daten aus Amazon S3 zu importieren, auf Verbindungsprobleme stoßen, finden Sie im Folgenden Empfehlungen:
+ [Fehlerbehebung für Amazon RDS-Identität und -Zugriff](security_iam_troubleshoot.md)
+ [Fehlerbehebung bei Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) im *Entwicklerhandbuch für Amazon Simple Storage Service*
+ [Fehlerbehebung bei Amazon S3 und IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) im *IAM-Benutzerhandbuch*
# Daten von Amazon S3 in Ihren ) importieren
Sie importieren Daten aus Ihrem Amazon-S3-Bucket mithilfe der `table_import_from_s3`-Funktion der aws\$1s3-Erweiterung. Referenz-Informationen finden Sie unter [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**Anmerkung**
Die folgenden Beispiele verwenden die IAM-Rollen-Methode, um den Zugriff auf den Amazon-S3-Bucket zu ermöglichen. Daher enthalten die `aws_s3.table_import_from_s3`-Funktionsaufrufe keine Berechtigungsnachweisparameter.
Nachfolgend ist ein typisches Beispiel aufgeführt.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
Es werden folgende Parameter verwendet:
+ `t1` – Der Name für die Tabelle in der PostgreSQL DB Instance, in die die Daten kopiert werden.
+ `''` – Eine optionale Liste mit Spalten in der Datenbanktabelle. Mithilfe dieses Parameters können Sie angeben, welche Spalten der S3-Daten in die Tabellenspalten übernommen werden sollen. Wenn keine Spalten angegeben sind, werden alle Spalten in die Tabelle kopiert. Ein Beispiel zum Verwenden einer Spaltenliste finden Sie unter [Importieren einer Amazon S3-Datei, die ein benutzerdefiniertes Trennzeichen verwendet](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)` – PostgreSQL COPY-Argumente. Der Kopiervorgang verwendet die Argumente und das Format des [PostgreSQL-Befehls COPY](https://www.postgresql.org/docs/current/sql-copy.html), um die Daten zu importieren. Zu den Optionen für das Format gehören kommagetrennte Werte (CSV), Text und Binärwerte. Der Standard ist Text.
+ `s3_uri` – Eine Struktur mit den Informationen zum Identifizieren der Amazon S3-Datei. Ein Beispiel für die Verwendung der Funktion [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) zum Erstellen einer `s3_uri`-Struktur finden Sie unter [Übersicht über den Import von Daten aus Amazon S3-Daten](USER_PostgreSQL.S3Import.Overview.md).
Weitere Informationen zu dieser Funktion finden Sie unter [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Die Funktion gibt `aws_s3.table_import_from_s3` zurück. Weitere Informationen zum Angeben von anderen Dateien für den Import aus einem Amazon S3-Bucket finden Sie in einem der folgenden Beispiele.
**Anmerkung**
Beim Importieren einer Datei mit 0 Byte tritt ein Fehler auf.
**Topics**
+ [Importieren einer Amazon S3-Datei, die ein benutzerdefiniertes Trennzeichen verwendet](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [Importieren einer Amazon S3-komprimierten Datei (gzip)](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [Importieren einer kodierten Amazon S3-Datei](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Importieren einer Amazon S3-Datei, die ein benutzerdefiniertes Trennzeichen verwendet
Das folgende Beispiel zeigt, wie man eine Datei importiert, die ein benutzerdefiniertes Trennzeichen verwendet. Außerdem wird veranschaulicht, wie mit dem `column_list`-Parameter der Funktion [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) kontrolliert wird, wo die Daten in der Datenbanktabelle platziert werden.
Für dieses Beispiel wird angenommen, dass die folgenden Informationen in durch Pipe-Zeichen getrennte Spalten in der Amazon S3-Datei angeordnet sind.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**So importieren Sie eine Datei, die ein benutzerdefiniertes Trennzeichen verwendet:**
1. Erstellen Sie eine Tabelle in der Datenbank für die importierten Daten.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Verwenden Sie die folgende Form der Funktion [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3), um Daten aus der Amazon S3-Datei zu importieren.
Zur Angabe der Datei können Sie auch den Funktionsaufruf [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) in den Funktionsaufruf `aws_s3.table_import_from_s3` einbinden.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
Die Daten befinden sich nun in den folgenden Spalten der Tabelle.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Importieren einer Amazon S3-komprimierten Datei (gzip)
Das folgende Beispiel zeigt, wie eine mit gzip komprimierte Datei aus Amazon S3 importiert wird. Die Datei, die Sie importieren, muss die folgenden Amazon-S3-Metadaten aufweisen:
+ Schlüssel: `Content-Encoding`
+ Wert: `gzip`
Wenn Sie die Datei mithilfe von hochladen AWS-Managementkonsole, werden die Metadaten in der Regel vom System übernommen. Informationen zum Hochladen von Dateien auf Amazon S3 mithilfe der AWS-Managementkonsole AWS CLI, der oder der API finden Sie unter [Hochladen von Objekten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) im *Amazon Simple Storage Service-Benutzerhandbuch*.
Weitere Informationen zu Amazon-S3-Metadaten und zu vom System bereitgestellten Metadaten finden Sie unter [Bearbeiten von Objektmetadaten in der Amazon-S3-Konsole](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
Importieren Sie die gzip-Datei folgendermaßen in Ihrer -RDS for PostgreSQL DB-Instance.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Importieren einer kodierten Amazon S3-Datei
Das folgende Beispiel zeigt, wie eine Datei aus Amazon S3 mit Windows-1252-Kodierung importiert wird.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Funktionsreferenz
**Topics**
+ [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3)
+ [aws\$1commons.create\$1s3\$1uri](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Importiert Amazon S3-Daten in eine Amazon RDS-Tabelle. Die Erweiterung `aws_s3` stellt die Funktion `aws_s3.table_import_from_s3` bereit. Der Rückgabewert ist Text.
### Syntax
Die erforderlichen Parameter sind `table_name`, `column_list` und `options`. Diese Parameter identifizieren die Datenbanktabelle und geben an, wie die Daten in die Tabelle kopiert werden.
Sie können auch die folgenden Parameter verwenden:
+ Die zu importierende Amazon S3-Datei wird mit dem Parameter `s3_info` übergeben. Wenn Sie diesen Parameter verwenden, wird der Zugriff auf Amazon S3 von einer IAM-Rolle für die PostgreSQL DB--Instance bereitgestellt.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ Die Anmeldeinformationen für den Zugriff auf Amazon S3 werden mit dem Parameter `credentials` übergeben. Mit diesem Parameter verwenden Sie keine IAM-Rolle.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parameters
*table\$1name*
Eine erforderliche Textzeichenfolge mit dem Namen der PostgreSQL-Datenbanktabelle, in die die Daten importiert werden sollen.
*column\$1list*
Eine erforderliche Textzeichenfolge mit einer optionalen Liste der Tabellenspalten der PostgreSQL-Datenbank, in die die Daten kopiert werden sollen. Wenn die Zeichenfolge leer ist, werden alle Spalten der Tabelle verwendet. Ein Beispiel finden Sie unter [Importieren einer Amazon S3-Datei, die ein benutzerdefiniertes Trennzeichen verwendet](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*options*
Eine erforderliche Textzeichenfolge mit Argumenten für den PostgreSQL `COPY`-Befehl. Diese Parameter legen fest, wie die Daten in die PostgreSQL-Tabelle kopiert werden. Weitere Informationen finden Sie in der [PostgreSQL COPY-Dokumentation](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
Ein zusammengesetzter `aws_commons._s3_uri_1`-Typ mit den folgenden Informationen zum S3-Objekt:
+ `bucket` – Der Name des Amazon S3-Buckets, der die Datei enthält.
+ `file_path` – Der Amazon S3-Dateiname einschließlich des Pfads der Datei.
+ `region`— Die AWS Region, in der sich die Datei befindet. Eine Liste der AWS Regionsnamen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
*Anmeldedaten*
Ein zusammengesetzter `aws_commons._aws_credentials_1`-Typ mit den folgenden Anmeldeinformationen, die für den Importvorgang verwendet werden sollen:
+ Zugriffsschlüssel
+ Geheimschlüssel
+ Sitzungs-Token
Hinweise zum Erstellen einer zusammengesetzten `aws_commons._aws_credentials_1`-Struktur finden Sie unter [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Alternative Syntax
Zum Testen können Sie statt der Parameter `s3_info` und `credentials` eine erweiterte Gruppe von Parametern verwenden. Nachfolgend sind weitere Syntaxvariationen für die Funktion `aws_s3.table_import_from_s3` aufgeführt:
+ Statt den Parameter `s3_info` zum Identifizieren einer Amazon S3-Datei zu verwenden, nutzen Sie die Kombination aus den Parametern `bucket`, `file_path` und `region`. Mit dieser Form der Funktion wird der Zugriff auf Amazon S3 mit einer IAM-Rolle für die PostgreSQL-DB-Instance bereitgestellt.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Statt den Parameter `credentials` zum Angeben einer Amazon S3-Datei zu verwenden, nutzen Sie die Kombination aus den Parametern `access_key`, `session_key` und `session_token`.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Alternative Parameter
*bucket*
Eine Textzeichenfolge mit den Namen des Amazon S3-Buckets, der die Datei enthält.
*file\$1path*
Eine Textzeichenfolge, die den Amazon S3-Dateinamen einschließlich des Pfades der Datei enthält.
*Region*
Eine Textzeichenfolge, die den AWS-Region Speicherort der Datei angibt. Eine Liste der AWS-Region Namen und zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
Eine Textzeichenfolge mit dem Zugriffsschlüssel, der für den Importvorgang verwendet werden soll. Der Standardwert ist „NULL“.
*secret\$1key*
Eine Textzeichenfolge mit dem Geheimschlüssel, der für den Importvorgang verwendet werden soll. Der Standardwert ist „NULL“.
*session\$1token*
(Optional) Eine Textzeichenfolge mit dem Sitzungsschlüssel, der für den Importvorgang verwendet werden soll. Der Standardwert ist „NULL“.
## aws\$1commons.create\$1s3\$1uri
Erstellt eine `aws_commons._s3_uri_1`-Struktur für die Amazon S3-Dateiinformationen. Die Ergebnisse der Funktion `aws_commons.create_s3_uri` werden im Parameter `s3_info` der Funktion [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) verwendet.
### Syntax
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parameters
*bucket*
Eine erforderliche Textzeichenfolge mit dem Namen des Amazon S3-Buckets für die Datei.
*file\$1path*
Eine erforderliche Textzeichenfolge, die den Amazon S3-Dateinamen einschließlich des Pfads der Datei enthält.
*Region*
Eine erforderliche Textzeichenfolge AWS-Region , die den Inhalt der Datei enthält. Eine Liste der AWS-Region Namen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Legt einen Zugriffs- und einen Geheimschlüssel in einer `aws_commons._aws_credentials_1`-Struktur fest. Die Ergebnisse der Funktion `aws_commons.create_aws_credentials` werden im Parameter `credentials` der Funktion [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) verwendet.
### Syntax
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parameters
*access\$1key*
Eine erforderliche Textzeichenfolge mit dem Zugriffsschlüssel, der zum Importieren einer Amazon S3-Datei verwendet werden soll. Der Standardwert ist „NULL“.
*secret\$1key*
Eine erforderliche Textzeichenfolge mit dem Geheimschlüssel, der zum Importieren einer Amazon S3-Datei verwendet werden soll. Der Standardwert ist „NULL“.
*session\$1token*
Eine erforderliche Textzeichenfolge mit dem Sitzungs-Token, der zum Importieren einer Amazon S3-Datei verwendet werden soll. Der Standardwert ist „NULL“. Wenn Sie ein optionales `session_token` angeben, können Sie temporäre Anmeldeinformationen verwenden.
# Transport von PostgreSQL-Datenbanken zwischen DB-Instances
Mit der Verwendung von PostgreSQL-Transportdatenbanken für Amazon RDS können Sie eine PostgreSQL-Datenbank zwischen zwei DB-Instances bewegen. Dies ist eine sehr schnelle Möglichkeit, große Datenbanken zwischen verschiedenen DB-Instances zu migrieren. Um diesen Ansatz zu verwenden, müssen Ihre DB-Instances beide die gleiche Hauptversion von PostgreSQL ausführen.
Diese Funktion erfordert, dass Sie die `pg_transport`-Erweiterung sowohl für die Quell- als auch die Ziel-DB-Instance installieren. Die `pg_transport`-Erweiterung bietet einen physischen Transportmechanismus, der die Datenbankdateien mit minimaler Verarbeitung verschiebt. Dieser Mechanismus bewegt Daten viel schneller als herkömmliche Abfragen- und Ladeprozesse mit weniger Ausfallzeiten.
**Anmerkung**
PostgreSQL-Transportdatenbanken sind in RDS for PostgreSQL Version 11.5 und höher und RDS for PostgreSQL Version 10.10 und höher verfügbar.
Um eine PostgreSQL-DB-Instance von einer DB-Instance von RDS for PostgreSQL zu einer anderen zu transportieren, richten Sie zuerst die Quell- und Zielinstances ein, wie in [ Einrichten einer DB-Instance für den Transport](PostgreSQL.TransportableDB.Setup.md) beschrieben. Anschließend können Sie die Datenbank mit der unter [ Transport einer PostgreSQL-Datenbank](PostgreSQL.TransportableDB.Transporting.md) beschriebenen Funktion transportieren.
**Topics**
+ [Was passiert beim Datenbanktransport?](#PostgreSQL.TransportableDB.DuringTransport)
+ [Einschränkungen für die Verwendung von PostgreSQL-Transportdatenbanken](#PostgreSQL.TransportableDB.Limits)
+ [Einrichten des Transports einer PostgreSQL-Datenbank](PostgreSQL.TransportableDB.Setup.md)
+ [Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel](PostgreSQL.TransportableDB.Transporting.md)
+ [Funktionsreferenz für transportable Datenbanken](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [Parameterreferenz für transportable Datenbanken](PostgreSQL.TransportableDB.Parameters.md)
## Was passiert beim Datenbanktransport?
Die Funktion PostgreSQL-Transportdatenbanken verwendet ein Pull-Modell, um die Datenbank aus der Quell-DB-Instance in das Ziel zu importieren. Die `transport.import_from_server`-Funktion erstellt die In-Transit-Datenbank auf der Ziel-DB-Instance. Die In-Transit-Datenbank ist auf der Ziel-DB-Instance für die Dauer des Transports nicht zugänglich.
Wenn der Transport beginnt, werden alle aktuellen Sitzungen auf der Quelldatenbank beendet. Alle anderen Datenbanken als die Quelldatenbank auf der Quell-DB-Instance sind vom Transport nicht betroffen.
Die Quelldatenbank wird in einen speziellen schreibgeschützten Modus versetzt. Während es sich in diesem Modus befindet, können Sie sich mit der Quelldatenbank verbinden und schreibgeschützte Abfragen durchführen. Allerdings sind schreibende Abfragen und einige andere Arten von Befehlen blockiert. Von diesen Einschränkungen ist nur die spezifische Quelldatenbank betroffen, die transportiert wird.
Während des Transports können Sie für die Ziel-DB-Instance keine Point-in-time-Wiederherstellung durchführen. Dies liegt daran, dass der Transport nicht transaktional ist und das PostgreSQL-Write-Ahead-Protokoll nicht verwendet, um Änderungen aufzuzeichnen. Wenn für die Ziel-DB-Instance automatische Backups aktiviert sind, wird nach Abschluss des Transports automatisch eine Sicherung erstellt. Point-in-timeWiederherstellungen sind für bestimmte Zeiten *nach* Abschluss des Backups verfügbar.
Wenn der Transport fehlschlägt, versucht die `pg_transport`-Erweiterung, alle Änderungen an den Quell- und Ziel-DB-Instances rückgängig zu machen. Dazu gehört auch das Entfernen der teilweise transportierten Datenbank auf dem Ziel. Abhängig von der Art des Fehlers kann es vorkommen, dass die Quelldatenbank weiterhin schreibende Abfragen ablehnt. Verwenden Sie in diesem Fall den folgenden Befehl, um schreibende Abfragen zu ermöglichen.
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## Einschränkungen für die Verwendung von PostgreSQL-Transportdatenbanken
Transportdatenbanken haben folgende Einschränkungen:
+ **Lesereplikate** – Sie können keine Transportdatenbanken für Lesereplikate oder übergeordnete Instances von Lesereplikaten verwenden.
+ **Nicht unterstützte Spaltentypen** – Sie können die `reg`-Datentypen nicht in Datenbanktabellen verwenden, die Sie mit dieser Methode transportieren möchten. Diese Typen hängen vom Systemkatalogobjekt IDs (OIDs) ab, das sich während des Transports häufig ändert.
+ **Tablespaces** – Alle Quelldatenbankobjekte müssen sich im Standard-Tablespace `pg_default` befinden.
+ **Kompatibilität** – Sowohl die Quell- als auch die Ziel-DB-Instance müssen die gleiche Hauptversion von PostgreSQL ausführen.
+ **Erweiterungen** – Auf der Quell-DB-Instance kann nur das `pg_transport` installiert sein.
+ **Rollen und ACLs** — Die Zugriffsberechtigungen und Besitzinformationen der Quelldatenbank werden nicht auf die Zieldatenbank übertragen. Alle Datenbankobjekte werden erstellt und gehören dem lokalen Zielbenutzer des Transports.
+ **Gleichzeitige Transporte** – Eine einzelne DB-Instance kann bis zu 32 gleichzeitige Transporte unterstützen, einschließlich Importe und Exporte, wenn Worker-Prozesse ordnungsgemäß konfiguriert wurden.
+ **Nur DB-Instances von RDS for PostgreSQL** – Transportable PostgreSQL-Datenbanken werden nur auf DB-Instances von RDS for PostgreSQL unterstützt. Sie können es nicht mit lokalen Datenbanken oder Datenbanken verwenden, die auf Amazon EC2 ausgeführt werden.
# Einrichten des Transports einer PostgreSQL-Datenbank
Stellen Sie vor Beginn sicher, dass Ihre DB-Instances von RDS für PostgreSQL die folgenden Anforderungen erfüllen:
+ Die DB-Instances von RDS für PostgreSQL für die Quelle und das Ziel müssen die gleiche Version von PostgreSQL ausführen.
+ Die Ziel-DB darf keine Datenbank mit dem gleichen Namen wie die Quell-DB haben, die Sie transportieren möchten.
+ Das Konto, das Sie zum Ausführen des Transports verwenden, benötigt `rds_superuser`-Berechtigungen sowohl für die Quell-DB als auch für die Ziel-DB.
+ Die Sicherheitsgruppe für die Quell-DB-Instance muss eingehenden Zugriff von der Ziel-DB-Instance zulassen. Dies ist möglicherweise bereits der Fall, wenn sich Ihre Quell- und Ziel-DB-Instances in der VPC befinden. Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md).
Für den Transport von Datenbanken von einer Quell-DB-Instance zu einer Ziel-DB-Instance sind mehrere Änderungen an der DB-Parametergruppe erforderlich, die mit jeder Instance verknüpft ist. Das bedeutet, dass Sie eine benutzerdefinierte DB-Parametergruppe für die Quell-DB-Instance erstellen und eine benutzerdefinierte DB-Parametergruppe für die Ziel-DB-Instance erstellen müssen.
**Anmerkung**
Wenn Ihre DB-Instances bereits mit benutzerdefinierten DB-Parametergruppen konfiguriert sind, können Sie mit Schritt 2 im folgenden Verfahren beginnen.
**Konfigurieren Sie die benutzerdefinierten DB-Gruppenparameter für den Transport von Datenbanken wie folgt:**
Verwenden Sie für die folgenden Schritte ein Konto mit `rds_superuser`-Berechtigungen.
1. Wenn die Quell- und Ziel-DB-Instances eine Standard-DB-Parametergruppe verwenden, müssen Sie eine benutzerdefinierte DB-Parametergruppe mit der entsprechenden Version für Ihre Instances erstellen. Sie tun dies, damit Sie Werte für mehrere Parameter ändern können. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Ändern Sie in der benutzerdefinierten DB-Parametergruppe die Werte für die folgenden Parameter:
+ `shared_preload_libraries` – Fügen Sie `pg_transport` zur Liste der Bibliotheken hinzu.
+ `pg_transport.num_workers` – Der Standardwert ist 3. Erhöhen oder reduzieren Sie diesen Wert nach Bedarf für Ihre Datenbank. Für eine 200-GB-Datenbank empfehlen wir nicht größer als 8. Beachten Sie, dass Sie, wenn Sie den Standardwert für diesen Parameter erhöhen, auch den Wert von `max_worker_processes` erhöhen sollten.
+ `pg_transport.work_mem` – Der Standardwert beträgt je nach PostgreSQL-Version entweder 128 MB oder 256 MB. Die Standardeinstellung kann normalerweise unverändert bleiben.
+ `max_worker_processes` – Der Wert dieses Parameters muss unter Verwendung der folgenden Berechnung festgelegt werden:
```
(3 * pg_transport.num_workers) + 9
```
Dieser Wert ist am Ziel erforderlich, um verschiedene Hintergrund-Worker-Prozesse abzuwickeln, die am Transport beteiligt sind. Weitere Informationen über `max_worker_processes,` finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
Weitere Informationen zu `pg_transport`-Parametern finden Sie unter [Parameterreferenz für transportable Datenbanken](PostgreSQL.TransportableDB.Parameters.md).
1. Starten Sie die Quell-DB-Instances von RDS für PostgreSQL und die Ziel-Instance neu, damit die Einstellungen für die Parameter wirksam werden.
1. Stellen Sie eine Verbindung zu Ihrer Quell-DB-Instance von RDS für PostgreSQL her.
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Entfernen Sie fremde Erweiterungen aus dem öffentlichen Schema der DB-Instance. Während des eigentlichen Transportvorgangs ist nur die `pg_transport`-Erweiterung zulässig.
1. Installieren Sie die `pg_transport`-Erweiterung wie folgt:
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. Stellen Sie eine Verbindung zu Ihrer Ziel-DB-Instance von RDS für PostgreSQL her. Entfernen Sie alle fremden Erweiterungen und installieren Sie dann die `pg_transport`-Erweiterung.
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel
Nachdem Sie den in [Einrichten des Transports einer PostgreSQL-Datenbank](PostgreSQL.TransportableDB.Setup.md) beschriebenen Prozess abgeschlossen haben, können Sie den Transport starten. Führen Sie dazu die Funktion `transport.import_from_server` auf der Ziel-DB-Instance aus. In der folgenden Syntax finden Sie die Funktionsparameter.
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
Der im Beispiel gezeigte `false`-Wert teilt der Funktion mit, dass es sich nicht um einen Trockenlauf handelt. Um die Transporteinrichtung zu testen, können Sie `true` für die Option `dry_run` angeben, wenn Sie die Funktion aufrufen, wie im Folgenden gezeigt:
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
Die INFO-Zeilen werden ausgegeben, da der `pg_transport.timing`-Parameter auf seinen Standardwert eingestellt ist, `true`. Legen Sie `dry_run` auf `false` fest, wenn Sie den Befehl ausführen und die Quelldatenbank wie folgt in das Ziel importiert wird:
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
Für diese Funktion müssen Sie Passwörter für Datenbankbenutzer angeben. Daher empfehlen wir Ihnen, die Passwörter der Benutzerrollen, die Sie für den Transportvorgang verwendet haben, nach Abschluss des Transports zu ändern. Oder Sie können SQL-Bind-Variablen verwenden, um temporäre Benutzerrollen zu erstellen. Verwenden Sie diese temporären Rollen für den Transport und entfernen Sie die Rollen anschließend.
Falls Ihr Transport nicht erfolgreich ist, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
Die Fehlermeldung „Dateidaten konnte nicht heruntergeladen werden“ zeigt an, dass die Anzahl der Worker-Prozesse für die Größe der Datenbank nicht korrekt festgelegt ist. Möglicherweise müssen Sie den für `pg_transport.num_workers` festgelegten Wert erhöhen oder verringern. Jeder Fehler meldet den Prozentsatz der Fertigstellung, sodass Sie die Auswirkungen Ihrer Änderungen sehen können. Wenn Sie beispielsweise die Einstellung in einem Fall von 8 auf 4 ändern, führte dies zu Folgendem:
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
Beachten Sie, dass der Parameter `max_worker_processes` auch während des Transportvorgangs berücksichtigt wird. Mit anderen Worten, Sie müssen möglicherweise sowohl `pg_transport.num_workers` als auch `max_worker_processes` ändern, um die Datenbank erfolgreich zu transportieren. Das gezeigte Beispiel hat endlich funktioniert, als die `pg_transport.num_workers` wurde auf 2 eingestellt wurde:
```
pg_transport.num_workers=2 100% of files transported
```
Weitere Hinweise zur `transport.import_from_server`-Funktion und ihren Parametern finden Sie unter [Funktionsreferenz für transportable Datenbanken](PostgreSQL.TransportableDB.transport.import_from_server.md).
# Funktionsreferenz für transportable Datenbanken
Die `transport.import_from_server`-Funktion transportiert eine PostgreSQL-Datenbank, indem sie sie von einer Quell-DB-Instance in eine Ziel-DB-Instance importiert. Dies geschieht durch die Verwendung eines physischen Datenbankverbindungs-Transportmechanismus.
Vor dem Start des Transports überprüft diese Funktion, ob die Quell- und Ziel-DB-Instances dieselbe Version haben und für die Migration kompatibel sind. Es bestätigt auch, dass die Ziel-DB-Instance über genügend Speicherplatz für die Quelle verfügt.
**Syntax**
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**Rückgabewert**
Keine.
**Parameter**
Die Beschreibung der Parameter der `transport.import_from_server`-Funktion finden Sie in der folgenden Tabelle.
****
| Parameter | Beschreibung |
| --- | --- |
| host | Der Endpunkt der Quell-DB-Instance. |
| port | Eine ganze Zahl, die den Port der Quell-DB-Instance darstellt. PostgreSQL DB-Instances verwenden häufig den Port 5432. |
| username | Der Benutzer der Quell-DB-Instance. Dieser Benutzer muss Mitglied der Rolle `rds_superuser` sein. |
| password | Das Benutzerpasswort der Quell-DB-Instance. |
| database | Der Name der Datenbank in der zu transportierenden Quell-DB-Instance. |
| local\$1password | Das lokale Passwort des aktuellen Benutzers für die Ziel-DB-Instance. Dieser Benutzer muss Mitglied der Rolle `rds_superuser` sein. |
| dry\$1run | Ein optionaler boolescher Wert, der angibt, ob ein Trockenlauf durchgeführt werden soll. Die Voreinstellung ist `false`, was bedeutet, dass der Transport durchgeführt wird.Um die Kompatibilität zwischen der Quell- und der Ziel-DB-Instance zu bestätigen, ohne den eigentlichen Transport durchzuführen, legen Sie dry\$1run auf true fest. |
**Beispiel**
Ein Beispiel finden Sie unter [Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel](PostgreSQL.TransportableDB.Transporting.md).
# Parameterreferenz für transportable Datenbanken
Mehrere Parameter steuern das Verhalten der `pg_transport`-Erweiterung. Im Folgenden finden Sie Beschreibungen dieser Parameter.
**`pg_transport.num_workers`**
Die Anzahl der für den Transportprozess zu verwendenden Worker. Die Voreinstellung ist 3. Gültige Werte sind 1–32. Selbst die größten Datenbanktransporte erfordern in der Regel weniger als acht Worker. Der Wert dieser Einstellung für die Ziel-DB-Instance wird während des Transports sowohl vom Ziel als auch von der Quelle verwendet.
**`pg_transport.timing` **
Gibt an, ob während des Transports Zeitinformationen übermittelt werden sollen. Der Standardwert ist `true`, was bedeutet, dass Zeitinformationen gemeldet werden. Es wird empfohlen, diesen Parameter auf `true` festzulegen, damit Sie den Fortschritt überwachen können. Eine Beispielausgabe finden Sie unter [Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel](PostgreSQL.TransportableDB.Transporting.md).
**`pg_transport.work_mem`**
Die maximale Menge an Speicher, die für jeden Worker zugewiesen werden kann. Der Standardwert ist 131072 Kilobyte (KB) oder 262144 KB (256 MB), abhängig von der PostgreSQL-Version. Der Mindestwert beträgt 64 Megabyte (65536 KB). Gültige Werte sind in Kilobyte (KBs) als binäre Basis-2-Einheiten angegeben, wobei 1 KB = 1024 Byte ist.
Der Transport benötigt möglicherweise weniger Speicher als in diesem Parameter angegeben. Selbst große Datenbanktransporte benötigen normalerweise weniger als 256 MB (262144 KB) Speicher pro Worker.
# Exportieren von Daten aus einem/einer RDS für PostgreSQL-DB-Instance zu Amazon S3
Sie können Daten aus einer DB-Instance von RDS für PostgreSQL abfragen und direkt in Dateien exportieren, die in einem Amazon-S3-Bucket gespeichert sind. Dazu installieren Sie zuerst die Erweiterung von RDS für PostgreSQL `aws_s3`. Diese Erweiterung stellt die Funktionen bereit, die Sie zum Exportieren von Abfrageergebnissen nach Amazon S3 verwenden. Im Folgenden erfahren Sie, wie Sie die Erweiterung installieren und Daten nach Amazon S3 exportieren.
**Anmerkung**
Kontoübergreifender Export nach Amazon S3 wird nicht unterstützt.
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen den Export von Daten nach Amazon Simple Storage Service. Ausführliche Versionsinformationen 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*.
Wenn Sie keinen Bucket für Ihren Export eingerichtet haben, lesen Sie die folgenden Themen im *Benutzerhandbuch von Amazon Simple Storage Service*.
+ [Einrichten von Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
Standardmäßig verwenden die von RDS für PostgreSQL nach Amazon S3 exportierten Daten eine serverseitige Verschlüsselung mit einem Von AWS verwalteter Schlüssel Wenn Sie die Bucket-Verschlüsselung verwenden, muss der Amazon S3 S3-Bucket mit einem AWS Key Management Service (AWS KMS) -Schlüssel (SSE-KMS) verschlüsselt werden. Derzeit werden Buckets, die mit Schlüsseln verschlüsselt sind, die von Amazon S3 (SSE-S3) verwaltet werden, nicht unterstützt.
**Anmerkung**
Sie können DB-Snapshot-Daten mit der AWS-Managementkonsole AWS CLI, oder Amazon RDS-API in Amazon S3 speichern. Weitere Informationen finden Sie unter [Exportieren von DB-Snapshot-Daten nach Amazon S3 für Amazon RDS](USER_ExportSnapshot.md).
**Topics**
+ [Installieren der Erweiterung aws\$1s3](#USER_PostgreSQL.S3Export.InstallExtension)
+ [Übersicht über das Exportieren von Daten zu Amazon S3](#postgresql-s3-export-overview)
+ [Angeben des Amazon S3-Dateipfads für den Export](#postgresql-s3-export-file)
+ [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](postgresql-s3-export-access-bucket.md)
+ [Exportieren von Abfragedaten mithilfe der Funktion aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md)
+ [Funktionsreferenz](postgresql-s3-export-functions.md)
+ [Fehlerbehebung beim Zugriff auf Amazon S3](postgresql-s3-export-troubleshoot.md)
## Installieren der Erweiterung aws\$1s3
Bevor Sie Amazon Simple Storage Service mit Ihrer DB-Instance von RDS für PostgreSQL verwenden können, müssen Sie die Erweiterung `aws_s3` installieren. Diese Erweiterung bietet Funktionen zum Exportieren von Daten aus einer DB-Instance von RDS für PostgreSQL in einen Amazon-S3-Bucket Sie stellt außerdem Funktionen zum Importieren von Daten aus Amazon S3 bereit. Weitere Informationen finden Sie unter [Importieren von Amazon S3 in eine DB-Instance von RDS für PostgreSQL](USER_PostgreSQL.S3Import.md). Die Erweiterung `aws_s3` hängt von einigen Hilfsfunktionen in der Erweiterung `aws_commons` ab, die bei Bedarf automatisch installiert wird.
**So installieren Sie die Erweiterung `aws_s3`**
1. Verwenden Sie psql (oder pgAdmin), um eine Verbindung mit der DB-Instance von RDS für PostgreSQL als Benutzer mit `rds_superuser`-Berechtigungen herzustellen. Wenn Sie beim Einrichten den Standardnamen beibehalten haben, stellen Sie eine Verbindung als `postgres` her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Führen Sie den folgenden Befehl aus, um die Erweiterung zu installieren.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Wenn Sie überprüfen möchten, ob die Erweiterung installiert wurde, können Sie psql-Metabefehl `\dx` verwenden.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Die Funktionen zum Importieren von Daten aus Amazon S3 und Exportieren von Daten nach Amazon S3 sind jetzt verfügbar.
### Stellen Sie sicher, dass Ihre nach Amazon S3 unterstützt
Sie können überprüfen, ob Ihre Version von RDS für PostgreSQL den Export nach Amazon S3 unterstützt, indem Sie den Befehl `describe-db-engine-versions` verwenden. Im folgenden Beispiel wird die Unterstützung für Version 10.14 überprüft.
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
Wenn die Ausgabe die Zeichenfolge `"s3Export"` enthält, unterstützt die Engine Amazon S3-Exporte. Ansonsten unterstützt die Engine sie nicht.
## Übersicht über das Exportieren von Daten zu Amazon S3
Verwenden Sie das folgende Verfahren, um in einer Datenbank gespeicherte Daten in einen Amazon S3 Bucket zu exportieren.
**So exportieren Sie Daten nach S3**
1. Identifizieren Sie einen Amazon S3-Dateipfad, der zum Exportieren von Daten verwendet werden soll. Weitere Informationen zu diesem Prozess finden Sie unter [Angeben des Amazon S3-Dateipfads für den Export](#postgresql-s3-export-file).
1. Erteilen Sie die Berechtigung für den Zugriff auf den Amazon S3-Bucket.
Um Daten in eine Amazon S3-Datei zu exportieren, erteilen Sie dem/der RDS für PostgreSQL-DB-Instance die Berechtigung, auf den Amazon S3-Bucket zuzugreifen, den der Export für die Speicherung verwendet. Dazu gehören die folgenden Schritte:
1. Erstellen Sie eine IAM-Richtlinie, die Zugriff auf einen Amazon S3-Bucket bietet, in den Sie exportieren möchten.
1. Erstellen Sie eine IAM-Rolle.
1. Fügen Sie die erstellte Richtlinie an die erstellte Rolle an.
1. Fügen Sie diese IAM-Rolle zu Ihrem Ihrer DB-Instance hinzu.
Weitere Informationen zu diesem Prozess finden Sie unter [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](postgresql-s3-export-access-bucket.md).
1. Identifizieren Sie eine Datenbankabfrage, um die Daten abzurufen. Exportieren Sie die Abfragedaten, indem Sie die Funktion `aws_s3.query_export_to_s3` aufrufen.
Nachdem Sie die vorangegangenen Vorbereitungsaufgaben abgeschlossen haben, verwenden Sie die [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion, um Abfrageergebnisse in Amazon S3 zu exportieren. Weitere Informationen zu diesem Prozess finden Sie unter [Exportieren von Abfragedaten mithilfe der Funktion aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
## Angeben des Amazon S3-Dateipfads für den Export
Geben Sie die folgenden Informationen an, um den Speicherort in Amazon S3 zu identifizieren, in den Sie Daten exportieren möchten:
+ Bucket-Name – Ein *Bucket* ist ein Container für Amazon S3-Objekte oder -Dateien.
Weitere Informationen zum Speichern von Daten mit Amazon S3 finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) und [Arbeiten mit Objekten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ Dateipfad – Der Dateipfad gibt an, wo der Export im Amazon S3-Bucket gespeichert wird. Der Dateipfad besteht aus Folgendem:
+ Ein optionales Pfadpräfix, das einen Pfad für virtuelle Ordner identifiziert.
+ Ein Dateipräfix, das eine oder mehrere Dateien identifiziert, die gespeichert werden sollen. Größere Exporte werden in mehreren Dateien gespeichert, jeweils mit einer maximalen Größe von ca. 6 GB. Die zusätzlichen Dateinamen haben das gleiche Dateipräfix, aber mit `_partXX` angefügt. `XX` stellt 2, dann 3 usw. dar.
Beispielsweise ist ein Dateipfad mit einem `exports`-Ordner und einem `query-1-export`-Dateipräfix `/exports/query-1-export`.
+ AWS Region (optional) — Die AWS Region, in der sich der Amazon S3 S3-Bucket befindet. Wenn Sie keinen AWS Regionswert angeben, speichert Amazon RDS Ihre Dateien in Amazon S3 in derselben AWS Region wie die exportierende .
**Anmerkung**
Derzeit muss die AWS Region mit der Region der exportierenden identisch sein.
Eine Liste der AWS Regionsnamen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
Um die Amazon S3-Dateiinformationen darüber zu speichern, wo der Export gespeichert werden soll, können Sie die [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri)-Funktion verwenden, um eine zusammengesetzte `aws_commons._s3_uri_1`-Struktur wie folgt zu erstellen.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Sie geben diesen `s3_uri_1`-Wert später als Parameter im Aufruf der [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion an. Beispiele finden Sie unter [Exportieren von Abfragedaten mithilfe der Funktion aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
# Einrichten des Zugriffs auf einen Amazon-S3-Bucket
Um Daten zu Amazon S3 zu exportieren, erteilen Sie Ihrer PostgreSQL-DB-Instance die Berechtigung, auf den Amazon S3-Bucket zuzugreifen, in den die Dateien aufgenommen werden sollen.
Führen Sie dazu die folgenden Schritte aus.
**So erteilen Sie einer PostgreSQL-DB-Instance Zugriff auf Amazon S3 über eine IAM-Rolle**
1. Erstellen Sie eine IAM-Richtlinie.
Diese Richtlinie enthält die Bucket- und Objektberechtigungen, die Ihrer PostgreSQL-DB-Instance den Zugriff auf Amazon S3 ermöglichen.
Führen Sie beim Erstellen dieser Richtlinie die folgenden Schritte aus:
1. Nehmen Sie die folgenden erforderlichen Aktionen in die Richtlinie auf, um die Übertragung von Dateien aus Ihrer PostgreSQL-DB-Instance in einen Amazon S3-Bucket zu gestatten:
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Geben Sie den Amazon-Ressourcennamen (ARN) ein, der den Amazon S3-Bucket und die Objekte im Bucket identifiziert. Das ARN-Format für den Zugriff auf Amazon S3 lautet: `arn:aws:s3:::amzn-s3-demo-bucket/*`
Weitere Informationen zum Erstellen einer IAM-Richtlinie für Amazon RDS für PostgreSQL finden Sie unter [Erstellen und Verwenden einer IAM-Richtlinie für den IAM-Datenbankzugriff](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Siehe auch [Tutorial: Erstellen und Anfügen Ihrer ersten vom Kunden verwalteten Richtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) im *IAM-Benutzerhandbuch*.
Mit dem folgenden AWS CLI Befehl wird eine IAM-Richtlinie `rds-s3-export-policy` mit diesen Optionen erstellt. Sie gewährt Zugriff auf einen Bucket namens *amzn-s3-demo-bucket*.
**Warnung**
Es wird empfohlen, die Datenbank innerhalb einer privaten VPC einzurichten, deren Endpunktrichtlinien für den Zugriff auf bestimmte Buckets konfiguriert sind. Weitere Informationen finden Sie unter [Verwenden von Endpunktrichtlinien für Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) im Amazon VPC Benutzerhandbuch.
Es wird dringend empfohlen, keine Richtlinie mit Zugriff auf alle Ressourcen zu erstellen. Dieser Zugriff kann eine Bedrohung für die Datensicherheit darstellen. Wenn Sie eine Richtlinie erstellen, die `S3:PutObject` Zugriff auf alle Ressourcen mit `"Resource":"*"` gewährt, kann ein Benutzer mit Exportberechtigungen Daten in alle Buckets in Ihrem Konto exportieren. Darüber hinaus kann der Benutzer Daten in *jeden öffentlich beschreibbaren Bucket in Ihrer AWS -Region* exportieren.
Notieren Sie nach dem Erstellen der Richtlinie den Amazon-Ressourcennamen (ARN) der Richtlinie. Sie benötigen den ARN für einen nachfolgenden Schritt, in dem Sie die Richtlinie an eine IAM-Rolle anhängen.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Erstellen Sie eine IAM-Rolle.
Sie tun dies, damit Amazon RDS in Ihrem Namen diese IAM-Rolle übernehmen kann, um auf Ihre Amazon S3-Buckets zuzugreifen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
Wir empfehlen die Verwendung von `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` und `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` globaler Bedingungskontext-Schlüssel in ressourcenbasierten Richtlinien, um die Berechtigungen des Dienstes auf eine bestimmte Ressource zu beschränken. Dies ist der effektivste Weg, um sich vor dem [verwirrtes Stellvertreterproblem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) zu schützen.
Wenn Sie sowohl globale Kontextschlüssel nutzen und der `aws:SourceArn`-Wert enthält die Konto-ID, muss der `aws:SourceAccount`-Wert und das Konto im `aws:SourceArn`-Wert die gleiche Konto-ID verwenden, wenn er in der gleichen Richtlinienanweisung verwendet wird.
+ Verwenden von `aws:SourceArn` wenn Sie einen serviceübergreifenden Zugriff für eine einzelne Ressource wünschen.
+ Verwenden von `aws:SourceAccount` wenn Sie zulassen möchten, dass eine Ressource in diesem Konto mit der betriebsübergreifenden Verwendung verknüpft wird.
Verwenden Sie in der Richtlinie den `aws:SourceArn` globalen Kontextschlüssel mit dem vollständigen ARN der Ressource. Das folgende Beispiel zeigt, wie Sie dazu den AWS CLI Befehl verwenden, um eine Rolle mit dem Namen `rds-s3-export-role` zu erstellen.
**Example**
Für Linux, macOS oder Unix:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Für Windows:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Fügen Sie die erstellte IAM-Richtlinie der IAM-Rolle an, die Sie erstellt haben.
Mit dem folgenden AWS CLI Befehl wird die zuvor erstellte Richtlinie an die Rolle `rds-s3-export-role.` Replace `your-policy-arn` mit dem Richtlinien-ARN angehängt, den Sie in einem früheren Schritt notiert haben.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Fügen Sie die IAM-Rolle der DB Instance hinzu. Sie tun dies, indem Sie das AWS-Managementkonsole oder verwenden AWS CLI, wie im Folgenden beschrieben.
## Konsole
**So fügen Sie eine IAM-Rolle für eine PostgreSQL DB--Instance über die Konsole hinzu:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie den Namen der PostgreSQL DB--Instance aus, um ihre Details anzuzeigen.
1. Wählen Sie auf der Registerkarte **Connectivity & security (Konnektivität und Sicherheit)** im Bereich **Manage IAM roles (IAM-Rollen verwalten)** die Rolle aus, die unter **Add IAM roles to this instance (IAM-Rollen zu dieser Instance hinzufügen)** hinzugefügt werden soll.
1. Wählen Sie unter **Funktion** die Option **s3Export** aus.
1. Wählen Sie **Rolle hinzufügen**.
## AWS CLI
**So fügen Sie eine IAM-Rolle für eine PostgreSQL-DB-Instance mithilfe der CLI hinzu**
+ Verwenden Sie den folgenden CLI-Befehl, um die IAM-Rolle zur RDS für PostgreSQL DB-Instance mit dem Namen `my-db-instance` hinzuzufügen. Ersetzen Sie *`your-role-arn`* durch den Rollen-ARN, den Sie im vorherigen Schritt notiert haben. Verwenden Sie `s3Export` für den Wert der `--feature-name`-Option.
**Example**
Für Linux, macOS oder Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Für Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Exportieren von Abfragedaten mithilfe der Funktion aws\$1s3.query\$1export\$1to\$1s3
Exportieren Sie Ihre PostgreSQL-Daten nach Amazon S3, indem Sie die [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion aufrufen.
**Topics**
+ [Voraussetzungen](#postgresql-s3-export-examples-prerequisites)
+ [Aufruf von aws\$1s3.query\$1export\$1to\$1s3](#postgresql-s3-export-examples-basic)
+ [Exportieren in eine CSV-Datei, die ein benutzerdefiniertes Trennzeichen verwendet](#postgresql-s3-export-examples-custom-delimiter)
+ [Exportieren in eine Binärdatei mit Codierung](#postgresql-s3-export-examples-encoded)
## Voraussetzungen
Bevor Sie die `aws_s3.query_export_to_s3`-Funktion verwenden, müssen Sie die folgenden Voraussetzungen erfüllen:
+ Installieren Sie die erforderlichen PostgreSQL-Erweiterungen, wie unter beschriebe [Übersicht über das Exportieren von Daten zu Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Legen Sie fest, wohin die Daten nach Amazon S3 exportiert werden sollen, wie unter beschriebe [Angeben des Amazon S3-Dateipfads für den Export](postgresql-s3-export.md#postgresql-s3-export-file).
+ Stellen Sie sicher, dass die Exportzugriff auf Amazon S3 hat (wie unter [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](postgresql-s3-export-access-bucket.md) beschrieben).
In den folgenden Beispielen wird eine Datenbanktabelle namens verwende `sample_table`. In diesen Beispielen werden die Daten in einen Bucket namens exportier *amzn-s3-demo-bucket*. Die Beispieltabelle und die Daten werden mit den folgenden SQL-Anweisungen in psql erstellt.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Aufruf von aws\$1s3.query\$1export\$1to\$1s3
Im Folgenden werden die grundlegenden Möglichkeiten zum Aufrufen der [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion dargestellt.
In diesen Beispielen wird die Variable `s3_uri_1` zum Identifizieren einer Struktur verwendet, die die Informationen zur Identifizierung der Amazon S3-Datei enthält. Verwenden Sie die Funktion [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri), um die Struktur zu erstellen.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Obwohl die Parameter für die folgenden zwei `aws_s3.query_export_to_s3`-Funktionsaufrufe unterschiedlich sind, sind die Ergebnisse für diese Beispiele identisch. Alle Zeilen der `sample_table`-Tabelle werden in einen Bucket namens *amzn-s3-demo-bucket* exportiert.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
Die Parameter werden wie folgt beschrieben:
+ `'SELECT * FROM sample_table'` – Der erste Parameter ist eine erforderliche Textzeichenfolge, die eine SQL-Abfrage enthält. Die PostgreSQL-Engine führt diese Abfrage aus. Die Ergebnisse der Abfrage werden in den S3-Bucket kopiert, der in anderen Parametern identifiziert wurde.
+ `:'s3_uri_1'` – Dieser Parameter ist eine Struktur, die die Datei Amazon S3 identifiziert. In diesem Beispiel wird die zuvor erstellte Struktur anhand einer Variablen identifiziert. Sie können die Struktur stattdessen erstellen, indem Sie den Funktionsaufruf `aws_commons.create_s3_uri` wie folgt inline in den Funktionsaufruf `aws_s3.query_export_to_s3` einschließen.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` – Der `options`-Parameter ist eine optionale Textzeichenfolge, die `COPY`-PostgreSQL-Argumente enthält. Beim Kopiervorgang werden die Argumente und das Format des [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html)-Befehls verwendet.
Wenn die angegebene Datei nicht im Amazon S3-Bucket vorhanden ist, wird sie erstellt. Wenn die Datei bereits vorhanden ist, wird sie überschrieben. Die Syntax für den Zugriff auf die exportierten Daten in Amazon S3 ist die folgende.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Größere Exporte werden in mehreren Dateien gespeichert, jeweils mit einer maximalen Größe von ca. 6 GB. Die zusätzlichen Dateinamen haben das gleiche Dateipräfix, aber mit `_partXX` angefügt. `XX` stellt 2, dann 3 usw. dar. Angenommen, Sie geben den Pfad, in dem Sie Datendateien speichern, wie folgt an.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
Wenn der Export drei Datendateien anlegen muss, enthält der Amazon S3-Bucket die folgenden Datendateien.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
Die vollständige Referenz für diese Funktion und weitere Aufrufmöglichkeiten finden Sie unter [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Weitere Informationen zum Zugriff auf Dateien in Amazon S3 finden Sie unter [View an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) im *Amazon Simple Storage Service User Guide.*
## Exportieren in eine CSV-Datei, die ein benutzerdefiniertes Trennzeichen verwendet
Das folgende Beispiel zeigt, wie die [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion zum Exportieren von Daten in eine Datei aufgerufen wird, die ein benutzerdefiniertes Trennzeichen verwendet. Im Beispiel werden Argumente des Befehls [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) verwendet, um das CSV-Dateiformat (durch Kommas getrennte Werte) und ein Doppelpunkt (:)-Trennzeichen anzugeben.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Exportieren in eine Binärdatei mit Codierung
Das folgende Beispiel zeigt, wie die [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)-Funktion zum Exportieren von Daten in eine Binärdatei mit Windows-1253-Codierung aufgerufen wird.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Funktionsreferenz
**Topics**
+ [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3)
+ [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Exportiert ein PostgreSQL-Abfrageergebnis in einen Amazon S3-Bucket. Die Erweiterung `aws_s3` stellt die Funktion `aws_s3.query_export_to_s3` bereit.
Die zwei erforderlichen Parameter sind `query` und `s3_info`. Diese definieren die zu exportierende Abfrage und identifizieren den Amazon S3-Bucket, in den exportiert werden soll. Ein optionaler Parameter namens `options` ermöglicht die Definition verschiedener Exportparameter. Beispiele für die Verwendung der `aws_s3.query_export_to_s3`-Funktion finden Sie unter [Exportieren von Abfragedaten mithilfe der Funktion aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
**Syntax**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Eingabeparameter
*query*
Eine erforderliche Textzeichenfolge, die eine SQL-Abfrage enthält, die von der PostgreSQL-Engine ausgeführt wird. Die Ergebnisse dieser Abfrage werden in einen S3-Bucket kopiert, der im `s3_info`-Parameter identifiziert wurde.
*s3\$1info*
Ein zusammengesetzter `aws_commons._s3_uri_1`-Typ mit den folgenden Informationen zum S3-Objekt:
+ `bucket` – Der Name des Amazon S3-Buckets, der die Datei enthalten soll.
+ `file_path` – Der Amazon S3-Dateiname und der -Pfad.
+ `region`— Die AWS Region, in der sich der Bucket befindet. Eine Liste der AWS Regionsnamen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
Derzeit muss dieser Wert dieselbe AWS Region wie die der exportierenden sein. Die Standardeinstellung ist die AWS Region der exportierenden .
Informationen zum Erstellen einer zusammengesetzten `aws_commons._s3_uri_1`-Struktur finden Sie in der [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri)-Funktion.
*options*
Eine optionale Textzeichenfolge mit Argumenten für den PostgreSQL `COPY`-Befehl. Diese Argumente geben an, wie die Daten beim Exportieren kopiert werden sollen. Weitere Informationen finden Sie in der [PostgreSQL COPY-Dokumentation](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Eine optionale Textzeichenfolge, die den vom Kunden verwalteten KMS-Schlüssel des S3-Buckets enthält, in den die Daten exportiert werden sollen.
### Alternative Eingabeparameter
Zum Testen können Sie statt des Parameters `s3_info` eine erweiterte Gruppe von Parametern verwenden. Nachfolgend sind weitere Syntaxvariationen für die Funktion `aws_s3.query_export_to_s3` aufgeführt.
Statt den Parameter `s3_info` zum Identifizieren einer Amazon S3-Datei zu verwenden, nutzen Sie die Kombination aus den Parametern `bucket`, `file_path` und `region`.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
Eine erforderliche Textzeichenfolge, die eine SQL-Abfrage enthält, die von der PostgreSQL-Engine ausgeführt wird. Die Ergebnisse dieser Abfrage werden in einen S3-Bucket kopiert, der im `s3_info`-Parameter identifiziert wurde.
*bucket*
Eine erforderliche Textzeichenfolge mit dem Namen des Amazon S3-Buckets, der die Datei enthält.
*file\$1path*
Eine erforderliche Textzeichenfolge, die den Amazon S3-Dateinamen einschließlich des Pfads der Datei enthält.
*Region*
Eine optionale Textzeichenfolge, die die AWS Region enthält, in der sich der Bucket befindet. Eine Liste der AWS Regionsnamen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
Derzeit muss dieser Wert dieselbe AWS Region wie die der exportierenden sein. Die Standardeinstellung ist die AWS Region der exportierenden .
*options*
Eine optionale Textzeichenfolge mit Argumenten für den PostgreSQL `COPY`-Befehl. Diese Argumente geben an, wie die Daten beim Exportieren kopiert werden sollen. Weitere Informationen finden Sie in der [PostgreSQL COPY-Dokumentation](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Eine optionale Textzeichenfolge, die den vom Kunden verwalteten KMS-Schlüssel des S3-Buckets enthält, in den die Daten exportiert werden sollen.
### Ausgabeparameter
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
Die Anzahl der Tabellenzeilen, die für die angegebene Abfrage erfolgreich in Amazon S3 hochgeladen wurden.
*files\$1uploaded*
Die Anzahl der in Amazon S3 hochgeladenen Dateien. Dateien werden in Größen von ca. 6 GB erstellt. Jeder weiteren erstellten Datei wird `_partXX` an den Namen angehängt. `XX` stellt 2, dann 3 usw. nach Bedarf dar.
*bytes\$1uploaded*
Die Gesamtanzahl der in Amazon S3 hochgeladenen Bytes.
### Beispiele
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Erstellt eine `aws_commons._s3_uri_1`-Struktur für die Amazon S3-Dateiinformationen. Die Ergebnisse der Funktion `aws_commons.create_s3_uri` werden im Parameter `s3_info` der Funktion [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3) verwendet. Ein Beispiel für die Verwendung der `aws_commons.create_s3_uri`-Funktion finden Sie unter [Angeben des Amazon S3-Dateipfads für den Export](postgresql-s3-export.md#postgresql-s3-export-file).
**Syntax**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Eingabeparameter
*bucket*
Eine erforderliche Textzeichenfolge mit dem Namen des Amazon S3-Buckets für die Datei.
*file\$1path*
Eine erforderliche Textzeichenfolge, die den Amazon S3-Dateinamen einschließlich des Pfads der Datei enthält.
*Region*
Eine erforderliche Textzeichenfolge, die die AWS Region enthält, in der sich die Datei befindet. Eine Liste der AWS Regionsnamen und der zugehörigen Werte finden Sie unter[Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
# Fehlerbehebung beim Zugriff auf Amazon S3
Wenn beim Versuch, Daten nach Amazon S3 zu exportieren, Verbindungsprobleme auftreten, bestätigen Sie zunächst, dass die Regeln für den ausgehenden Zugriff für die mit Ihrer DB-Instance verknüpfte VPC-Sicherheitsgruppe Netzwerkkonnektivität zulassen. Insbesondere muss die Sicherheitsgruppe über eine Regel verfügen, die es der DB-Instance erlaubt, TCP-Datenverkehr über Port 443 und an eine beliebige IPv4-Adresse (0.0.0.0/0) zu senden. Weitere Informationen finden Sie unter [Ermöglichen des Zugriffs auf Ihre DB-Instance in der VPC durch Erstellen einer Sicherheitsgruppe](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Empfehlungen finden Sie im Folgenden:
+ [Fehlerbehebung für Amazon RDS-Identität und -Zugriff](security_iam_troubleshoot.md)
+ [Fehlerbehebung bei Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) im *Entwicklerhandbuch für Amazon Simple Storage Service*
+ [Fehlerbehebung bei Amazon S3 und IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) im *IAM-Benutzerhandbuch*
# Aufrufen einer AWS Lambda Funktion aus einem )
AWS Lambda ist ein ereignisgesteuerter Rechendienst, mit dem Sie Code ausführen können, ohne Server bereitstellen oder verwalten zu müssen. Es ist für die Verwendung mit vielen AWS Diensten verfügbar, einschließlich . Sie können beispielsweise Lambda-Funktionen verwenden, um Ereignisbenachrichtigungen aus einer Datenbank zu verarbeiten oder Daten aus Dateien zu laden, wann immer eine neue Datei in Amazon S3 hochgeladen wird. Weitere Informationen zu Lambda finden Sie unter [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) im *AWS Lambda Entwicklerhandbuch*.
**Anmerkung**
Das Aufrufen einer AWS Lambda Funktion wird in den folgenden RDS-Versionen für PostgreSQL unterstützt:
Alle PostgreSQL 18-Versionen
Alle PostgreSQL 17-Versionen
Alle PostgreSQL 16-Versionen
Alle PostgreSQL 15-Versionen
PostgreSQL 14.1 und höhere Unterversionen
PostgreSQL 13.2 und höhere Unterversionen
PostgreSQL 12.6 und höhere Unterversionen
Die Einrichtung von für die Arbeit mit Lambda-Funktionen ist ein mehrstufiger Prozess, der IAM AWS Lambda, Ihre VPC und Ihre umfasst. Im Folgenden finden Sie Zusammenfassungen der notwendigen Schritte.
Weitere Informationen über Lambda-Funktionen finden Sie unter [Erste Schritte mit Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) und [Grundlagen von AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) im *AWS Lambda -Entwicklerhandbuch*.
**Topics**
+ [Schritt 1: Konfigurieren Sie Ihren für ausgehende Verbindungen zu AWS Lambda](#PostgreSQL-Lambda-network)
+ [Schritt 2: Konfigurieren Sie IAM für Ihren und AWS Lambda](#PostgreSQL-Lambda-access)
+ [Schritt 3: Installieren Sie die `aws_lambda` Erweiterung für eine](#PostgreSQL-Lambda-install-extension)
+ [Schritt 4: Verwenden von Lambda-Hilfsfunktionen mit Ihrer RDS-for-PostgreSQL-DB-Instance (optional)](#PostgreSQL-Lambda-specify-function)
+ [Schritt 5: Aufrufen einer Lambda-Funktion von Ihrem RDS-for-PostgreSQL-DB-Instance](#PostgreSQL-Lambda-invoke)
+ [Schritt 6: Erteilen der Berechtigung, Lambda-Funktionen aufzurufen, für andere Benutzer](#PostgreSQL-Lambda-grant-users-permissions)
+ [Beispiele: Aufrufen von Lambda-Funktionen von Ihrer RDS-for-PostgreSQL-DB-Instance](PostgreSQL-Lambda-examples.md)
+ [Fehlermeldungen von Lambda-Funktionen](PostgreSQL-Lambda-errors.md)
+ [Referenz für AWS Lambda-Funktionen und -Parameter](PostgreSQL-Lambda-functions.md)
## Schritt 1: Konfigurieren Sie Ihren für ausgehende Verbindungen zu AWS Lambda
Lambda-Funktionen werden immer in einer Amazon-VPC ausgeführt, die dem AWS Lambda Service gehört. Lambda wendet Netzwerkzugriffs- und Sicherheitsregeln auf diese VPC an und pflegt und überwacht die VPC automatisch. Ihre DB-Instance von RDS für PostgreSQL muss Netzwerkdatenverkehr an die VPC des Lambda-Services senden. Wie Sie dies konfigurieren, hängt davon ab, ob die primäre DB-Instance Ihres öffentlich oder privat ist.
+ **Öffentlicher RDS für PostgreSQL-DB-Instance** — ist öffentlich, wenn sie sich in einem öffentlichen Subnetz auf Ihrer VPC befindet und wenn die Eigenschaft "" der Instance lautet. PubliclyAccessible `true` Um den Wert dieser Eigenschaft zu ermitteln, können Sie den Befehl verwenden. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI Alternativ können Sie über die AWS-Managementkonsole die Registerkarte **Connectivity & security** (Konnektivität und Sicherheit) öffnen und prüfen, ob **Publicly accessible** (Öffentlich zugänglich) auf **Yes** (Ja) eingestellt ist. Wenn Sie überprüfen möchten, ob sich die Instance im öffentlichen Subnetz Ihrer VPC befindet, können Sie die AWS-Managementkonsole oder die AWS CLI verwenden.
Um den Zugriff auf Lambda einzurichten, verwenden Sie AWS-Managementkonsole oder, AWS CLI um eine ausgehende Regel für die Sicherheitsgruppe Ihrer VPC zu erstellen. Die ausgehende Regel gibt an, dass TCP Port 443 verwenden kann, um Pakete an beliebige IPv4 Adressen (0.0.0.0/0) zu senden.
+ **Private RDS für PostgreSQL-DB-Instance** — In diesem Fall befindet sich die Eigenschaft "PubliclyAccessible" der Instance in einem privaten Subnetz `false` oder sie befindet sich in einem privaten Subnetz. Damit die Instance mit Lambda arbeiten kann, können Sie ein Network Address Translation (NAT)-Gateway verwenden. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Sie können Ihre VPC auch mit einem VPC-Endpunkt für Lambda konfigurieren. Weitere Informationen finden Sie unter [VPC-Endpunkte](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) im *Amazon-VPC-Benutzerhandbuch*. Der Endpunkt gibt Antworten auf Aufrufe Ihrer Lambda-Funktionen von Ihrer DB-Instance von RDS für PostgreSQL zurück. Der VPC-Endpunkt verwendet seine eigene private DNS-Auflösung. RDS für PostgreSQL kann den Lambda-VPC-Endpunkt erst verwenden, wenn Sie den Wert von `rds.custom_dns_resolution` von seinem Standardwert 0 (nicht aktiviert) zu 1 ändern. Gehen Sie hierzu wie folgt vor:
+ Erstellen Sie eine benutzerdefinierte DB-Parametergruppe.
+ Ändern Sie den Wert des Parameters `rds.custom_dns_resolution` von seinem Standardwert `0` zu `1`.
+ Ändern Sie Ihre DB-Instance, um Ihre benutzerdefinierte DB-Parametergruppe zu verwenden.
+ Starten Sie die DB-Instance neu, damit der bearbeitete Parameter in Kraft tritt.
Ihre VPC kann jetzt auf Netzwerkebene mit der AWS Lambda VPC interagieren. Als Nächstes konfigurieren Sie die Berechtigungen mithilfe von IAM.
## Schritt 2: Konfigurieren Sie IAM für Ihren und AWS Lambda
Das Aufrufen von Lambda-Funktionen von Ihrer RDS-for-PostgreSQL-DB-Instance erfordert bestimmte Berechtigungen. Um die erforderlichen Berechtigungen zu konfigurieren, empfehlen wir Ihnen, eine IAM-Richtlinie zu erstellen, die es ermöglicht, Lambda-Funktionen aufzurufen, diese Richtlinie einer Rolle zuzuweisen und die Rolle dann auf Ihre DB-Instance anzuwenden. Dieser Ansatz gewährt der DB-Instance Berechtigungen zum Aufrufen der angegebenen Lambda-Funktion in Ihrem Namen. Nachfolgend wird beschrieben, wie Sie dazu die AWS CLI verwenden können.
**IAM-Berechtigungen für die Verwendung Ihrer Amazon-RDS-Instance mit Lambda konfigurieren**
1. Verwenden Sie den AWS CLI Befehl [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html), um eine IAM-Richtlinie zu erstellen, die es Ihrer ermöglicht, die angegebene Lambda-Funktion aufzurufen. (Die Anweisungs-ID (Sid) ist eine optionale Beschreibung für Ihre Richtlinienanweisung und hat keine Auswirkungen auf die Verwendung.) Diese Richtlinie gewährt Ihrer DB-Instance die Mindestberechtigungen zum Aufrufen der angegebenen Lambda-Funktion.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Alternativ können Sie die vordefinierte `AWSLambdaRole`-Richtlinie verwenden, mit der Sie alle Ihre Lambda-Funktionen aufrufen können. Weitere Informationen finden Sie unter [Identitätsbasierte IAM-Richtlinien für Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed).
1. Verwenden Sie den AWS CLI Befehl [create-role, um eine IAM-Rolle](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) zu erstellen, die die Richtlinie zur Laufzeit annehmen kann.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Wenden Sie die Richtlinie mithilfe des Befehls auf die Rolle an. [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) AWS CLI
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. AWS CLI Dieser letzte Schritt erlaubt den Datenbankbenutzern Ihrer DB-Instances, Lambda-Funktionen aufzurufen.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Wenn die VPC- und die IAM-Konfigurationen abgeschlossen sind, können Sie jetzt die `aws_lambda`-Erweiterung installieren. (Beachten Sie, dass Sie die Erweiterung jederzeit installieren können, bis Sie jedoch die richtige VPC-Unterstützung und IAM-Berechtigungen eingerichtet haben, hat die `aws_lambda`-Erweiterung keinerlei Auswirkungen auf die Funktionen Ihrer RDS-for-PostgreSQL-DB-Instances.)
## Schritt 3: Installieren Sie die `aws_lambda` Erweiterung für eine
Zur Verwendung AWS Lambda mit Ihrem fügen Sie die PostgreSQL-Erweiterung zu Ihrem DB-Instance hinzu. Diese Erweiterung bietet Ihrer RDS-for-PostgreSQL-DB-Instance die Möglichkeit, Lambda-Funktionen von PostgreSQL aus aufzurufen.
**So installieren Sie die `aws_lambda` Erweiterung in Ihrem )**
Verwenden Sie die PostgreSQL-`psql`-Befehlszeile oder das pgAdmin-Tool, um Ihre RDS-for-PostgreSQL-DB-Instance zu verbinden.
1. Verbinden Sie Ihren Ihre RDS-for-PostgreSQL-DB-Instance als Benutzer mit `rds_superuser`-Berechtigungen. Im Beispiel wird der `postgres`-Standardbenutzer dargestellt.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Installieren Sie die `aws_lambda`-Erweiterung. Die `aws_commons`-Erweiterung ist auch erforderlich. Sie bietet Hilfsfunktionen für `aws_lambda` und viele andere Aurora-Erweiterungen für PostgreSQL. Wenn Sie noch nicht auf Ihrer RDS-for-PostgreSQL-DB-Instance installiert ist, wird sie mit `aws_lambda` wie folgt installiert.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
Die `aws_lambda`-Erweiterung wird in Ihrer DB-Instance installiert. Sie können jetzt praktische Strukturen für den Aufruf Ihrer Lambda-Funktionen erstellen.
## Schritt 4: Verwenden von Lambda-Hilfsfunktionen mit Ihrer RDS-for-PostgreSQL-DB-Instance (optional)
Sie können die Hilfsfunktionen in der `aws_commons`-Erweiterung verwenden, um Entitäten vorzubereiten, die sich einfacher über PostgreSQL aufrufen lassen. Hierzu sind die folgenden Informationen zu Ihren Lambda-Funktionen erforderlich:
+ **Funktionsname** – Der Name, der Amazon-Ressourcenname (ARN), die Version oder der Alias der Lambda-Funktion. Die in [Schritt 2: Konfigurieren von IAM für Ihre Instance und Lambda](#PostgreSQL-Lambda-access) erstellte IAM-Richtlinie benötigt den ARN, daher empfehlen wir Ihnen, den ARN Ihrer Funktion zu verwenden.
+ **AWS Region** — (Optional) Die AWS Region, in der sich die Lambda-Funktion befindet, falls sie sich nicht in derselben Region wie Ihre befindet.
Um die Daten zum Lambda-Funktionsnamen zu speichern, verwenden Sie die [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn)-Funktion. Diese Hilfsfunktion erstellt eine zusammengesetzte `aws_commons._lambda_function_arn_1`-Struktur mit den Details, die von der Aufruffunktion benötigt werden. Im Folgenden finden Sie drei alternative Ansätze zum Einrichten dieser zusammengesetzten Struktur.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
Jeder dieser Werte kann in Aufrufen der [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)-Funktion verwendet werden. Beispiele finden Sie unter [Schritt 5: Aufrufen einer Lambda-Funktion von Ihrem RDS-for-PostgreSQL-DB-Instance](#PostgreSQL-Lambda-invoke).
## Schritt 5: Aufrufen einer Lambda-Funktion von Ihrem RDS-for-PostgreSQL-DB-Instance
Die `aws_lambda.invoke`-Funktion verhält sich synchron oder asynchron, je nach `invocation_type`. Die beiden Alternativen für diesen Parameter sind `RequestResponse` (der Standardwert) und `Event`, wie folgt.
+ **`RequestResponse`** – Dieser Aufrufstyp ist *synchron*. Dies ist das Standardverhalten, wenn der Aufruf erfolgt, ohne einen Aufruftyp anzugeben. Die Antwort-Nutzlast beinhaltet die Ergebnisse der `aws_lambda.invoke`-Funktion. Verwenden Sie diesen Aufruftyp, wenn Ihr Workflow Ergebnisse von der Lambda-Funktion erhalten muss, bevor er fortfährt.
+ **`Event`** – Dieser Aufrufstyp ist *asynchron*. Die Antwort umfasst keine Nutzlast, die Ergebnisse enthält. Verwenden Sie diesen Aufruftyp, wenn Ihr Workflow kein Ergebnis der Lambda-Funktion benötigt, um die Verarbeitung fortzusetzen.
Als einfacher Test Ihres Setups können Sie mittels `psql` eine Verbindung mit Ihrer DB-Instance herstellen und eine Beispielfunktion über die Befehlszeile aufrufen. Angenommen, Sie haben eine der Grundfunktionen Ihres Lambda-Services eingerichtet, z. B. die einfache Python-Funktion, die im folgenden Screenshot gezeigt wird.
![\[Beispiel für eine Lambda-Funktion, die AWS CLI im for gezeigt wird AWS Lambda\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Beispielfunktion aufrufen**
1. Stellen Sie per `psql` oder pgAdmin eine Verbindung zu Ihrer DB-Instance her.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Rufen Sie die Funktion mit ihrem ARN auf.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
Die Antwort sieht wie folgt aus.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Schlägt der Aufruf fehl, siehe [Fehlermeldungen von Lambda-Funktionen](PostgreSQL-Lambda-errors.md).
## Schritt 6: Erteilen der Berechtigung, Lambda-Funktionen aufzurufen, für andere Benutzer
An dieser Stelle in den Prozeduren können nur Sie als `rds_superuser` Ihre Lambda-Funktionen aufrufen. Damit andere Benutzer alle von Ihnen erstellten Funktionen aufrufen können, müssen Sie ihnen die entsprechende Berechtigung erteilen.
**Gewähren der Berechtigung zum Aufrufen von Lambda-Funktionen**
1. Stellen Sie per `psql` oder pgAdmin eine Verbindung zu Ihrer DB-Instance her.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Führen Sie die folgenden SQL-Befehle aus:
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Beispiele: Aufrufen von Lambda-Funktionen von Ihrer RDS-for-PostgreSQL-DB-Instance
Nachfolgend finden Sie einige Beispiele für den Aufruf der [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)-Funktion. Die meisten Beispiele verwenden die Verbundstruktur `aws_lambda_arn_1`, die Sie in [Schritt 4: Verwenden von Lambda-Hilfsfunktionen mit Ihrer RDS-for-PostgreSQL-DB-Instance (optional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) erstellen, um die Übergabe der Funktionsdetails zu vereinfachen. Ein Beispiel für einen asynchronen Aufruf finden Sie unter [Beispiel: Asynchroner Ereignisaufruf (Event) von Lambda-Funktionen](#PostgreSQL-Lambda-Event). Alle anderen aufgelisteten Beispiele verwenden einen synchronen Aufruf.
Weitere Informationen zu Lambda-Aufruftypen finden Sie unter [Aufrufen von Lambda-Funktionen](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) im *AWS Lambda -Entwicklerhandbuch*. Mehr über `aws_lambda_arn_1` erfahren Sie unter [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [Beispiel: Synchroner (RequestResponse) -Aufruf von Lambda-Funktionen](#PostgreSQL-Lambda-RequestResponse)
+ [Beispiel: Asynchroner Ereignisaufruf (Event) von Lambda-Funktionen](#PostgreSQL-Lambda-Event)
+ [Beispiel: Erfassen des Lambda-Ausführungsprotokolls in einer Funktionsantwort](#PostgreSQL-Lambda-log-response)
+ [Beispiel: Einschließen von Client-Kontext in einer Lambda-Funktion](#PostgreSQL-Lambda-client-context)
+ [Beispiel: Aufrufen einer bestimmten Version einer Lambda-Funktion](#PostgreSQL-Lambda-function-version)
## Beispiel: Synchroner (RequestResponse) -Aufruf von Lambda-Funktionen
Es folgen zwei Beispiele für einen synchronen Lambda-Funktionsaufruf. Die Ergebnisse dieser `aws_lambda.invoke`-Funktionen sind identisch.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Die Parameter werden wie folgt beschrieben:
+ `:'aws_lambda_arn_1'` – Dieser Parameter identifiziert die zusammengesetzte Struktur, die in [Schritt 4: Verwenden von Lambda-Hilfsfunktionen mit Ihrer RDS-for-PostgreSQL-DB-Instance (optional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) erstellt wurde, mit der `aws_commons.create_lambda_function_arn`-Hilfsfunktion. Sie können diese Struktur wie folgt auch in Ihren `aws_lambda.invoke`-Aufruf einbinden.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` – Die JSON-Nutzlast, die an die Lambda-Funktion übergeben werden soll.
+ `'RequestResponse'` – Der Lambda Aufruftyp.
## Beispiel: Asynchroner Ereignisaufruf (Event) von Lambda-Funktionen
Es folgt ein Beispiel für einen asynchronen Lambda-Funktionsaufruf. Der `Event`-Aufruftyp plant den Lambda-Funktionsaufruf mit der angegebenen Eingabe-Nutzlast und sofort Rückgabe. Verwenden Sie den `Event`-Aufruftyp in bestimmten Workflows, die nicht von den Ergebnissen der Lambda-Funktion abhängen.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Beispiel: Erfassen des Lambda-Ausführungsprotokolls in einer Funktionsantwort
Sie können die letzten 4 KB des Ausführungsprotokolls in die Funktionsantwort aufnehmen, indem Sie den Parameter `log_type` in Ihrem `aws_lambda.invoke`-Funktionsaufruf verwenden. Standardmäßig ist dieser Parameter auf `None` festgelegt, aber Sie können `Tail` angeben, um die Ergebnisse des Lambda-Ausführungsprotokolls in der Antwort zu erfassen, wie nachfolgend gezeigt.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Legen Sie den Parameter [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) der `log_type`-Funktion auf `Tail`, um das Ausführungsprotokoll in die Antwort aufzunehmen. Der Standardwert für diesen `log_type`-Parameter ist `None`.
Das `log_result`, was zurückgegeben wird, ist eine `base64` codierte Zeichenfolge. Sie können den Inhalt mit einer Kombination der PostgreSQL-Funktionen `decode` und `convert_from` dekodieren.
Mehr über `log_type` erfahren Sie unter [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Beispiel: Einschließen von Client-Kontext in einer Lambda-Funktion
Die `aws_lambda.invoke`-Funktion hat einen `context`-Parameter, den Sie verwenden können, um Informationen getrennt von der Nutzlast zu übergeben, wie nachfolgend gezeigt.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Um den Clientkontext einzuschließen, verwenden Sie ein JSON-Objekt für den Parameter [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) der `context`-Funktion.
Weitere Informationen zum `context`-Parameter finden Sie in der [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)-Referenz.
## Beispiel: Aufrufen einer bestimmten Version einer Lambda-Funktion
Sie können eine bestimmte Version einer Lambda-Funktion angeben, indem Sie den `qualifier`-Parameter mit dem `aws_lambda.invoke`-Aufruf einschließen. Im Folgenden finden Sie ein Beispiel, das diese Funktion mit `'custom_version'` als Alias für die Version erfüllt.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Sie können auch einen Lambda-Funktionsqualifizierer wie folgt mit den Daten zum Funktionsnamen angeben.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Weitere Informationen zu `qualifier` und anderen Parametern finden Sie in der [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)-Referenz.
# Fehlermeldungen von Lambda-Funktionen
In der folgenden Liste finden Sie Informationen zu Fehlermeldungen sowie mögliche Ursachen und Lösungen.
+ **VPC-Konfigurationsprobleme**
Probleme mit der VPC-Konfiguration können beim Versuch, eine Verbindung herzustellen, die folgenden Fehlermeldungen auslösen:
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Eine häufige Ursache für diesen Fehler ist eine falsch konfigurierte VPC-Sicherheitsgruppe. Stellen Sie sicher, dass eine Regel Port 443 Ihrer VPC-Sicherheitsgruppe für ausgehenden TCP-Datenverkehr öffnet, damit Ihre VPC eine Verbindung zur Lambda-VPC herstellen kann.
Wenn Ihre DB-Instance privat ist, überprüfen Sie das private DNS-Setup für Ihre VPC. Stellen Sie sicher, dass Sie den `rds.custom_dns_resolution` Parameter auf 1 setzen und die Einrichtung AWS PrivateLink wie unter beschrieben durchführen[Schritt 1: Konfigurieren Sie Ihren für ausgehende Verbindungen zu AWS Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Weitere Informationen finden Sie unter [Interface VPC Endpoints ()AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns).
+ **Fehlende Berechtigungen, die zum Aufrufen von Lambda-Funktionen erforderlich sind**
Wenn eine der folgenden Fehlermeldungen angezeigt wird, verfügt der Benutzer (Rolle), der die Funktion aufruft, nicht über die entsprechenden Berechtigungen.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Ein Benutzer (Rolle) muss bestimmte Berechtigungen erhalten, um Lambda-Funktionen aufrufen zu können. Weitere Informationen finden Sie unter [Schritt 6: Erteilen der Berechtigung, Lambda-Funktionen aufzurufen, für andere Benutzer](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Unsachgemäße Handhabung von Fehlern in Ihren Lambda-Funktionen**
Wenn eine Lambda-Funktion während der Anforderungsverarbeitung eine Ausnahme auslöst, `aws_lambda.invoke` schlägt dies mit einem PostgreSQL-Fehler wie folgt fehl.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Kümmern Sie sich unbedingt um Fehler in Ihren Lambda-Funktionen oder in Ihrer PostgreSQL-Anwendung.
# Referenz für AWS Lambda-Funktionen und -Parameter
Im Folgenden finden Sie die Referenz für die Funktionen, die zum Aufrufen von Lambda-Funktionen mit RDS für PostgreSQL verwendet werden müssen.
**Topics**
+ [aws\$1lambda.invoke](#aws_lambda.invoke)
+ [aws\$1commons.create\$1lambda\$1function\$1arn](#aws_commons.create_lambda_function_arn)
+ [aws\$1lambda-Parameter](#aws_lambda.parameters)
## aws\$1lambda.invoke
Führt eine Lambda-Funktion für eine für PostgreSQL-DB-Instance aus.
Weitere Informationen zum Aufrufen von Lambda-Funktionen finden Sie unter [Invoke (Aufrufen)](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) auch im *AWS Lambda-Entwicklerhandbuch.*
**Syntax**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Eingabeparameter
**function\$1name**
Der spezifizierte Name der Lambda-Funktion. Der Wert kann der Funktionsname, ein ARN oder ein partieller ARN sein. Eine Auflistung möglicher Formate finden Sie unter [ Lambda Funktionsnamenformate](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) im *AWS Lambda-Entwicklerhandbuch. *
*Nutzlast*
Die Eingabe für die Funktion Lambda. Das Format kann JSON oder JSONB sein. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [JSON Types](https://www.postgresql.org/docs/current/datatype-json.html).
*region*
(Optional) Die Lambda-Region für die Funktion. Standardmäßig verwendet RDS die AWS-Region aus dem vollständigen ARN in der `function_name` oder die RDS für PostgreSQL-DB-Instance-Region. Wenn dieser Region-Wert mit dem im `function_name` ARN angegebenen Wert in Konflikt steht, wird ein Fehler ausgelöst.
*invocation\$1type*
Die Aufruftyp der Lambda-Funktion. Bei -Wert ist die Groß- und Kleinschreibung zu beachten. Die folgenden Werte sind möglich:
+ `RequestResponse` – Der Standardwert. Diese Art des Aufrufens für eine Lambda-Funktion ist synchron und gibt eine Antwortnutzlast im Ergebnis zurück. Verwenden Sie den `RequestResponse` Aufruftyp, wenn Ihr Workflow vom sofortigen Erhalt des Lambda-Funktionsergebnisses abhängt.
+ `Event` – Diese Art des Aufrufs für eine Lambda-Funktion ist asynchron und wird sofort ohne Rückgabe einer Nutzlast zurückgegeben. Verwenden Sie den `Event`-Aufruftyp, wenn Sie keine Ergebnisse der Lambda-Funktion benötigen, bevor Ihr Workflow weitergeht.
+ `DryRun` – Diese Art des Aufrufs testet den Zugriff, ohne die Lambda-Funktion auszuführen.
*log\$1typ*
Der Typ des Lambda-Protokolls, das im Ausgabeparameter `log_result` ausgegeben werden soll. Bei -Wert ist die Groß- und Kleinschreibung zu beachten. Die folgenden Werte sind möglich:
+ Tail – Der zurückgegebene Ausgabeparameter `log_result` enthält die letzten 4 KB des Ausführungsprotokolls.
+ Keiner – Es werden keine Lambda-Protokollinformationen zurückgegeben.
*context*
Client-Kontext im JSON- oder JSONB-Format. Zu verwendende Felder sind dann `custom` und `env`.
*Qualifier*
Ein Qualifier, der die aufzurufende Version einer Lambda-Funktion spezifiziert. Wenn dieser Wert mit einem im `function_name` ARN angegebenen Wert in Konflikt steht, wird ein Fehler ausgelöst.Ausgabeparameter
*status\$1code*
Ein HTTP-Status-Antwortcode. Weitere Informationen finden Sie unter [Lambda Antwortelemente aufrufen](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) im *AWS Lambda-Entwicklerhandbuch.*
*Nutzlast*
Die von der ausgeführten Lambda-Funktion zurückgegebenen Daten. Das Format ist in JSON oder JSONB.
*executed\$1version*
Die Version der Lambda-Funktion, die ausgeführt wurde.
*log\$1resultat*
Die Ausführungsprotokollinformationen werden zurückgegeben, wenn der Wert `log_type` beim Aufruf der Lambda-Funktion `Tail` beträgt. Das Ergebnis enthält die letzten 4 KB des in Base64 codierten Ausführungsprotokolls.
## aws\$1commons.create\$1lambda\$1function\$1arn
Erstellt eine `aws_commons._lambda_function_arn_1`-Struktur für Daten zum Lambda Funktionsnamen. Sie können die Ergebnisse der `aws_commons.create_lambda_function_arn`-Funktion im Parameter `function_name` der [aws\$1lambda.invoke](#aws_lambda.invoke)-Funktion aws\$1lambda.invoke verwenden.
**Syntax**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Eingabeparameter
*function\$1name*
Eine erforderliche Textzeichenfolge mit dem Lambda-Funktionsnamen. Der Wert kann ein Funktionsname, ein partieller ARN oder ein vollständiger ARN sein.
*region*
Eine optionale Textzeichenfolge mit der AWS-Region, in der sich die Lambda-Funktion befindet. Eine Liste der -Regionsnamen und der zugehörigen Werte finden Sie unter [Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1lambda-Parameter
In der Tabelle finden Sie Parameter, die der `aws_lambda`-Funktion zugeordnet sind.
| Parameter | Beschreibung |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | Dies ist ein dynamischer Parameter, der die maximale Wartezeit beim Herstellen einer Verbindung zu AWS Lambda festlegt. Der Standardwert ist `1000`. Die zulässigen Werte für diesen Parameter sind 1 bis 90000. |
| `aws_lambda.request_timeout_ms` | Dies ist ein dynamischer Parameter, der die maximale Wartezeit beim Warten auf eine Antwort von AWS Lambda festlegt. Der Standardwert ist `3000`. Die zulässigen Werte für diesen Parameter sind 1 bis 90000. |
| `aws_lambda.endpoint_override` | Gibt den Endpunkt an, der für die Verbindung mit AWS Lambda verwendet werden kann. Eine leere Zeichenfolge wählt den AWS-Lambda-Standardendpunkt für die Region aus. Sie müssen die Datenbank für diese Änderung des statischen Parameters neu starten, damit Änderungen wirksam werden. |
# Häufige DBA-Aufgaben für Amazon RDS für PostgreSQL
Datenbankadministratoren (DBAs) führen bei der Verwaltung einer Amazon RDS for PostgreSQL PostgreSQL-DB-Instance eine Vielzahl von Aufgaben aus. Wenn Sie als DBA bereits mit PostgreSQL vertraut sind, müssen Sie sich einige wichtige Unterschiede zwischen dem Ausführen von PostgreSQL auf Ihrer Hardware und RDS für PostgreSQL beachten. Da es sich beispielsweise um einen verwalteten Service handelt, lässt Amazon RDS keinen Shell-Zugriff auf Ihre DB-Instances zu. Das bedeutet, dass Sie keinen direkten Zugriff auf `pg_hba.conf` und andere Konfigurationsdateien haben. Bei RDS für PostgreSQL werden Änderungen, die normalerweise an der PostgreSQL-Konfigurationsdatei einer lokalen Instance vorgenommen werden, an einer benutzerdefinierten DB-Parametergruppe vorgenommen, die der DB-Instance von RDS für PostgreSQL zugeordnet ist. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Darüber hinaus können Sie nicht auf die gleiche Weise auf Protokolldateien zugreifen wie mit einer lokalen PostgreSQL-Instance. Weitere Informationen zur Protokollierung finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
Sie haben beispielsweise auch keinen Zugriff auf das `superuser`-Konto von PostgreSQL. Bei RDS für PostgreSQL ist die `rds_superuser`-Rolle diejenige mit den meisten Berechtigungen und wird `postgres` zum Zeitpunkt der Einrichtung gewährt. Unabhängig davon, ob Sie mit der On-Premises-Verwendung von PostgreSQL vertraut sind oder Neueinsteiger bei RDS für PostgreSQL sind, empfehlen wir Ihnen, sich mit der `rds_superuser`-Rolle und dem Umgang mit Rollen, Benutzern, Gruppen und Berechtigungen vertraut zu machen. Weitere Informationen finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Im Folgenden sind einige häufige DBA-Aufgaben für RDS für PostgreSQL aufgeführt.
**Topics**
+ [Kollationen, die in unterstützt werden](PostgreSQL-Collations.md)
+ [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Behandeln von inaktiven Verbindungen in PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL](PostgreSQL.HighObjectCount.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [Arbeiten mit Protokollierungsmechanismen, die von RDS für PostgreSQL unterstützt werden](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Verwalten temporärer Dateien mit PostgreSQL](PostgreSQL.ManagingTempFiles.md)
+ [Verwenden von pgBadger für die Protokollanalyse mit PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [PGSnapper Für die Überwachung von PostgreSQL verwenden](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [](PostgreSQL.CustomCasts.md)
+ [Bewährte Methoden für parallele Abfragen in](PostgreSQL.ParallelQueries.md)
+ [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Kollationen, die in unterstützt werden
Sortierungen sind eine Reihe von Regeln, die bestimmen, wie in der Datenbank gespeicherte Zeichenfolgen sortiert und verglichen werden. Sortierungen spielen eine grundlegende Rolle im Computersystem und sind Teil des Betriebssystems. Sortierungen ändern sich im Laufe der Zeit, wenn neue Zeichen zu Sprachen hinzugefügt werden oder wenn sich die Sortierregeln ändern.
Sortierungsbibliotheken definieren spezifische Regeln und Algorithmen für eine Sortierung. Die beliebtesten Sortierungsbibliotheken, die in PostgreSQL verwendet werden, sind GNU C (glibc) und Internationalization Components for Unicode (ICU). Standardmäßig verwendet RDS für PostgreSQL die Glibc-Sortierung, die Unicode-Zeichensortierreihenfolgen für Multibyte-Zeichensequenzen enthält.
Wenn Sie eine neue DB-Instance in RDS für PostgreSQL erstellen, wird das Betriebssystem auf die verfügbare Sortierung überprüft. Die PostgreSQL-Parameter des `CREATE DATABASE`-Befehls `LC_COLLATE` und `LC_CTYPE` werden verwendet, um eine Sortierung anzugeben, die in dieser Datenbank als Standardsortierung gilt. Alternativ können Sie auch den Parameter `LOCALE` in `CREATE DATABASE` verwenden, um diese Parameter festzulegen. Dieser bestimmt die Standardsortierung für Zeichenfolgen in der Datenbank und die Regeln für die Klassifizierung von Zeichen als Buchstaben, Zahlen oder Symbole. Sie können auch eine Sortierung auswählen, die für eine Spalte, einen Index oder eine Abfrage verwendet werden soll.
RDS für PostgreSQL benötigt für die Sortierungsunterstützung die Glibc-Bibliothek im Betriebssystem. Die Instance von RDS für PostgreSQL wird regelmäßig mit den neuesten Versionen des Betriebssystems aktualisiert. Diese Updates umfassen manchmal eine neuere Version der Glibc-Bibliothek. In seltenen Fällen ändern neuere Versionen von Glibc die Sortierreihenfolge oder Sortierung einiger Zeichen, was dazu führen kann, dass die Daten anders sortiert werden oder ungültige Indexeinträge entstehen. Wenn Sie während eines Updates bei der Sortierung Probleme mit der Sortierreihenfolge feststellen, müssen Sie möglicherweise die Indizes neu erstellen.
Damit mögliche Auswirkungen der Glibc-Updates reduziert werden, enthält RDS für PostgreSQL jetzt eine unabhängige Standard-Sortierungsbibliothek. Diese Sortierungsbibliothek ist in RDS für PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 und neueren Nebenversionen verfügbar. Sie ist mit Glibc 2.26-59.amzn2 kompatibel und bietet eine stabile Sortierreihenfolge, um falsche Abfrageergebnisse zu verhindern.
# Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen
Wenn Sie mit dem eine for PostgreSQL-DB-Instance erstellen AWS-Managementkonsole, wird gleichzeitig ein Administratorkonto erstellt. Der Name lautet standardmäßig `postgres`, wie im folgenden Screenshot gezeigt:
![\[Die Standardanmelde-Identität für Anmeldeinformationen auf der Seite Create database (Datenbank erstellen) lautet postgres.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Sie können einen anderen Namen auswählen, anstatt den Standard (`postgres`) beizubehalten. In diesem Fall muss der von Ihnen gewählte Name mit einem Buchstaben beginnen und zwischen 1 und 16 alphanumerische Zeichen umfassen. Der Einfachheit halber verwenden wir für das Hauptbenutzerkonto den Standardwert (`postgres`) in diesem Handbuch.
Wenn Sie den `create-db-instance` AWS CLI anstelle von verwenden, erstellen Sie den Namen AWS-Managementkonsole, indem Sie ihn zusammen mit dem `master-username` Parameter im Befehl übergeben. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
Unabhängig davon AWS-Managementkonsole, ob Sie die AWS CLI, oder die Amazon RDS-API verwenden und ob Sie den `postgres` Standardnamen verwenden oder einen anderen Namen wählen, ist dieses erste Datenbankbenutzerkonto Mitglied der `rds_superuser` Gruppe und verfügt über `rds_superuser` Berechtigungen.
**Topics**
+ [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Delegieren und Steuern der Benutzerpasswortverwaltung](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung](PostgreSQL_Password_Encryption_configuration.md)
# Die Rolle „rds\$1superuser“ verstehen
In PostgreSQL kann eine *Rolle* einen Benutzer, eine Gruppe oder einen Satz bestimmter Berechtigungen definieren, die einer Gruppe oder einem Benutzer für verschiedene Objekte in der Datenbank gewährt werden. PostgreSQL-Befehle für `CREATE USER` und `CREATE GROUP` wurden durch den allgemeineren Befehl `CREATE ROLE` mit bestimmten Eigenschaften zur Unterscheidung von Datenbankbenutzern ersetzt. Einen Datenbankbenutzer kann man sich als Rolle mit der LOGIN-Berechtigung vorstellen.
**Anmerkung**
Die Befehle `CREATE USER` und `CREATE GROUP` können weiterhin verwendet werden. Weitere Informationen dazu finden Sie im Abschnitt [Datenbankrollen](https://www.postgresql.org/docs/current/user-manag.html) der PostgreSQL-Dokumentation.
Der `postgres`-Benutzer ist der Datenbankbenutzer mit den meisten Berechtigungen auf Ihrer RDS-for-PostgreSQL-DB-Instance. Er verfügt über die Eigenschaften, die durch die folgende `CREATE ROLE`-Anweisung definiert sind.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Die Eigenschaften `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` und `VALID UNTIL 'infinity'` sind die Standardoptionen für CREATE ROLE, sofern nicht anders angegeben.
Standardmäßig verfügt `postgres` über Berechtigungen, die der `rds_superuser`-Rolle gewährt wurden, und über Berechtigungen zum Erstellen von Rollen und Datenbanken. Die `rds_superuser`-Rolle erlaubt dem `postgres`-Benutzer, folgende Aktionen auszuführen:
+ Erweiterungen für die Verwendung mit Amazon RDS hinzufügen. Weitere Informationen finden Sie unter [Arbeiten mit PostgreSQL-Funktionen, die von Amazon RDS für PostgreSQL unterstützt werden](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Rollen für Benutzer erstellen und Benutzern Berechtigungen gewähren. Weitere Informationen dazu finden Sie im Abschnitt [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) und [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) der PostgreSQL-Dokumentation.
+ Datenbanken erstellen. Weitere Informationen finden Sie im Abschnitt [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) der PostgreSQL-Dokumentation.
+ Gewähren Sie `rds_superuser`-Berechtigungen anderen Benutzerrollen, die nicht über diese Berechtigungen verfügen, und widerrufen Sie diese Berechtigungen bei Bedarf. Es wird empfohlen, diese Rolle nur denjenigen Benutzern zu gewähren, die Superuser-Aufgaben ausführen. Mit anderen Worten, Sie können diese Rolle Datenbankadministratoren (DBAs) oder Systemadministratoren zuweisen.
+ Die `rds_replication`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Die `rds_password`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Statusinformationen über alle Datenbankverbindungen über die Ansicht `pg_stat_activity` abrufen. Bei Bedarf kann `rds_superuser` alle Verbindungen mit `pg_terminate_backend` oder `pg_cancel_backend` stoppen.
In der `CREATE ROLE postgres...`-Anweisung können Sie sehen, dass die `postgres`-Benutzerrolle PostgreSQL ausdrücklich `superuser`-Berechtigungen verweigert. RDS für PostgreSQL ist ein verwalteter Service, sodass Sie nicht auf das Host-Betriebssystem zugreifen können und keine Verbindung mit dem `superuser`-PostgreSQL-Konto herstellen können. Viele der Aufgaben, die `superuser`-Zugriff auf einem eigenständigem PostgreSQL erfordern, werden von Amazon RDS automatisch verwaltet.
Weitere Informationen zum Gewähren von Berechtigungen finden Sie unter [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) in der PostgreSQL-Dokumentation.
Die `rds_superuser`-Rolle ist eine von mehreren *vordefinierten* Rollen in einem . DB-Instance von RDS für PostgreSQL
**Anmerkung**
In PostgreSQL 13 und früheren Versionen werden *vordefinierte Rollen* als *Standardrollen* bezeichnet.
In der folgenden Liste finden Sie einige der anderen vordefinierten Rollen, die automatisch für einen neuen erstellt werden. DB-Instance von RDS für PostgreSQL Vordefinierte Rollen und ihre Berechtigungen können nicht geändert werden. Sie können Berechtigungen für diese vordefinierten Rollen nicht löschen, umbenennen oder ändern. Jeder entsprechende Versuch führt zu einem Fehler.
+ **rds\$1passwort** – Eine Rolle, die Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer einrichten kann. Die `rds_superuser`-Rolle erhält diese Rolle standardmäßig und kann die Rolle Datenbankbenutzern gewähren. Weitere Informationen finden Sie unter [Steuern des Benutzerzugriffs auf die PostgreSQL−DatenbankSteuern des Benutzerzugriffs auf PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ In Versionen von RDS für PostgreSQL, die höher sind als 14, kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer und Benutzer mit der `rds_superuser`-Rolle einrichten. Ab Version 14 und höher von RDS für PostgreSQL kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen nur für Datenbankbenutzer einrichten. Nur Benutzer mit der `rds_superuser`-Rolle können diese Aktionen für andere Benutzer mit der `rds_superuser`-Rolle ausführen.
+ **rdsadmin** – Eine Rolle, die erstellt wurde, um viele der Verwaltungsaufgaben zu erledigen, die der Administrator mit `superuser`-Berechtigungen für eine eigenständige PostgreSQL-Datenbank ausführt. Diese Rolle wird intern von RDS für PostgreSQL für viele Verwaltungsaufgaben verwendet.
+ **rdstopmgr** – Eine Rolle, die intern von Amazon RDS zur Unterstützung von Multi-AZ-Bereitstellungen verwendet wird.
+ **rds\$1reserved** – Dies ist eine Rolle, die intern von Amazon RDS verwendet wird, um Datenbankverbindungen zu reservieren.
# Anzeigen von Rollen und deren Berechtigungen
Sie können vordefinierte Rollen und deren Berechtigungen in Ihrer DB-Instance von RDS für PostgreSQL je nach PostgreSQL-Version mit unterschiedlichen Befehlen anzeigen. Wenn Sie alle vordefinierten Rollen anzeigen möchten, können Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL herstellen und die folgenden Befehle mit `psql` ausführen.
**Für `psql` 15 und frühere Versionen**
Stellen Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL her und verwenden Sie den `\du`-Befehl in psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Für `psql` 16 und höhere Versionen**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Wenn Sie die Rollenmitgliedschaft ohne Versionsabhängigkeit überprüfen möchten, können Sie die folgende SQL-Abfrage verwenden:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
In der Ausgabe sehen Sie, dass `rds_superuser` keine Datenbankbenutzerrolle ist (sie kann sich nicht anmelden), aber über die Berechtigungen vieler anderer Rollen verfügt. Sie können auch sehen, dass dieser Datenbankbenutzer `postgres` Mitglied der `rds_superuser`-Rolle ist. Wie bereits erwähnt, ist `postgres` der Standardwert auf der Seite **Create database** (Datenbank erstellen) der Amazon-RDS-Konsole. Wenn Sie einen anderen Namen gewählt haben, wird dieser Name stattdessen in der Rollenliste angezeigt.
# Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank
Neue Datenbanken in PostgreSQL werden immer mit Standardberechtigungen im `public`-Schema der Datenbank erstellt, mit dem alle Datenbankbenutzer und -rollen Objekte erstellen können. Diese Berechtigungen ermöglichen es Datenbankbenutzern, eine Verbindung mit der Datenbank herzustellen und während der Verbindung temporäre Tabellen zu erstellen.
Es wird empfohlen, diese `public`-Standardberechtigungen zu widerrufen, um den Benutzerzugriff auf die Datenbank-Instances, die Sie auf Ihrer DB-Instance von RDS for PostgreSQL erstellen, besser kontrollieren können. Danach erteilen Sie Datenbankbenutzern auf einer detaillierteren Basis spezifische Berechtigungen, wie im Folgenden gezeigt.
**So richten Sie Rollen und Berechtigungen für eine neue Datenbank-Instance ein**
Angenommen, Sie richten eine Datenbank für eine neu erstellte DB-Instance von RDS for PostgreSQL ein, die von mehreren Forschenden verwendet wird, die alle Lese-/Schreibzugriff auf die Datenbank benötigen.
1. Verwenden Sie `psql` (oder pgAdmin) zum Herstellen einer Verbindung mit Ihrer DB-Instance von RDS for PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Geben Sie bei der Aufforderung Ihr Passwort ein. Der `psql`-Client verbindet und zeigt die standardmäßige administrative Verbindungsdatenbank `postgres=>` als Eingabeaufforderung an.
1. Gehen Sie wie folgt vor, um zu verhindern, dass Datenbankbenutzer Objekte im `public`-Schema erstellen:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Als Nächstes erstellen Sie eine neue Datenbank-Instance:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Widerrufen Sie alle Berechtigungen aus dem `PUBLIC`-Schema in dieser neuen Datenbank.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Erstellen Sie eine Rolle für Datenbankbenutzer.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Geben Sie Datenbankbenutzern mit dieser Rolle die Möglichkeit, eine Verbindung mit der Datenbank herzustellen.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Gewähren Sie allen Benutzern mit der `lab_tech`-Rolle alle Berechtigungen für diese Datenbank.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Erstellen Sie Datenbankbenutzer wie folgt:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Gewähren Sie diesen beiden Benutzern die Berechtigungen, die mit der lab\$1tech-Rolle verknüpft sind:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
An dieser Stelle können `lab_user1` und `lab_user2` eine Verbindung mit der `lab_db`-Datenbank herstellen. Dieses Beispiel folgt nicht den bewährten Methoden für den Unternehmensgebrauch, darunter das Erstellen mehrerer Datenbank-Instances, verschiedener Schemas und das Erteilen eingeschränkter Berechtigungen. Umfassende Informationen und zusätzliche Szenarien finden Sie unter [Verwalten von PostgreSQL-Benutzern und -Rollen](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Weitere Informationen zu Berechtigungen in PostgreSQL-Datenbanken finden Sie unter dem Befehl [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) in der PostgreSQL-Dokumentation.
# Delegieren und Steuern der Benutzerpasswortverwaltung
Als DBA sollten Sie ggf. die Verwaltung von Benutzerpasswörtern delegieren. Oder Sie möchten verhindern, dass Datenbankbenutzer ihre Passwörter ändern oder Passwortbeschränkungen wie die Lebensdauer des Passworts neu konfigurieren. Um sicherzustellen, dass nur die von Ihnen ausgewählten Datenbankbenutzer Passworteinstellungen ändern können, können Sie die Funktion zur eingeschränkten Passwortverwaltung aktivieren. Wenn Sie diese Funktion aktivieren, können nur die Datenbankbenutzer, denen die `rds_password`-Rolle gewährt wurde, Passwörter verwalten.
**Anmerkung**
Um die eingeschränkte Passwortverwaltung nutzen zu können, muss Ihre DB-Instance für RDS for PostgreSQL PostgreSQL 10.6 oder höher ausführen.
Standardmäßig lautet diese Funktion `off`, wie im Folgenden gezeigt:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Zum Aktivieren dieser Funktion verwenden Sie eine benutzerdefinierte Parametergruppe und ändern die Einstellung für `rds.restrict_password_commands` in 1. Stellen Sie sicher, dass Sie Ihre DB-Instance von RDS for PostgreSQL neu starten, damit die Einstellung wirksam wird.
Wenn diese Funktion aktiv ist, werden für die folgenden SQL-Befehle `rds_password`-Berechtigungen benötigt:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Das Umbenennen einer Rolle (`ALTER ROLE myrole RENAME TO newname`) ist ebenfalls eingeschränkt, wenn das Passwort den MD5 Hash-Algorithmus verwendet.
Wenn diese Funktion aktiv ist, generiert jeder Versuch, einen dieser SQL-Befehle ohne die `rds_password`-Rollenberechtigungen auszuführen, den folgenden Fehler:
```
ERROR: must be a member of rds_password to alter passwords
```
Wir empfehlen, dass Sie die `rds_password`-Berechtigung nur wenigen Rollen zuweisen, die Sie ausschließlich für die Passwortverwaltung verwenden. Wenn Sie `rds_password`-Berechtigungen für Datenbankbenutzer erteilen, die keine `rds_superuser`-Berechtigungen haben, müssen Sie ihnen auch das `CREATEROLE`-Attribut erteilen.
Stellen Sie sicher, dass Sie die Passwortanforderungen wie Ablaufdatum und erforderliche Komplexität auf Kundenseite überprüfen. Wenn Sie Ihr eigenes clientseitiges Dienstprogramm für passwortbezogene Änderungen verwenden, muss das Dienstprogramm Mitglied von `rds_password` sein und über `CREATE ROLE`-Berechtigungen verfügen.
# Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung
Der *Salted Challenge Response Authentication Mechanism (SCRAM)* ist eine Alternative zum standardmäßigen Message Digest (MD5) -Algorithmus von PostgreSQL zur Verschlüsselung von Passwörtern. Der SCRAM-Authentifizierungsmechanismus gilt als sicherer als. MD5 Weitere Informationen zu diesen beiden verschiedenen Ansätzen zur Sicherung von Passwörtern finden Sie unter [Passwortauthentifizierung](https://www.postgresql.org/docs/14/auth-password.html) in der PostgreSQL-Dokumentation.
Wir empfehlen, SCRAM statt MD5 als Kennwortverschlüsselungsschema für Ihren zu verwenden. DB-Instance von RDS für PostgreSQL Es ist ein kryptografischer Challenge-Response-Mechanismus, der den scram–sha-256-Algorithmus zur Passwortauthentifizierung und -verschlüsselung nutzt.
Möglicherweise müssen Sie Bibliotheken aktualisieren, damit Ihre Clientanwendungen SCRAM unterstützen können. JDBC-Versionen vor 42.2.0 unterstützen SCRAM beispielsweise nicht. Weitere Informationen finden Sie unter [PostgreSQL-JDBC-Treiber](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) in der Dokumentation zu PostgreSQL-JDBC-Treibern. Für eine Liste anderer PostgreSQL-Treiber und SCRAM-Unterstützung siehe die [Treiberliste](https://wiki.postgresql.org/wiki/List_of_drivers) in der PostgreSQL-Dokumentation.
RDS für PostgreSQL 13.1 und höhere Versionen unterstützen scram-sha-256. Mit diesen Versionen können Sie Ihre DB-Instance auch so konfigurieren, dass SCRAM erforderlich ist, wie in den folgenden Verfahren beschrieben.
## Einrichtung des RDS für die PostgreSQL-DB-Instance, die SCRAM benötigt
können Sie verlangen, dass der DB-Instance von RDS für PostgreSQL nur Passwörter akzeptiert, die den scram-sha-256-Algorithmus verwenden.
**Wichtig**
Wenn Sie bei vorhandenen RDS-Proxys mit PostgreSQL-Datenbanken die Datenbankauthentifizierung so ändern, dass nur `SCRAM` verwendet wird, ist der Proxy für bis zu 60 Sekunden nicht verfügbar. Um das Problem zu vermeiden, führen Sie einen der folgenden Schritte aus:
Stellen Sie sicher, dass die Datenbank sowohl die `SCRAM`- als auch die `MD5`-Authentifizierung zulässt.
Wenn Sie nur die `SCRAM`-Authentifizierung verwenden möchten, erstellen Sie einen neuen Proxy, migrieren Sie Ihren Anwendungsdatenverkehr auf den neuen Proxy und löschen Sie dann den zuvor mit der Datenbank verknüpften Proxy.
Bevor Sie Änderungen an Ihrem System vornehmen, vergewissern Sie sich, dass Sie den folgenden Prozess komplett verstehen:
+ Sammeln Sie Informationen über alle Rollen und Passwortverschlüsselung für alle Datenbankbenutzer.
+ Überprüfen Sie die Parametereinstellungen für Ihren DB-Instance von RDS für PostgreSQL für die Parameter, die die Passwortverschlüsselung steuern.
+ Wenn Ihr DB-Instance von RDS für PostgreSQL eine Standardparametergruppe verwendet, müssen Sie eine benutzerdefinierte DB-Parametergruppe erstellen und sie auf Ihren DB-Instance von RDS für PostgreSQL anwenden, damit Sie bei Bedarf Parameter ändern können. Wenn Ihr DB-Instance von RDS für PostgreSQL eine benutzerdefinierte Parametergruppe verwendet, können Sie die erforderlichen Parameter bei Bedarf später im Prozess ändern.
+ Ändern Sie den Parameter `password_encryption` in `scram-sha-256`.
+ Informieren Sie alle Datenbankbenutzer, dass sie ihre Passwörter aktualisieren müssen. Wiederholen Sie diesen Schritt für Ihr `postgres`-Konto. Die neuen Passwörter werden mit dem scram-sha-256-Algorithmus verschlüsselt und gespeichert.
+ Stellen Sie sicher, dass alle Passwörter mit diesem Verschlüsselungstyp verschlüsselt sind.
+ Wenn alle Passwörter scram-sha-256 verwenden, können Sie den `rds.accepted_password_auth_method`-Parameter von `md5+scram` in `scram-sha-256` ändern.
**Warnung**
Nachdem Sie `rds.accepted_password_auth_method` nur in scram-sha-256 geändert haben, können Benutzer (Rollen) mit `md5`-verschlüsselten Passwörtern keine Verbindung herstellen.
### Machen Sie sich bereit, SCRAM für Ihren ) zu benötigen
Bevor Sie Änderungen an Ihrem DB-Instance von RDS für PostgreSQL, vornehmen, überprüfen Sie alle vorhandenen Datenbankbenutzerkonten. Überprüfen Sie auch die Art der Verschlüsselung, die für Passwörter verwendet wird. Sie können für diese Aufgaben die `rds_tools`-Erweiterung verwenden. Weitere Informationen darüber, welche PostgreSQL-Versionen `rds_tools` unterstützen, finden Sie unter [Erweiterungsversionen für Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**So erhalten Sie eine Liste der Datenbankbenutzer (Rollen) und Passwortverschlüsselungsmethoden**
1. Verwenden Sie `psql` zum Herstellen einer Verbindung mit Ihrer DB-Instance von RDS für PostgreSQL, wie im Folgenden gezeigt.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installieren Sie die `rds_tools`-Erweiterung.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Rufen Sie eine Auflistung der Rollen und Verschlüsselungsmethoden ab.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Die Ausgabe entspricht weitgehend der folgenden.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Erstellen einer benutzerdefinierten DB-Parametergruppe
**Anmerkung**
Wenn Ihre DB-Instance von RDS für PostgreSQL bereits eine benutzerdefinierte Parametergruppe verwendet, müssen Sie keine neue erstellen.
Eine Übersicht über Parametergruppen für Amazon RDS finden Sie unter [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Der für Passwörter verwendete Passwortverschlüsselungstyp wird in einem Parameter, `password_encryption`, festgelegt. Die Verschlüsselung, die der DB-Instance von RDS für PostgreSQL zulässt, wird in einem anderen Parameter, `rds.accepted_password_auth_method`, festgelegt. Wenn Sie den Standardwert eines dieser Parameter ändern, müssen Sie eine benutzerdefinierte DB-Parametergruppe erstellen und auf Ihre Instance anwenden.
Sie können auch die AWS-Managementkonsole oder die RDS-API verwenden, um eine benutzerdefinierte zu erstellen. Weitere Informationen finden Sie unter
Sie können jetzt die benutzerdefinierte Parametergruppe Ihrer DB-Instance zuordnen.
**Um eine benutzerdefinierte zu erstellen, DB-Parametergruppe**
1. Verwenden Sie den CLI-Befehl `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` zum Erstellen der benutzerdefinierten DB-Parametergruppe. In diesem Beispiel wird `postgres13` als Quelle für diese benutzerdefinierte Parametergruppe verwendet.
Für Linux, macOS oder Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Für Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Verwenden Sie den CLI-Befehl `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` zum Anwenden dieser benutzerdefinierten Parametergruppe auf Ihren DB-Cluster von RDS für PostgreSQL.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Für Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Zum erneuten Synchronisieren Ihrer DB-Instance von RDS für PostgreSQL mit Ihrer benutzerdefinierten DB-Parametergruppe müssen Sie die primäre und alle anderen Instances des Clusters neu starten. Planen Sie dies während Ihres regulären Wartungsfensters, um die Auswirkungen auf Ihre Benutzer zu minimieren.
### Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM
Der Passwortverschlüsselungsmechanismus, der von einer DB-Instance von RDS für PostgreSQL verwendet wird, ist in der DB-Parametergruppe auf den Parameter `password_encryption` festgelegt. Zulässige Werte sind keine Angabe, `md5` oder `scram-sha-256`. Der Standardwert hängt von der Version von RDS für PostgreSQL wie folgt ab:
+ RDS für PostgreSQL 14 und höher – Der Standardwert ist `scram-sha-256`.
+ RDS für PostgreSQL 13 – Der Standardwert ist `md5`.
Mit einer benutzerdefinierten DB-Parametergruppe, die Ihrer DB-Instance von RDS für PostgreSQL angefügt ist, können Sie die Werte für den Passwortverschlüsselungsparameter ändern.
![\[Im Folgenden zeigt die RDS-Konsole die Standardwerte für die password_encryption-Parameter für RDS für PostgreSQL.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**So ändern Sie die Passwortverschlüsselungseinstellung in scram-sha-256**
+ Ändern Sie den Wert der Passwortverschlüsselung in scram-sha-256, wie nachfolgend gezeigt. Die Änderung kann sofort angewendet werden, da der Parameter dynamisch ist. Daher ist kein Neustart erforderlich, damit die Änderung wirksam wird.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migrieren von Passwörtern für Benutzerrollen zu SCRAM
Sie können Passwörter für Benutzerrollen wie folgt zu SCRAM migrieren.
**Um Datenbankbenutzer- (Rollen-) Passwörter von MD5 zu SCRAM zu migrieren**
1. Melden Sie sich als Administratorbenutzer an (Standardbenutzer `postgres`), wie nachfolgend gezeigt.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Überprüfen Sie die Einstellung des `password_encryption`-Parameters auf der DB-Instance von RDS für PostgreSQL mithilfe des folgenden Befehls.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ändern Sie den Wert dieses Parameters in scram-sha-256. Weitere Informationen finden Sie unter [Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Überprüfen Sie den Wert erneut, um sicherzustellen, dass er jetzt auf `scram-sha-256` festgelegt ist. Gehen Sie dazu wie folgt vor.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Bitten Sie alle Datenbankbenutzer, ihre Passwörter zu ändern. Stellen Sie sicher, dass Sie auch Ihr eigenes Passwort für das `postgres`-Konto ändern (der Datenbankbenutzer mit `rds_superuser`-Berechtigungen).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Wiederholen Sie den Vorgang für alle Datenbanken auf dem DB-Instance von RDS für PostgreSQL
### Ändern des Parameters, um SCRAM zu erfordern
Dies ist der letzte Schritt in diesem Prozess. Nachdem Sie die Änderung im folgenden Verfahren vorgenommen haben, können sich Benutzerkonten (Rollen), die nach wie vor die `md5`-Verschlüsselung für Passwörter verwenden, nicht beim anmelden. DB-Instance von RDS für PostgreSQL
Die `rds.accepted_password_auth_method` gibt die Verschlüsselungsmethode an, die die DB-Instance von RDS für PostgreSQL als Benutzerpasswort beim Anmeldevorgang akzeptiert. Der Standardwert ist `md5+scram`, was bedeutet, dass eine der beiden Methoden akzeptiert wird. Im folgenden Bild finden Sie die Standardeinstellung für diesen Parameter.
![\[Die RDS-Konsole, die die Standardwerte und die zulässigen Werte für den rds.accepted_password_auth_method-Parameter zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Die zulässigen Werte für diesen Parameter sind `md5+scram` oder nur `scram`. Durch Ändern dieses Parameterwerts in `scram` wird er erforderlich.
**So ändern Sie den Parameterwert, sodass eine SCRAM-Authentifizierung für Passwörter erforderlich ist**
1. Stellen Sie sicher, dass alle Datenbank-Benutzerpasswörter für alle Datenbanken auf Ihrer DB-Instance von RDS für PostgreSQL `scram-sha-256` für die Passwortverschlüsselung verwenden. Fragen Sie hierzu `rds_tools` für die Rolle (Benutzer) und den Verschlüsselungstyp wie folgt ab.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Wiederholen Sie die Abfrage auf allen DB-Instances Ihres DB-Instance von RDS für PostgreSQL
Wenn alle Passwörter scram-sha-256 verwenden, können Sie fortfahren.
1. Ändern Sie den Wert der akzeptierten Passwortauthentifizierung in scram-sha-256 wie folgt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Behandeln von inaktiven Verbindungen in PostgreSQL
Inaktive Verbindungen treten auf, wenn eine Datenbanksitzung auf dem Server aktiv bleibt, obwohl die Client-Anwendung abgebrochen oder auf ungewöhnliche Weise beendet wurde. Eine solche Situation entsteht in der Regel, wenn Client-Prozesse abstürzen oder unerwartet beendet werden, ohne dass ihre Datenbankverbindungen ordnungsgemäß geschlossen oder laufende Anfragen abgebrochen werden.
PostgreSQL identifiziert und bereinigt inaktive Verbindungen, wenn Serverprozesse inaktiv sind oder versuchen, Daten an Clients zu senden. Die Erkennung ist jedoch schwierig bei Sitzungen, die im Leerlauf sind, auf Eingaben vom Client warten oder Abfragen aktiv ausführen. Um diese Szenarien zu handhaben, stellt PostgreSQL die Parameter `tcp_keepalives_*`, `tcp_user_timeout` und `client_connection_check_interval` bereit.
**Topics**
+ [Grundlagen zu TCP-Keepalive](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [Wichtige TCP-Keepalive-Parameter in RDS für PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Anwendungsfälle für TCP-Keepalive-Einstellungen](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Best Practices](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Grundlagen zu TCP-Keepalive
TCP-Keepalive ist ein Mechanismus auf Protokollebene, der dabei hilft, die Verbindungsintegrität aufrechtzuerhalten und zu überprüfen. Jede TCP-Verbindung verwaltet Einstellungen auf Kernelebene, die das Keepalive-Verhalten steuern. Wenn der Keepalive-Timer abläuft, führt das System folgenden Aktionen durch:
+ Es sendet ein Testpaket ohne Daten und mit gesetztem ACK-Flag.
+ Erwartet eine Antwort vom Remote-Endpunkt gemäß den TCP/IP Spezifikationen.
+ Es verwaltet den Verbindungsstatus auf der Grundlage der Antwort oder des Fehlens einer Antwort.
## Wichtige TCP-Keepalive-Parameter in RDS für PostgreSQL
| Parameter | Description | Standardwerte |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Gibt die Anzahl der Sekunden der Inaktivität an, bevor eine Keepalive-Nachricht gesendet wird. | 300 |
| tcp\$1keepalives\$1interval | Gibt die Anzahl der Sekunden zwischen erneuten Übertragungen unbestätigter Keepalive-Nachrichten an. | 30 |
| tcp\$1keepalives\$1count | Höchstzahl verloren gegangener Keepalive-Nachrichten, bevor die Verbindung für unterbrochen erklärt wird | 2 |
| tcp\$1user\$1timeout | Gibt an, wie lange (in Millisekunden) unbestätigte Daten verbleiben können, bevor die Verbindung gewaltsam geschlossen wird. | 0 |
| client\$1connection\$1check\$1interval | Legt das Intervall (in Millisekunden) für die Überprüfung des Client-Verbindungsstatus bei Abfragen mit langer Laufzeit fest. Dadurch wird eine schnellere Erkennung geschlossener Verbindungen gewährleistet. | 0 |
## Anwendungsfälle für TCP-Keepalive-Einstellungen
### Aufrechterhalten von Sitzungen im Leerlauf
So verhindern Sie, dass inaktive Verbindungen aufgrund von Inaktivität durch Firewalls oder Router beendet werden:
+ Konfigurieren Sie `tcp_keepalives_idle`, um Keepalive-Pakete in regelmäßigen Abständen zu senden.
### Erkennen von inaktiven Verbindungen
Gehen Sie wie folgt vor, um inaktive Verbindungen umgehend zu erkennen:
+ Passen Sie `tcp_keepalives_idle`, `tcp_keepalives_interval` und `tcp_keepalives_count` an. Mit den Standardeinstellungen von Aurora PostgreSQL dauert es beispielsweise etwa 1 Minute (2 Proben × 30 Sekunden), um eine interaktive Verbindung zu erkennen. Eine Senkung dieser Werte kann die Erkennung beschleunigen.
+ Verwenden Sie `tcp_user_timeout`, um die maximale Wartezeit für eine Bestätigung festzulegen.
TCP-Keepalive-Einstellungen helfen dem Kernel, inaktive Verbindungen zu erkennen, aber PostgreSQL reagiert möglicherweise erst, wenn der Socket verwendet wird. Wenn in einer Sitzung eine lange Abfrage ausgeführt wird, werden inaktive Verbindungen möglicherweise erst nach Abschluss der Abfrage erkannt. In PostgreSQL 14 und höheren Versionen kann `client_connection_check_interval` die Erkennung inaktiver Verbindungen beschleunigen, indem der Socket während der Abfrageausführung regelmäßig abgefragt wird.
## Best Practices
+ **Angemessene Keepalive-Intervalle festlegen:** Optimieren Sie `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` und `tcp_keepalives_interval`, um für ein ausgewogenes Verhältnis zwischen Erkennungsgeschwindigkeit und Ressourcennutzung zu sorgen.
+ **Für Ihre Umgebung optimieren**. Richten Sie Einstellungen am Netzwerkverhalten, an Firewall-Richtlinien und an Sitzungsanforderungen aus.
+ **PostgreSQL-Funktionen nutzen:** Verwenden Sie `client_connection_check_interval` in PostgreSQL 14 und höheren Versionen für effiziente Verbindungsprüfungen.
# Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL
Wir empfehlen ausdrücklich die Selbstbereinigungsfunktion zu verwenden, um die Integrität Ihrer PostgreSQL-DB-Instance zu wahren. Die Selbstbereinigung automatisiert den Start der Befehle VACUUM und ANALYZE. Sie prüft auf Tabellen mit einer großen Zahl von eingefügten, aktualisierten oder gelöschten Tupeln. Nach dieser Prüfung wird Speicher durch Entfernen von überflüssigen Daten oder Tupeln aus der PostgreSQL-Datenbank freigegeben.
Standardmäßig ist die Selbstbereinigungsfunktion auf den DB-Instances von RDS für PostgreSQL aktiviert, die Sie mit einer der standardmäßigen PostgreSQL-DB-Parametergruppen erstellen. Andere Konfigurationsparameter, die mit der Selbstbereinigungsfunktion verknüpft sind, sind ebenfalls standardmäßig festgelegt. Da diese Standardwerte generisch sind, können Sie davon profitieren, einige der mit der Selbstbereinigungsfunktion verbundenen Parameter für Ihre spezifische Workload zu optimieren.
Im Folgenden finden Sie weitere Informationen zur Selbstbereinigung und wie Sie einige ihrer Parameter auf Ihrer DB-Instance von RDS für PostgreSQL optimieren können. Allgemeine Informationen finden Sie unter [Bewährte Methoden für die Arbeit mit PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [Zuweisen von Arbeitsspeicher für die Selbstbereinigung](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [Ermittlung, ob die Tabellen in Ihrer Datenbank bereinigt werden müssen](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [Ermittlung, für welche Tabellen derzeit eine Selbstbereinigung nötig ist](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Ermittlung, ob die Selbstbereinigung derzeit ausgeführt wird und wie lange sie dauert](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [Neuindizierung einer Tabelle während der Ausführung einer Selbstbereinigung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [Verwalten der automatischen Bereinigung mit großen Indizes](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [Weitere Parameter, die sich auf die Selbstbereinigung auswirken](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [Festlegen von Selbstbereinigungsparametern auf Tabellenebene](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [Verstehen des Verhaltens der Selbstbereinigung bei ungültigen Datenbanken](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [Identifizieren und Beheben von Problemen mit Blockern aggressiver Bereinigungen in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Zuweisen von Arbeitsspeicher für die Selbstbereinigung
Einer der wichtigsten Parameter, der sich auf die Leistung der Selbstbereinigung auswirkt, ist der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). In RDS für PostgreSQL, Versionen 14 und früher, ist der `autovacuum_work_mem`-Parameter auf -1 gesetzt und zeigt somit an, dass stattdessen die `maintenance_work_mem`-Einstellung verwendet wird. Für alle anderen Versionen `autovacuum_work_mem` wird durch GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536) bestimmt.
Bei manuellen Vakuumvorgängen wird immer die `maintenance_work_mem` Einstellung verwendet, wobei die Standardeinstellung GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536) ist. Sie kann auch auf Sitzungsebene mithilfe des Befehls für gezieltere manuelle Operationen angepasst werden. `SET` `VACUUM`
`autovacuum_work_mem` bestimmt den Speicher der automatischen Bereinigung zum Speichern von IDs toter Tupeln (`pg_stat_all_tables.n_dead_tup`) für Bereinigungsindizes.
Beachten Sie Folgendes, wenn Sie Berechnungen durchführen, um den Wert des `autovacuum_work_mem`-Parameters bestimmen:
+ Wenn Sie den Wert des Parameters zu niedrig einstellen, muss die Tabelle während des Bereinigungsvorgangs möglicherweise mehrmals gescannt werden, damit der Vorgang abgeschlossen werden kann. Solche wiederholten Scans können negative Auswirkungen auf die Leistung haben. Bei größeren Instances kann das Festlegen von `maintenance_work_mem` oder `autovacuum_work_mem` auf mindestens 1 GB die Leistung bei der Bereinigung von Tabellen mit einer hohen Anzahl von toten Tupeln verbessern. In den PostgreSQL-Versionen 16 und früher ist die Speichernutzung für die Bereinigung jedoch auf 1 GB begrenzt, was ausreicht, um ungefähr 179 Millionen tote Tupel in einem einzigen Durchgang zu verarbeiten. Wenn eine Tabelle mehr tote Tupel enthält, sind mehrere Bereinigungsdurchläufe durch die Indizes der Tabelle erforderlich, was den Zeitaufwand erheblich erhöht. Ab PostgreSQL-Version 17 gibt es kein Limit von 1 GB mehr und die Selbstbereinigung kann mithilfe von Radixbäumen mehr als 179 Millionen Tupel verarbeiten.
Ein Tupel-Bezeichner hat eine Größe von 6 Bytes. Um den Speicherbedarf für das Bereinigen eines Tabellenindex zu schätzen, fragen Sie `pg_stat_all_tables.n_dead_tup` ab, um die Anzahl der toten Tupel zu ermitteln. Multiplizieren Sie diese Zahl dann mit 6, um den Speicherbedarf zu bestimmen, der für das Bereinigen des Index in einem einzigen Durchgang erforderlich ist. Sie können die folgende Abfrage verwenden:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Der Parameter `autovacuum_work_mem` funktioniert in Verbindung mit dem Parameter `autovacuum_max_workers`. Jeder Worker aus `autovacuum_max_workers` kann den von Ihnen zugeteilten Arbeitsspeicher nutzen. Wenn Sie viele kleine Tabellen haben, müssen Sie mehr `autovacuum_max_workers` und weniger `autovacuum_work_mem` zuteilen. Wenn Sie große Tabellen haben (größer als 100 GB), sollten Sie mehr Arbeitsspeicher und weniger Worker-Prozesse zuteilen. Sie müssen genügend Arbeitsspeicher zuweisen, um den Vorgang für Ihre größte Tabelle erfolgreich ausführen zu können. Daher muss die Kombination aus Worker-Prozessen und Arbeitsspeicher dem gesamten Arbeitsspeicher entsprechen, den Sie zuteilen möchten.
## Verringern der Wahrscheinlichkeit von Transaktions-ID-Wraparounds
In einigen Fällen sind Parametergruppen-Einstellungen, die sich auf die Selbstbereinigung beziehen, möglicherweise nicht aggressiv genug, um Transaktions-ID-Wraparounds zu verhindern. Um dieses Problem anzugehen, stellt RDS für PostgreSQL eine Methode bereit, mit der die Selbstbereinigungsparameter automatisch angepasst werden. Die *adaptive Selbstbereinigung* ist ein Feature für RDS für PostgreSQL . In der PostgreSQL-Dokumentation finden Sie eine sehr detaillierte Beschreibung von [Transaktions-ID-Wraparounds](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Die adaptive Selbstbereinigung ist standardmäßig für Instances von RDS für PostgreSQL aktiviert, wobei der dynamische Parameter `rds.adaptive_autovacuum` auf ON gesetzt ist. Wir raten dringend dazu, diese Option aktiviert zu lassen. Um die adaptive Optimierung der Selbstbereinigungsparameter zu deaktivieren, stellen Sie den Parameter `rds.adaptive_autovacuum` jedoch auf 0 oder OFF ein.
Transaktions-ID-Wraparounds können selbst dann noch auftreten, wenn Amazon RDS Amazon RDS die Selbstbereinigungsparameter optimiert. Wir empfehlen Ihnen, einen CloudWatch Amazon-Alarm für den Transaktions-ID-Wraparound zu implementieren. Weitere Informationen finden Sie im Datenbank-Blog im Beitrag [Implementieren eines Frühwarnsystems für Transaktions-ID-Wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/). AWS
Wenn die adaptive Abstimmung der Autovakuum-Parameter aktiviert ist, beginnt Amazon RDS mit der Anpassung der Autovakuum-Parameter, wenn die CloudWatch Metrik den Wert des `autovacuum_freeze_max_age` Parameters oder 500.000.000 `MaximumUsedTransactionIDs` erreicht, je nachdem, welcher Wert größer ist.
Amazon RDS fährt mit dem Anpassen der Parameter für die Selbstbereinigung fort, wenn eine Tabelle weiterhin zu Transaktions-ID-Wraparounds tendiert. Jede dieser Anpassungen stellt weitere Ressourcen für die Selbstbereinigung bereit, um Wraparounds zu vermeiden. Amazon RDS aktualisiert die folgenden Parameter, die sich auf die Selbstbereinigung beziehen:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS ändert diese Parameter nur, wenn der neue Wert die Selbstbereinigung aggressiver macht. Die Parameter werden im Arbeitsspeicher auf der DB-Instance geändert. Die Werte in der Parametergruppe werden nicht geändert. Um die aktuellen Arbeitsspeichereinstellungen anzuzeigen, verwenden Sie den PostgreSQL-SQL-Befehl [SHOW](https://www.postgresql.org/docs/current/sql-show.html).
Wenn Amazon RDS einen dieser Selbstbereinigungsparameter ändert, wird ein Ereignis für die betroffene DB-Instance erzeugt. Dieses Ereignis ist auf der AWS-Managementkonsole und über die Amazon RDS-API sichtbar. Wenn die `MaximumUsedTransactionIDs` CloudWatch Metrik wieder unter den Schwellenwert fällt, setzt Amazon RDS die Autovakuum-bezogenen Parameter im Speicher auf die in der Parametergruppe angegebenen Werte zurück. Es generiert dann ein anderes Ereignis, das dieser Änderung entspricht.
# Ermittlung, ob die Tabellen in Ihrer Datenbank bereinigt werden müssen
Sie können die folgende Abfrage verwenden, um die Anzahl der nicht eingefrorenen Transaktionen in einer Datenbank anzuzeigen. Die `datfrozenxid` Spalte einer `pg_database` Datenbankzeile ist eine Untergrenze der normalen Transaktion, die in dieser Datenbank IDs erscheint. Diese Spalte ist der Mindestwert der `relfrozenxid`-Werte pro Tabelle in der Datenbank.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Beispielsweise könnten die Ergebnisse der Ausführung der oben gezeigten Abfrage wie folgt aussehen.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Wenn das Alter einer Datenbank 2 Milliarden Transaktionen erreicht IDs, erfolgt ein Transaktions-ID (XID) -Wraparound, und die Datenbank wird schreibgeschützt. Sie können diese Abfrage verwenden, um eine Metrik zu erstellen und einige Male am Tag auszuführen. Standardmäßig ist die Selbstbereinigung so festgelegt, dass das Alter der Transaktionen 200 000 000 nicht überschreitet 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Eine Überwachungsstrategie kann beispielsweise wie folgt aussehen:
+ Stellen Sie den `autovacuum_freeze_max_age`-Wert auf 200 Millionen Transaktionen ein.
+ Wenn eine Tabelle 500 Millionen nicht eingefrorener Transaktionen erreicht, wird ein Alarm mit niedrigem Schweregrad ausgelöst. Dies ist kein unangemessener Wert. Er könnte jedoch zu erkennen geben, dass die Selbstbereinigung nicht Schritt hält.
+ Wenn eine Tabelle 1 Milliarde nicht bereinigter Transaktionen aufweist, sollte dies als ein Alarm behandelt werden, für den Maßnahmen zu ergreifen sind. Im Allgemeinen sollte aus Leistungsgründen das Alter möglichst nahe zu `autovacuum_freeze_max_age` liegen. Wir empfehlen, dass Sie eine Untersuchung unter Beachtung der folgenden Empfehlungen durchführen.
+ Wenn eine Tabelle 1,5 Milliarden nicht bereinigter Transaktionen erreicht, wird ein Alarm mit hohem Schweregrad ausgelöst. Je nachdem, wie schnell Ihre Datenbank die Transaktion verwendet, kann dieser Alarm darauf hinweisen IDs, dass dem System die Zeit für die Ausführung des Autovakuums knapp wird. In diesem Fall empfehlen wir, eine unmittelbare Lösung in Betracht zu ziehen.
Wenn eine Tabelle diese Schwellenwerte konstant überschreitet, ändern Sie die Selbstbereinigungsparameter weiter. Standardmäßig ist die manuelle Verwendung von VACUUM (für den kostenbasierte Verzögerungen deaktiviert sind) aggressiver als die Standardselbstbereinigung. Der Befehl hat jedoch insgesamt auch größere Auswirkungen auf das System.
Wir empfehlen Folgendes:
+ Aktivieren Sie einen Überwachungsmechanismus, damit Sie über das Alter der ältesten Transaktionen informiert sind.
Informationen zum Erstellen eines Prozesses, der Sie vor Transaktions-ID-Wraparound warnt, finden Sie im AWS Datenbank-Blogbeitrag [Implementieren Sie ein Frühwarnsystem für Transaktions-ID-Wraparound in Amazon](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) RDS for PostgreSQL.
+ Führen Sie für häufiger verwendete Tabellen zusätzlich zur Selbstbereinigung während Wartungsfenstern regelmäßig eine manuelle Bereinigungseinfrierung aus. Informationen zur Ausführung manueller Bereinigungseinfrierungen finden Sie unter [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Ermittlung, für welche Tabellen derzeit eine Selbstbereinigung nötig ist
Häufig benötigen eine oder zwei Tabellen eine Bereinigung. Tabellen, deren `relfrozenxid`-Wert größer als die Anzahl von Transaktionen in `autovacuum_freeze_max_age` ist, sind stets Ziel der Selbstbereinigung. Wenn andernfalls die Anzahl der Tupeln, die seit dem letzten VACUUM-Befehl veraltet sind, den Bereinigungsschwellenwert überschreitet, wird die Tabelle bereinigt.
Der [Selbstbereinigungsschwellenwert](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) ist definiert als:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
wobei `vacuum base threshold` `autovacuum_vacuum_threshold` ist, `vacuum scale factor` `autovacuum_vacuum_scale_factor` ist und `number of tuples` `pg_class.reltuples` ist.
Führen Sie während der Herstellung der Verbindung mit Ihrer Datenbank die folgende Abfrage aus, um eine Liste der Tabellen anzuzeigen, für die Selbstbereinigungsfunktion eine Bereinigung als notwendig betrachtet.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Ermittlung, ob die Selbstbereinigung derzeit ausgeführt wird und wie lange sie dauert
Wenn Sie eine Tabelle manuell bereinigen müssen, müssen Sie ermitteln, ob zurzeit eine Selbstbereinigung ausgeführt wird. Wenn dies der Fall ist, müssen Sie die Parameter anpassen, damit sie effizienter ausgeführt wird, oder die Selbstbereinigung temporär beenden, damit Sie den Befehl VACUUM manuell ausführen können.
Verwenden Sie die folgende Abfrage, um zu ermitteln, ob die Selbstbereinigung ausgeführt wird, wie lange diese bereits dauert und ob diese auf eine andere Sitzung wartet.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Nach dem Ausführen der Abfrage wird Ihnen eine Ausgabe ähnlich der folgenden angezeigt.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Verschiedene Probleme können dazu führen, dass eine Selbstbereinigungssitzung über eine lange Zeit (mehrere Tage) ausgeführt wird. Das häufigste Problem besteht jedoch darin, dass der Wert Ihres Parameters [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) im Verhältnis zur Größe der Tabelle oder zur Häufigkeit der Aktualisierungen zu niedrig festgelegt wurde.
Es wird empfohlen, dass Sie die folgende Formel verwenden, um den Wert des Parameters `maintenance_work_mem` festzulegen.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Selbstbereinigungssitzungen, die nur kurze Zeit ausgeführt werden, können ebenfalls auf Probleme hinweisen:
+ Es kann bedeuten, dass es für Ihren Workload nicht genügend `autovacuum_max_workers` gibt. In diesem Fall müssen Sie die Anzahl der Worker angeben.
+ Es kann bedeuten, dass es eine Indexbeschädigung gibt (die Selbstbereinigung stürzt ab und startet bei derselben Relation neu, es gibt jedoch keine Fortschritte). Führen Sie in diesem Fall ein manuelles `vacuum freeze verbose table` aus, um die genaue Ursache zu sehen.
# Ausführen einer manuellen Bereinigungseinfrierung
Möglicherweise möchten Sie eine manuelle Bereinigung für eine Tabelle ausführen, für die bereits ein Bereinigungsvorgang ausgeführt wird. Dies ist nützlich, wenn Sie eine Tabelle mit einem Alter identifiziert haben, das 2 Milliarden Transaktionen (oder einen Wert oberhalb eines von Ihnen beobachteten Schwellenwerts) erreicht.
Die folgenden Schritte sind Richtlinien mit mehreren Variationen des Prozesses. Angenommen, Sie stellen während der Überprüfung fest, dass der Wert für den Parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) zu niedrig festgelegt wurde. Sie müssen sofort Maßnahmen für eine Tabelle einleiten. Sie möchten zum aktuellen Zeitpunkt jedoch keinen Bounce für die Instance auslösen. Ermitteln Sie mittels der Abfragen in vorherigen Abschnitten die Tabelle, die das Problem darstellt, und identifizieren Sie eine über einen langen Zeitraum ausgeführte Selbstbereinigungssitzung. Sie müssen die Einstellung für den Parameter `maintenance_work_mem` ändern. Sie müssen jedoch auch sofortige Maßnahmen einleiten und die betreffende Tabelle bereinigen. Das folgende Verfahren zeigt, was Sie in dieser Situation unternehmen.
**So führen Sie manuell eine Bereinigungseinfrierung aus**
1. Öffnen Sie zwei Sitzungen für die Datenbank, die Tabelle enthält, die Sie bereinigen möchten. Verwenden Sie für die zweite Sitzung „screen“ oder ein anderes Hilfsprogramm, das die Sitzung beibehält, wenn die Verbindung verloren geht.
1. Rufen Sie in der ersten Sitzung die Prozess-ID (PID) der Selbstbereinigungssitzung ab, die für die Tabelle ausgeführt wird.
Führen Sie die folgende Abfrage aus, um die PID der Selbstbereinigungssitzung abzurufen.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Berechnen Sie in der zweiten Sitzung die Menge des Arbeitsspeichers, den Sie für diese Operation benötigen. In diesem Beispiel ermitteln Sie, dass für diese Operation bis zu 2 GB Arbeitsspeicher verwendet werden können. Daher wird für die aktuelle Sitzung [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) auf 2 GB festgelegt.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Geben Sie in der zweiten Sitzung einen `vacuum freeze verbose`-Befehl für die Tabelle aus. Die Verbose-Einstellung ist nützlich, da Sie Aktivität sehen können, auch wenn in PostgreSQL hierfür zurzeit kein Fortschrittsbericht verfügbar ist.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Wenn die Selbstbereinigung die Bereinigungssitzung blockiert hat, wird Ihnen in der ersten Sitzung in `pg_stat_activity` angezeigt, dass das Warten für Ihre Bereinigungssitzung `T` ist. Beenden Sie in diesem Fall den Selbstbereinigungsvorgang wie folgt.
```
SELECT pg_terminate_backend('the_pid');
```
**Anmerkung**
Einige niedrigere Versionen von Amazon RDS können einen Selbstbereinigungsvorgang mit dem vorherigen Befehl nicht beenden und schlagen mit dem folgenden Fehler fehl:`ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
An diesem Punkt beginnt Ihre Sitzung. Die Selbstbereinigung wird sofort neu gestartet, da diese Tabelle in der Liste der Aufgaben wahrscheinlich ganz oben steht.
1. Initiieren Sie Ihren `vacuum freeze verbose`-Befehl in der zweiten Sitzung und beenden Sie dann den Selbstbereinigungsvorgang in der ersten Sitzung.
# Neuindizierung einer Tabelle während der Ausführung einer Selbstbereinigung
Wenn ein Index beschädigt wurde, verarbeitet die Selbstbereinigung die Tabelle weiter und schlägt fehl. Wenn Sie in dieser Situation eine manuelle Bereinigung versuchen, werden Sie eine Fehlermeldung ähnlich der folgenden erhalten.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Wenn der Index beschädigt ist und eine Selbstbereinigung für die Tabelle versucht wird, konkurrieren Sie mit einer Selbstbereinigungssitzung, die bereits ausgeführt wird. Wenn Sie einen [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html)-Befehl ausgeben, wird eine exklusive Sperre für die Tabelle ausgeführt. Schreiboperationen werden blockiert. Gleiches gilt für Lesevorgänge, die diesen spezifischen Index verwenden.
**So führen Sie eine Neuindizierung für eine Tabelle aus, wenn eine Selbstbereinigung für die Tabelle ausgeführt wird**
1. Öffnen Sie zwei Sitzungen für die Datenbank, die Tabelle enthält, die Sie bereinigen möchten. Verwenden Sie für die zweite Sitzung „screen“ oder ein anderes Hilfsprogramm, das die Sitzung beibehält, wenn die Verbindung verloren geht.
1. Rufen Sie in der ersten Sitzung die PID der Selbstbereinigungssitzung ab, die für die Tabelle ausgeführt wird.
Führen Sie die folgende Abfrage aus, um die PID der Selbstbereinigungssitzung abzurufen.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Führen Sie in der zweiten Sitzung den Neuindizierungsbefehl aus.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Wenn die Selbstbereinigung den Prozess blockiert hat, wird Ihnen in der ersten Sitzung in `pg_stat_activity` angezeigt, dass das Warten für Ihre Bereinigungssitzung "T" ist. In diesem Fall beenden Sie den Selbstbereinigungsprozess.
```
SELECT pg_terminate_backend('the_pid');
```
An diesem Punkt beginnt Ihre Sitzung. Es ist wichtig, zu beachten, dass die Selbstbereinigung sofort neu gestartet wird, da diese Tabelle in der Liste der Aufgaben wahrscheinlich ganz oben steht.
1. Initiieren Sie Ihren Befehl in der zweiten Sitzung und beenden Sie dann den Selbstbereinigungsvorgang in der ersten Sitzung.
# Verwalten der automatischen Bereinigung mit großen Indizes
Im Rahmen ihrer Funktion führt die *automatische Bereinigung* mehrere [Bereinigungsphasen](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) aus, während sie für eine Tabelle ausgeführt wird. Bevor die Tabelle bereinigt wird, werden zunächst alle Indizes bereinigt. Wenn mehrere große Indizes entfernt werden, benötigt diese Phase einen großen Zeit- und Ressourcenaufwand. Es hat sich daher bewährt, die Anzahl der Indizes in einer Tabelle zu kontrollieren und ungenutzte Indizes zu entfernen.
Überprüfen Sie für diesen Vorgang zunächst die Gesamtindexgröße. Stellen Sie dann fest, ob es möglicherweise unbenutzte Indizes gibt, die entfernt werden können, wie in den folgenden Beispielen dargestellt.
**So überprüfen Sie die Größe der Tabelle und ihrer Indizes**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
In diesem Beispiel ist die Größe der Indizes größer als die Tabelle. Dieser Unterschied kann zu Leistungsproblemen führen, da die Indizes überlastet oder ungenutzt sind, was sich sowohl auf die automatische Bereinigung als auch auf Insert-Operationen auswirkt.
**So prüfen Sie, ob ungenutzte Indizes vorhanden sind**
Mithilfe der Ansicht [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) können Sie überprüfen, wie oft ein Index für die Spalte `idx_scan` verwendet wird. Im folgenden Beispiel haben die ungenutzten Indizes den `idx_scan`-Wert `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**Anmerkung**
Diese Statistiken sind ab dem Zeitpunkt, an dem die Statistiken zurückgesetzt werden, inkrementell. Angenommen, Sie haben einen Index, der nur am Ende eines Geschäftsquartals oder nur für einen bestimmten Bericht verwendet wird. Es ist möglich, dass dieser Index seit dem Zurücksetzen der Statistiken nicht mehr verwendet wurde. Weitere Informationen finden Sie unter [Statistikfunktionen](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Indizes, die verwendet werden, um Eindeutigkeit zu erzwingen, werden nicht gescannt und sollten nicht als ungenutzte Indizes identifiziert werden. Um die ungenutzten Indizes zu identifizieren, sollten Sie über fundierte Kenntnisse der Anwendung und ihrer Abfragen verfügen.
Um zu überprüfen, wann die Statistiken für eine Datenbank zuletzt zurückgesetzt wurden, verwenden Sie [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW).
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Möglichst schnelles Bereinigen einer Tabelle
**RDS für PostgreSQL 12 und höher**
Wenn Sie zu viele Indizes in einer großen Tabelle haben, nähert sich Ihre DB-Instance möglicherweise dem Transaktions-ID-Wraparound (XID), also dem Zeitpunkt, an dem der XID-Zähler auf Null zurückgeht. Wenn diese Option nicht aktiviert ist, kann diese Situation zu Datenverlust führen. Sie können die Tabelle jedoch schnell bereinigen, ohne die Indizes zu bereinigen. In RDS für PostgreSQL 12 und höher können Sie VACUUM mit der Klausel [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html) verwenden.
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Wenn eine automatische Bereinigungssitzung bereits läuft, müssen Sie sie beenden, um mit dem manuellen VACUUM-Vorgang zu beginnen. Informationen zur Ausführung manueller Bereinigungseinfrierungen finden Sie unter [Ausführen einer manuellen Bereinigungseinfrierung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**Anmerkung**
Wenn Sie die Indexbereinigung regelmäßig überspringen, führt dies zu einer Überlastung der des Indizes, was die Leistung degradiert. Der Index behält tote Zeilen und die Tabelle behält tote Zeilenzeiger bei. Daher wird `pg_stat_all_tables.n_dead_tup` erhöht, bis die Selbstbereinigung oder einen manuellen VACUUM-Vorgang mit Indexbereinigung ausgeführt wird. Verwenden Sie dieses Verfahren am besten nur, um einen Transaktions-ID-Wraparound zu verhindern.
**RDS für PostgreSQL 11 und niedriger**
In RDS für PostgreSQL 11 und niedrigeren Versionen besteht die einzige Möglichkeit, den Bereinigungsvorgang schneller abzuschließen, darin, die Anzahl der Indizes in einer Tabelle zu reduzieren. Das Löschen eines Index kann sich auf Abfragepläne auswirken. Wir empfehlen, zuerst unbenutzte Indizes zu löschen und dann die Indizes löschen, wenn der XID-Wraparound kurz bevorsteht. Nach Abschluss des Bereinigungsvorgangs können Sie diese Indizes neu erstellen.
# Weitere Parameter, die sich auf die Selbstbereinigung auswirken
Die folgende Abfrage zeigt die Werte einiger Parameter an, die sich direkt auf die Selbstbereinigung und ihr Verhalten auswirken. Die [Selbstbereinigungsparameter](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) werden in der PostgreSQL-Dokumentation vollständig beschrieben.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
All diese Parameter wirken sich auf die Selbstbereinigung aus. Die wichtigsten unter ihnen sind jedoch:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Festlegen von Selbstbereinigungsparametern auf Tabellenebene
Sie können [Speicherparameter](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS), die sich auf die der Selbstbereinigung beziehen, auf Tabellenebene festlegen. Dies kann im Vergleich zur Änderung des Verhaltens der gesamten Datenbank ein bevorzugtes Verfahren sein. Im Fall großer Tabellen müssen möglicherweise aggressive Einstellungen festgelegt werden, und Sie möchten vielleicht nicht, dass sich die Selbstbereinigung für alle Tabellen auf diese Weise verhält.
Die folgende Abfrage zeigt, für welche Tabellen zurzeit Optionen auf Tabellenebene festgelegt wurden.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Ein Beispiel, in dem dies nützlich sein kann, sind Tabellen, die sehr viel größer als Ihre restlichen Tabellen sind. Angenommen, es gibt eine Tabelle mit 300 GB und 30 weitere Tabellen mit weniger als 1 GB. In diesem Fall würde es sich anbieten, einige spezifische Parameter nur für die große Tabelle festzulegen, um nicht das Verhalten des gesamten Systems zu ändern.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Hierdurch wird die kostenbasierte Selbstbereinigungsverzögerung für diese Tabelle auf Kosten einer größeren Ressourcennutzung in Ihrem System deaktiviert. Normalerweise pausiert die Selbstbereinigung für `autovacuum_vacuum_cost_delay` jedes Mal, wenn `autovacuum_cost_limit` erreicht wird. Weitere Details finden Sie in der PostgreSQL-Dokumentation zum Thema [kostenbasierte Bereinigung](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten
Informationen über Bereinigungsaktivitäten werden basierend auf der im`rds.force_autovacuum_logging_level`-Parameter angegebenen Ebene an das `postgresql.log` gesendet. Im Folgenden sind die für diesen Parameter zulässigen Werte und die PostgreSQL-Versionen aufgeführt, für die dieser Wert die Standardeinstellung ist:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 und höher)
+ `error`, Protokoll, `fatal`, `panic`
Das `rds.force_autovacuum_logging_level` arbeitet mit dem `log_autovacuum_min_duration`-Parameter. Der Wert des `log_autovacuum_min_duration`-Parameters ist der Schwellenwert (in Millisekunden), über dem Selbstbereinigung-Aktionen protokolliert werden. Eine Einstellung von `-1` protokolliert nichts, während eine Einstellung von 0 alle Aktionen protokolliert. Wie bei `rds.force_autovacuum_logging_level`, Standardwerte für `log_autovacuum_min_duration` sind versionsabhängig wie folgt:
+ `10000 ms` – PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 und PostgreSQL 11
+ `(empty)` – Kein Standardwert für PostgreSQL 10 und PostgreSQL 9.6
Wir empfehlen Ihnen, `rds.force_autovacuum_logging_level` auf `WARNING` einzustellen. Wir empfehlen auch, dass Sie `log_autovacuum_min_duration` auf einen Wert von 1000 bis 5000 einstellen. Eine Einstellung von 5000 Protokollaktivitäten, die länger als 5000 Millisekunden dauern. Jede andere Einstellung als –1 protokolliert auch Meldungen, wenn die Selbstbereinigungsaktion aufgrund einer widersprüchlichen Sperre oder gleichzeitig verworfener Beziehungen übersprungen wird. Weitere Informationen finden Sie unter [Selbstbereinigung](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) in der PostgreSQL-Dokumentation.
Um Probleme zu beheben, können Sie die `rds.force_autovacuum_logging_level`-Parameter in eine der Debugebenen ändern, von `debug1` bis zu `debug5` für die ausführlichsten Informationen. Wir empfehlen, die Debug-Einstellungen für kurze Zeiträume und nur zur Fehlerbehebung zu verwenden. Weitere Informationen finden Sie unter [Zeitpunkt des Protokollierens](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) in der PostgreSQL-Dokumentation.
**Anmerkung**
PostgreSQL ermöglicht es dem Konto `rds_superuser`, Autovakuum-Sitzungen in `pg_stat_activity` anzuzeigen. Sie können beispielsweise eine Selbstbereinigungssitzung identifizieren und beenden, die die Ausführung eines Befehls blockiert oder langsamer als ein manuell ausgegebener Bereinigungsbefehl ausgeführt wird.
# Verstehen des Verhaltens der Selbstbereinigung bei ungültigen Datenbanken
Ein neuer `-2`-Wert wird in die `datconnlimit`-Spalte im `pg_database`-Katalog eingeführt, um Datenbanken, die während des DROP DATABASE-Vorgangs unterbrochen wurden, als ungültig zu kennzeichnen.
Dieser neue Wert ist in den folgenden Versionen von RDS für PostgreSQL verfügbar:
+ 15.4 und alle höheren Versionen
+ 14.9 und höhere Versionen
+ 13.12 und höhere Versionen
+ 12.16 und höhere Versionen
+ 11.21 und höhere Versionen
Ungültige Datenbanken haben keinen Einfluss auf die Möglichkeit der Selbstbereinigung, die Funktionalität für gültige Datenbanken einzufrieren. Die Selbstbereinigung ignoriert ungültige Datenbanken. Folglich funktionieren reguläre Selbstbereinigungsfunktionen weiterhin ordnungsgemäß und werden effizient für alle gültigen Datenbanken in Ihrer PostgreSQL-Umgebung ausgeführt.
**Topics**
+ [Überwachen der Transaktions-ID](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [Anpassen der Überwachungsanfrage](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [Beheben des Problems mit ungültigen Datenbanken](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Überwachen der Transaktions-ID
Die `age(datfrozenxid)`-Funktion wird häufig verwendet, um das Alter der Transaktions-ID (XID) von Datenbanken zwecks Verhinderung eines Transaktions-ID-Wrapraround zu überwachen.
Da ungültige Datenbanken von der Selbstbereinigung ausgenommen sind, kann ihr Transaktions-ID-(XID)-Zähler den Maximalwert von `2 billion` erreichen, auf `- 2 billion` zurückgehen und diesen Zyklus auf unbestimmte Zeit fortsetzen. Eine typische Abfrage zur Überwachung des Transaktions-ID-Wraparound könnte wie folgt aussehen:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Mit der Einführung des Werts -2 für `datconnlimit` können ungültige Datenbanken jedoch die Ergebnisse dieser Abfrage verfälschen. Da diese Datenbanken nicht gültig sind und nicht Teil regelmäßiger Wartungsprüfungen sein sollten, können sie zu einem falsch-positiven Ergebnis führen, sodass Sie glauben, dass der `age(datfrozenxid)`-Wert höher ist, als er tatsächlich ist.
## Anpassen der Überwachungsanfrage
Um eine genaue Überwachung zu gewährleisten, sollten Sie Ihre Überwachungsabfrage so anpassen, dass ungültige Datenbanken ausgeschlossen werden. Folgen Sie dieser empfohlenen Abfrage:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Diese Abfrage stellt sicher, dass nur gültige Datenbanken bei der `age(datfrozenxid)`-Berechnung berücksichtigt werden, sodass das Alter der Transaktions-ID in Ihrer gesamten PostgreSQL-Umgebung genau wiedergegeben wird.
## Beheben des Problems mit ungültigen Datenbanken
Wenn Sie versuchen, eine Verbindung zu einer ungültigen Datenbank herzustellen, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Wenn darüber hinaus der `log_min_messages`-Parameter auf `DEBUG2` oder höher gesetzt ist, fallen Ihnen möglicherweise die folgenden Protokolleinträge auf, die darauf hinweisen, dass der Selbstbereinigungsprozess die ungültige Datenbank überspringt:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Um dieses Problem zu beheben, befolgen Sie den `HINT`, der während des Verbindungsversuchs ausgegeben wurde. Stellen Sie mit Ihrem RDS-Master-Konto oder einem Datenbankkonto mit der `rds_superuser`-Rolle eine Verbindung zu einer gültigen Datenbank her und verwerfen Sie ungültige Datenbanken.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identifizieren und Beheben von Problemen mit Blockern aggressiver Bereinigungen in RDS für PostgreSQL
In PostgreSQL ist die Bereinigung von entscheidender Bedeutung zur Sicherstellung der Integrität der Datenbank, da durch diese Speicherplatz zurückgewonnen wird und Probleme mit [Transaktions-ID-Wraparounds](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) vermieden werden. Manchmal wird eine reibungslose Bereinigung jedoch verhindert, was zu Leistungseinbußen, einem aufgeblähten Speicher und sogar zu einer Beeinträchtigung der Verfügbarkeit Ihrer DB-Instance durch einen Transaktions-ID-Wraparound führen kann. Daher ist die Identifizierung und Lösung dieser Probleme für eine optimale Datenbankleistung und -verfügbarkeit unerlässlich. Lesen Sie [Understanding autovacuum in Amazon RDS für PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/), um mehr über die Selbstbereinigung zu erfahren.
Die `postgres_get_av_diag()`-Funktion hilft bei der Identifizierung von Problemen, die den aggressiven Bereinigungsprozess entweder verhindern oder verzögern. Es werden Vorschläge bereitgestellt, die Befehle zur Behebung des Problems beinhalten können, wenn es identifiziert werden kann, oder Anleitungen für weitere Diagnosen, wenn das Problem nicht identifiziert werden kann. Aggressive Vakuumblocker werden gemeldet, wenn das Alter den [adaptiven Autovakuum-Schwellenwert](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) von 500 Millionen Transaktionen von RDS überschreitet. IDs
**Wie alt ist die Transaktions-ID?**
Die `age()` Transaktionsfunktion IDs berechnet die Anzahl der Transaktionen, die seit der ältesten nicht eingefrorenen Transaktions-ID für eine Datenbank (`pg_database.datfrozenxid`) oder Tabelle () stattgefunden haben. `pg_class.relfrozenxid` Dieser Wert gibt die Datenbankaktivität seit dem letzten aggressiven Bereinigungsvorgang an und zeigt den wahrscheinlichen Workload für bevorstehende VACUUM-Prozesse auf.
**Was ist eine aggressive Bereinigung?**
Eine aggressive VACUUM-Operation führt einen umfassenden Scan aller Seiten innerhalb einer Tabelle durch, einschließlich der Seiten, die normalerweise während der regulären Tabelle übersprungen werden. VACUUMs Dieser gründliche Scan zielt darauf ab, Transaktionen, die IDs sich ihrem Höchstalter nähern, „einzufrieren“ und so eine Situation, die als [Transaktions-ID-Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) bezeichnet wird, effektiv zu verhindern.
Damit `postgres_get_av_diag()` Blocker meldet, muss der Blocker mindestens 500 Millionen Transaktionen alt sein.
**Topics**
+ [Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [Funktionen von postgres\$1get\$1av\$1diag() in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [Beseitigen von identifizierbaren Bereinigungsblockern in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [Beheben von nicht identifizierbaren Bereinigungsblockern in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [Beheben von Leistungsproblemen bei der Bereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [Erläuterung der HINWEIS-Meldungen in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL
Die `postgres_get_av_diag()`-Funktion ist derzeit in den folgenden Versionen von RDS für PostgreSQL verfügbar:
+ 17.2 und höhere 17-Versionen
+ 16.7 und höher 16 Versionen
+ 15.11 und höhere 15-Versionen
+ 14.16 und höhere 14-Versionen
+ 13.19 und höhere 13-Versionen
Um `postgres_get_av_diag()` zu verwenden, erstellen Sie die `rds_tools`-Erweiterung.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Stellen Sie sicher, dass die Erweiterung installiert ist.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Stellen Sie sicher, dass die Funktion erstellt ist.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funktionen von postgres\$1get\$1av\$1diag() in RDS für PostgreSQL
The `postgres_get_av_diag()`-Funktion ruft Diagnoseinformationen über Selbstbereinigungsprozesse ab, die in einer Datenbank von RDS für PostgreSQL blockiert sind oder zeitlich verzögert erfolgen. Die Abfrage muss in der Datenbank mit der ältesten Transaktions-ID ausgeführt werden, damit genaue Ergebnisse geliefert werden. Weitere Informationen zur Verwendung der Datenbank mit der ältesten Transaktions-ID finden Sie unter [Keine Verbindung zur Datenbank mit dem Alter der ältesten Transaktions-ID](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
Die `postgres_get_av_diag()`-Funktion gibt eine Tabelle mit folgenden Informationen zurück:
**blocker**
Gibt die Kategorie der Datenbankaktivität an, die die Selbstbereinigung blockiert
+ [Aktive Anweisung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Leerlauf in Transaktion](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Vorbereitete Transaktion](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Logischer Replikations-Slot](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Lesereplikat mit physischen Replikations-Slots](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Lesereplikat mit Streaming-Replikation](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Temporäre Tabellen](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**Datenbank**
Gibt den Namen der Datenbank an, sofern zutreffend und unterstützt. Dies ist die Datenbank, in der die Aktivität ausgeführt wird und die Selbstbereinigung blockiert oder blockieren wird. Dies ist die Datenbank, zu der Sie eine Verbindung herstellen und für die Sie Maßnahmen ergreifen müssen.
**blocker\$1identifier**
Gibt die ID der Aktivität an, die den Selbstbereinigungsprozess blockiert oder blockieren wird. Bei der ID kann es sich um eine Prozess-ID in Kombination mit einer SQL-Anweisung, einer vorbereiteten Transaktion, einer IP-Adresse einem Lesereplikat und dem Namen des logischen oder physischen Replikationsslots handeln.
**wait\$1event**
Gibt das [Warteereignis](PostgreSQL.Tuning.md) der blockierenden Sitzung an und gilt für die folgenden Blocker:
+ Aktive Anweisung
+ Leerlauf in Transaktion
**autovacum\$1lagging\$1by**
Gibt pro Kategorie die Anzahl der Transaktionen an, bei denen die Selbstbereinigungsfunktion hinsichtlich der Backlog-Arbeiten im Rückstand ist
**-Vorschlag**
Gibt Vorschläge zur Behebung des Blocker-Problems an. Diese Anleitungen enthalten gegebenenfalls den Namen der Datenbank, in der die Aktivität vorhanden ist, gegebenenfalls die Prozess-ID (PID) der Sitzung und die auszuführende Aktion.
**suggested\$1action**
Schlägt die Aktion vor, die ergriffen werden muss, um das Blocker-Problem zu beheben
# Beseitigen von identifizierbaren Bereinigungsblockern in RDS für PostgreSQL
Der Selbstbereinigungsprozess führt aggressive Bereinigungen durch und senkt das Alter der Transaktions-IDs auf einen Wert unterhalb des Schwellenwerts, der durch den `autovacuum_freeze_max_age`-Parameter Ihrer RDS-Instance angegeben ist. Sie können dieses Alter mit der `MaximumUsedTransactionIDs`-Metrik von Amazon CloudWatch nachverfolgen.
Zum Ermitteln der Einstellung von `autovacuum_freeze_max_age` (der Standardwert ist 200 Millionen Transaktions-IDs) für Ihre Amazon-RDS-Instance eignet sich folgende Abfrage:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Beachten Sie, dass `postgres_get_av_diag()` nur dann nach Blockern aggressiver Bereinigungen sucht, wenn das Alter den Schwellenwert für die [adaptive Selbstbereinigung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) von Amazon RDS von 500 Millionen Transaktions-IDs überschreitet. Damit `postgres_get_av_diag()` Blocker erkennt, muss der Blocker mindestens 500 Millionen Transaktionen alt sein.
Die `postgres_get_av_diag()`-Funktion identifiziert die folgenden Arten von Blockern:
**Topics**
+ [Aktive Anweisung](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Leerlauf in Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Vorbereitete Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Logischer Replikations-Slot](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Read Replicas](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Temporäre Tabellen](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Aktive Anweisung
In PostgreSQL ist eine aktive Anweisung eine SQL-Anweisung, die aktuell von der Datenbank ausgeführt wird. Dazu gehören Abfragen, Transaktionen sowie laufende Operationen. Bei der Überwachung mit `pg_stat_activity` wird in der Statusspalte angegeben, dass der Prozess mit der entsprechenden PID aktiv ist.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine Anweisung identifiziert, die inaktiv ist.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Vorgeschlagene Aktion**
Gemäß der Empfehlung in der `suggestion`-Spalte kann der Benutzer eine Verbindung zu der Datenbank herstellen, in der sich die aktive Anweisung befindet. Wie in der `suggested_action`-Spalte angegeben, ist es ratsam, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung sicher ist, können Sie die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen `pg_terminate_backend()`-Berechtigung durchgeführt werden.
**Warnung**
Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat.
## Leerlauf in Transaktion
Eine „idle in transaction“-Anweisung bezieht sich auf jede Sitzung mit einer offenen, expliziten Transaktion (z. B. durch Ausgabe einer `BEGIN`-Anweisung), in der einige Arbeiten ausgeführt wurden und die nun darauf wartet, dass der Client entweder weitere Aufgaben übergibt oder das Ende der Transaktion durch Ausgabe von `COMMIT`, `ROLLBACK` oder `END` signalisiert (was zu einem impliziten `COMMIT` führen würde).
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine `idle in transaction`-Anweisung als Blocker identifiziert.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Vorgeschlagene Aktion**
Wie in der `suggestion`-Spalte angegeben, können Sie eine Verbindung zu der Datenbank mit der „idle in transaction“-Sitzung herstellen und die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Der Benutzer kann Ihr Admin-Benutzer (RDS-Master-Konto) oder ein Benutzer mit der `pg_terminate_backend()`-Berechtigung sein.
**Warnung**
Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat.
## Vorbereitete Transaktion
PostgreSQL ermöglicht Transaktionen, die Teil einer zweiphasigen Commit-Strategie sind, auch bekannt als [vorbereitete Transaktionen](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Diese werden aktiviert, indem der `max_prepared_transactions`-Parameter auf einen Wert ungleich Null gesetzt wird. Vorbereitete Transaktionen sollen sicherstellen, dass eine Transaktion dauerhaft ist und auch nach Datenbankabstürzen, Neustarts oder Verbindungsabbrüchen des Clients verfügbar bleibt. Genau wie reguläre Transaktionen erhalten sie eine Transaktions-ID und können die Selbstbereinigung beeinflussen. Wenn sie im Zustand „vorbereitet“ verbleiben, kann die Selbstbereinigungsfunktion keine Einfrierungen durchführen und es kann zu einem Transaktions-ID-Wraparound kommen.
Wenn Transaktionen auf unbestimmte Zeit in diesem Zustand verbleiben, ohne dass dieser von einem Transaktionsmanager aufgehoben wird, werden sie zu verwaisten vorbereiteten Transaktionen. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, die Transaktion mit den Befehlen `COMMIT PREPARED` oder `ROLLBACK PREPARED` festzuschreiben bzw. rückgängig zu machen.
**Anmerkung**
Beachten Sie, dass ein Backup, das während einer vorbereiteten Transaktion erstellt wurde, diese Transaktion auch nach der Wiederherstellung noch enthält. Sehen Sie sich die folgenden Informationen genauer an, um mehr über das Finden und Beenden solcher Transaktionen zu erfahren.
Die `postgres_get_av_diag()`-Funktion liefert die folgende Ausgabe, wenn sie eine vorbereitete Transaktion als Blocker identifiziert.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Vorgeschlagene Aktion**
Stellen Sie, wie in der Vorschlagsspalte angegeben, eine Verbindung zu der Datenbank her, auf der sich die vorbereitete Transaktion befindet. Prüfen Sie basierend auf der `suggested_action`-Spalte sorgfältig, ob Sie entweder `COMMIT` oder ausführen `ROLLBACK` möchten und welche Aktion dann angemessen ist.
Zur allgemeinen Überwachung vorbereiteter Transaktionen bietet PostgreSQL eine Katalogansicht mit der Bezeichnung `pg_prepared_xacts`. Sie können die folgende Abfrage verwenden, um vorbereitete Transaktionen zu finden.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Logischer Replikations-Slot
Zweck eines Replikations-Slots ist es, nicht genutzte Änderungen so lange aufzubewahren, bis sie auf einen Zielserver repliziert wurden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter [Logische Replikation](https://www.postgresql.org/docs/current/logical-replication.html).
Es gibt zwei Arten von logischen Replikations-Slots.
**Inaktive logische Replikations-Slots**
Wenn die Replikation beendet wird, können nicht genutzte Transaktionsprotokolle nicht entfernt werden und der Replikations-Slot wird inaktiv. Obwohl ein inaktiver logischer Replikations-Slot derzeit nicht von einem Subscriber verwendet wird, verbleibt er auf dem Server, was zur Aufbewahrung von WAL-Dateien führt und verhindert, dass alte Transaktionsprotokolle entfernt werden. Dies kann die Festplattennutzung erhöhen und insbesondere verhindern, dass der Selbstbereinigungsprozess interne Katalogtabellen bereinigt, da das System verhindern muss, dass LSN-Informationen überschrieben werden. Wird dieses Problem nicht behoben, kann das zu einem Aufblähen des Katalogs, zu Leistungseinbußen und zu einem erhöhten Risiko für eine Wraparound-Bereinigung führen, was wiederum Transaktionsausfallzeiten nach sich ziehen kann.
**Aktive, aber langsame logische Replikations-Slots**
Manchmal verzögert sich das Entfernen toter Katalog-Tupel aufgrund von Leistungseinbußen bei der logischen Replikation. Diese Verzögerung bei der Replikation verlangsamt die Aktualisierung von `catalog_xmin`und kann zu einem aufgeblähten Katalog und einer Wraparound-Bereinigung führen.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie einen logischen Replikations-Slot als Blocker identifiziert.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Vorgeschlagene Aktion**
Überprüfen Sie zur Behebung des Problems die Replikationskonfiguration auf Probleme mit dem Zielschema oder Daten, die den Anwendungsprozess möglicherweise beenden. Die häufigsten Gründe sind die folgenden:
+ fehlende Spalten
+ inkompatibler Datentyp
+ nicht übereinstimmende Daten
+ fehlende Tabelle
Wenn das Problem mit Infrastrukturproblemen zusammenhängt:
+ Netzwerkprobleme – [Wie behebe ich Probleme mit einer Amazon-RDS-Datenbank, die sich in einem inkompatiblen Netzwerkstatus befindet?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ Die Datenbank oder DB-Instance ist aus folgenden Gründen nicht verfügbar:
+ Die Replikat-Instance hat keinen Speicherplatz mehr – Sehen Sie unter [Wie behebe ich Probleme, die auftreten, wenn den Amazon-RDS-DB-Instances der Speicherplatz ausgeht?](https://repost.aws/knowledge-center/rds-out-of-storage) nach, um mehr über das Hinzufügen von Speicherplatz zu erfahren.
+ Incompatible-parameters – Sehen Sie unter [Wie behebe ich Fehler bei einer Amazon-RDS-DB-Instance, die im Status „incompatible-parameters“ feststeckt?](https://repost.aws/knowledge-center/rds-incompatible-parameters) nach, um mehr über die Behebung des Problems zu erfahren.
Wenn sich Ihre Instance außerhalb des AWS-Netzwerks oder auf AWS-EC2 befindet, wenden Sie sich an Ihren Administrator, um zu erfahren, wie Sie die Verfügbarkeits- oder Infrastrukturprobleme lösen können.
**Löschen des inaktiven Slots**
**Warnung**
Achtung: Vergewissern Sie sich vor dem Löschen eines Replikations-Slots, dass dieser keine laufende Replikation aufweist, inaktiv ist und sich im Zustand „nicht wiederherstellbar“ befindet. Das vorzeitige Löschen eines Slots kann zu Replikationsunterbrechungen oder Datenverlust führen.
Nachdem Sie sich vergewissert haben, dass der Replikations-Slot nicht mehr benötigt wird, löschen Sie diesen, damit die Selbstbereinigung fortgesetzt werden kann. Die `active = 'f'`-Bedingung sorgt dafür, dass nur ein inaktiver Slot gelöscht wird.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Read Replicas
Wenn die `hot_standby_feedback`-Einstellung für [Lesereplikate von Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md) aktiviert ist, verhindert sie, dass der Selbstbereinigungsprozess auf der primären Datenbank tote Zeilen entfernt, die möglicherweise noch von Abfragen benötigt werden, die auf dem Lesereplikat ausgeführt werden. Dies hat Auswirkungen auf alle Arten von physischen Lesereplikaten, einschließlich solcher, die mit oder ohne Replikations-Slots verwaltet werden. Dieses Verhalten ist notwendig, da Abfragen, die auf dem Standby-Replikat ausgeführt werden, erfordern, dass diese Zeilen auf der primären Datenbank verfügbar bleiben, um [Abfragekonflikte](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) und -abbrüche zu vermeiden.
**Lesereplikat mit physischen Replikations-Slots**
Lesereplikate mit physischen Replikations-Slots verbessern die Zuverlässigkeit und Stabilität der Replikation in RDS für PostgreSQL erheblich. Diese Slots stellen sicher, dass die primäre Datenbank wichtige Write-Ahead-Protokolldateien aufbewahrt, bis das Replikat diese verarbeitet, sodass die Datenkonsistenz auch bei Netzwerkunterbrechungen gewahrt bleibt.
Ab Version 14 von RDS für PostgreSQL verwenden alle Replikate Replikations-Slots. In früheren Versionen wurden Replikations-Slots nur von regionsübergreifenden Replikaten verwendet.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Lesereplikat mit einem physischen Replikations-Slot als Blocker identifiziert.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Lesereplikat mit Streaming-Replikation**
Amazon RDS ermöglicht die Einrichtung von Lesereplikaten ohne physischen Replikations-Slot in älteren Versionen bis Version 13. Dieser Ansatz reduziert den Overhead, da die primäre Datenbank WAL-Dateien aggressiver recyceln kann. Dies ist in Umgebungen mit begrenztem Speicherplatz von Vorteil. Zudem kann ein gelegentlicher ReplicaLag toleriert werden. Ohne Slot muss das Standby-Replikat jedoch synchron bleiben, um zu verhindern, dass WAL-Dateien fehlen. Amazon RDS verwendet archivierte WAL-Dateien, damit das Replikat gegebenenfalls einen Rückstand aufholen kann. Dieser Vorgang ist jedoch möglicherweise langsam und erfordert eine sorgfältige Überwachung.
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Streaming-Lesereplikat als Blocker identifiziert.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Vorgeschlagene Aktion**
Wie in der `suggested_action`-Spalte empfohlen, sollten Sie diese Optionen sorgfältig prüfen, um die Blockierung des Selbstbereinigungsprozesses aufzuheben.
+ **Abfrage beenden** – Gemäß der Empfehlung in der Vorschlagspalte können Sie eine Verbindung zum Lesereplikat herstellen. Laut der suggested\$1action-Spalte empfiehlt es sich jedoch, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung als sicher erachtet wird, können Sie die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen pg\$1terminate\$1backend()-Berechtigung durchgeführt werden.
Sie können den folgenden SQL-Befehl auf dem Lesereplikat ausführen, um die Abfrage zu beenden, die verhindert, dass der Bereinigungsprozess auf der primären Datenbank alte Zeilen löscht. Der Wert von `backend_xmin` wird in der Ausgabe der Funktion gemeldet:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Hot-Standby-Feedback deaktivieren** – Erwägen Sie, den `hot_standby_feedback`-Parameter zu deaktivieren, wenn er zu erheblichen Verzögerungen bei der Bereinigung führt.
Der `hot_standby_feedback`-Parameter ermöglicht einem Lesereplikat, die primäre Datenbank über seine Abfrageaktivität zu informieren. Dadurch wird verhindert, dass diese Tabellen entfernt, die auf dem Standby-Replikat verwendet werden. Dadurch wird zwar die Stabilität der Abfrage auf diesem gewährleistet, die Bereinigung auf der primären Datenbank kann sich jedoch erheblich verzögern. Wenn Sie diese Funktion deaktivieren, kann die Bereinigung auf der primären Datenbank fortgesetzt werden, ohne dass darauf gewartet werden muss, dass das Standby-Replikat aufholt. Dies kann jedoch zu Abfrageabbrüchen oder -fehlern auf dem Standby-Replikat führen, wenn versucht wird, auf Zeilen zuzugreifen, die auf der primären Datenbank bereinigt wurden.
+ **Nicht benötigtes Lesereplikat löschen** – Wenn das Lesereplikat nicht mehr benötigt wird, können Sie es löschen. Dadurch entfällt der damit verbundene Replikations-Overhead und ermöglicht das Recyclen von Transaktionsprotokollen auf der primären Datenbank, ohne vom Replikat zurückgehalten zu werden.
## Temporäre Tabellen
[Temporäre Tabellen](https://www.postgresql.org/docs/current/sql-createtable.html), die mit dem `TEMPORARY`-Schlüsselwort erstellt wurden, befinden sich im temporären Schema, z. B. in pg\$1temp\$1xxx, und sind nur für die Sitzung zugänglich, in der sie erstellt wurden. Temporäre Tabellen werden gelöscht, wenn die Sitzung endet. Diese Tabellen sind jedoch für den Selbstbereinigungsprozess von PostgreSQL unsichtbar und müssen manuell von der Sitzung bereinigt werden, von der sie erstellt wurden. Der Versuch, die temporäre Tabelle von einer anderen Sitzung aus bereinigen zu lassen, hat keine Wirkung.
In seltenen Fällen kann es eine temporäre Tabelle geben, die keiner aktiven Sitzung angehört. Wenn die innehabende Sitzung aufgrund eines fatalen Absturzes, eines Netzwerkproblems oder eines ähnlichen Ereignisses unerwartet beendet wird, wird die temporäre Tabelle möglicherweise nicht bereinigt, sodass sie als „verwaiste“ Tabelle zurückbleibt. Wenn der Selbstbereinigungsprozess von PostgreSQL eine solche verwaiste temporäre Tabelle entdeckt, protokolliert er die folgende Meldung:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine temporäre Tabelle als Blocker identifiziert. Damit die Funktion die Ausgabe in Bezug auf temporäre Tabellen korrekt anzeigt, muss sie auf der Datenbank ausgeführt werden, auf der diese Tabellen vorhanden sind.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Vorgeschlagene Aktion**
Folgen Sie den Anleitungen aus der `suggestion`-Spalte der Ausgabe, um die temporäre Tabelle zu identifizieren und zu entfernen, die die Ausführung des Selbstbereinigungsprozesses verhindert. Verwenden Sie den folgenden Befehl, um die temporäre Tabelle zu löschen, die von `postgres_get_av_diag()` gemeldet wurde. Ersetzen Sie den Tabellennamen auf der Grundlage der von der `postgres_get_av_diag()`-Funktion gelieferten Ausgabe.
```
DROP TABLE my_temp_schema.my_temp_table;
```
Mit der folgenden Abfrage können temporäre Tabellen identifiziert werden:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Beheben von nicht identifizierbaren Bereinigungsblockern in RDS für PostgreSQL
In diesem Abschnitt werden weitere Gründe für ein Verhindern des Fortschritts bei der Bereinigung untersucht. Diese Probleme können derzeit nicht direkt mit der `postgres_get_av_diag()`-Funktion identifiziert werden.
**Topics**
+ [Ungültige Seiten](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Index-Inkonsistenz](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Außergewöhnlich hohe Transaktionsrate](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Ungültige Seiten
Ein Fehler aufgrund einer ungültigen Seite tritt auf, wenn PostgreSQL beim Zugriff auf diese Seite eine Nichtübereinstimmung bei der Prüfsumme dieser Seite feststellt. Der Inhalt ist nicht lesbar, wodurch verhindert wird, dass der Selbstbereinigungsprozess Tupel einfrieren kann. Dadurch wird der Bereinigungsprozess effektiv gestoppt. Der folgende Fehler wird im Protokoll von PostgreSQL erfasst:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Ermitteln des Objekttyps**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Aus der Fehlermeldung geht hervor, dass der `base/16403/186752608`-Pfad die folgenden Informationen bereitstellt:
+ „base“ ist der Verzeichnisname unter dem PostgreSQL-Datenverzeichnis.
+ „16403“ ist die Datenbank-OID, die Sie im `pg_database`-Systemkatalog nachschlagen können.
+ „186752608“ steht für `relfilenode` und kann verwendet werden, um das Schema und den Objektnamen im `pg_class`-Systemkatalog nachzuschlagen.
Indem Sie die Ausgabe der folgenden Abfrage in der betroffenen Datenbank überprüfen, können Sie den Objekttyp ermitteln. Die folgende Abfrage ruft Objektinformationen für diese OID ab: 186752608. Ersetzen Sie die OID durch die OID, die für den aufgetretenen Fehler relevant ist.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Weitere Informationen finden Sie in der PostgreSQL-Dokumentation [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) für alle unterstützten Objekttypen, die in der `relkind`-Spalte in `pg_class` aufgeführt sind.
**Empfehlungen**
Die effektivste Lösung für dieses Problem hängt von der Konfiguration Ihrer spezifischen Amazon-RDS-Instance und der Art der Daten ab, die von der inkonsistenten Seite betroffen sind.
**Wenn der Objekttyp ein Index ist:**
Es wird empfohlen, den Index neu zu erstellen.
+ **Verwenden der `CONCURRENTLY`-Option** – Vor PostgreSQL-Version 12 erforderte die Neuerstellung eines Index eine exklusive Tabellensperre, die den Zugriff auf die Tabelle einschränkte. In PostgreSQL-Version 12 und höheren Versionen ermöglicht die `CONCURRENTLY`-Option das Sperren auf Zeilenebene, wodurch die Verfügbarkeit der Tabelle erheblich verbessert wird. Dies ist der Befehl:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
`CONCURRENTLY` ist zwar weniger störend, kann aber bei stark frequentierten Tabellen langsamer sein. Erwägen Sie, den Index nach Möglichkeit in Zeiten mit geringem Datenverkehr zu erstellen.
Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Verwenden der `INDEX_CLEANUP FALSE`-Option** – Wenn die Indizes groß sind und vermutlich viel Zeit für die Fertigstellung benötigen, können Sie die Blockierung der Selbstbereinigung aufheben, indem Sie einen manuellen `VACUUM FREEZE`-Vorgang ausführen und dabei Indizes ausschließen. Diese Funktionalität ist in PostgreSQL-Version 12 und höheren Versionen verfügbar.
Durch das Umgehen von Indizes können Sie den Bereinigungsprozess des inkonsistenten Index überspringen und das Wraparound-Problem abmildern. Das zugrundeliegende Problem mit der ungültigen Seite wird dadurch jedoch nicht gelöst. Um das Problem mit der ungültigen Seite vollständig zu beheben, müssen Sie den Index dennoch neu erstellen.
**Wenn es sich bei dem Objekttyp um eine materialisierte Ansicht handelt:**
Wenn in einer materialisierten Ansicht ein Fehler aufgrund einer ungültigen Seite auftritt, melden Sie sich bei der betroffenen Datenbank an und aktualisieren Sie sie, um das Problem der ungültige Seite zu beheben:
Aktualisieren Sie die materialisierte Ansicht:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Wenn die Aktualisierung fehlschlägt, versuchen Sie eine Neuerstellung:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Durch das Aktualisieren oder Neuerstellen der materialisierten Ansicht wird sie wiederhergestellt, ohne dass sich dies auf die zugrunde liegenden Tabellendaten auswirkt.
**Für alle anderen Objekttypen:**
Für alle anderen Objekttypen wenden Sie sich an den AWS Support.
## Index-Inkonsistenz
Ein logisch inkonsistenter Index kann verhindern, dass der Selbstbereinigungsprozess voranschreitet. Die folgenden oder ähnliche Fehler werden entweder während der Bereinigungsphase des Index oder beim Zugriff auf den Index durch SQL-Anweisungen protokolliert.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Empfehlungen**
Erstellen Sie den Index neu oder überspringen Sie Indizes mittels `INDEX_CLEANUP` bei einem manuellen `VACUUM FREEZE`. Informationen zur Neuerstellung des Index finden Sie unter [Wenn der Objekttyp ein Index ist](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Verwenden der CONCURRENTLY-Option** – Vor PostgreSQL-Version 12 erforderte die Neuerstellung eines Index eine exklusive Tabellensperre, die den Zugriff auf die Tabelle einschränkte. In PostgreSQL-Version 12 und höheren Versionen ermöglicht die CONCURRENTLY-Option das Sperren auf Zeilenebene, wodurch die Verfügbarkeit der Tabelle erheblich verbessert wird. Dies ist der Befehl:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
CONCURRENTLY ist zwar weniger störend, kann aber bei stark frequentierten Tabellen langsamer sein. Erwägen Sie, den Index nach Möglichkeit in Zeiten mit geringem Datenverkehr zu erstellen. Weitere Informationen finden Sie unter [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) in der *PostgreSQL*-Dokumentation.
+ **Verwenden der INDEX\$1CLEANUP FALSE-Option** – Wenn die Indizes groß sind und vermutlich viel Zeit für die Fertigstellung benötigen, können Sie die Blockierung der Selbstbereinigung aufheben, indem Sie einen manuellen VACUUM-FREEZE-Vorgang ausführen und dabei Indizes ausschließen. Diese Funktionalität ist in PostgreSQL-Version 12 und höheren Versionen verfügbar.
Durch das Umgehen von Indizes können Sie den Bereinigungsprozess des inkonsistenten Index überspringen und das Wraparound-Problem abmildern. Das zugrundeliegende Problem mit der ungültigen Seite wird dadurch jedoch nicht gelöst. Um das Problem mit der ungültigen Seite vollständig zu beheben, müssen Sie den Index dennoch neu erstellen.
## Außergewöhnlich hohe Transaktionsrate
In PostgreSQL können hohe Transaktionsraten die Leistung der Selbstbereinigung erheblich beeinträchtigen, was zu einer langsameren Bereinigung toter Tupel und einem erhöhten Risiko für einen Transaktions-ID-Wraparound führt. Sie können die Transaktionsrate überwachen, indem Sie die Differenz hinsichtlich `max(age(datfrozenxid))` zwischen zwei Zeiträumen, typischerweise pro Sekunde, messen. Darüber hinaus können Sie die folgenden Zählermetriken von RDS Performance Insights verwenden, um die Transaktionsrate (die Summe aus xact\$1commit und xact\$1rollback) zu messen, die die Gesamtzahl der Transaktionen darstellt.
| Zähler | Typ | Einheit | Metrik |
| --- | --- | --- | --- |
| xact\$1commit | Transaktionen | Commits pro Sekunde | db.Transactions.xact\$1commit |
| xact\$1rollback | Transaktionen | Rollbacks pro Sekunde | db.Transactions.xact\$1rollback |
Ein schneller Anstieg deutet auf eine hohe Transaktionslast hin, die den Selbstbereinigungsvorgang überlasten und zu Aufblähungen, Sperrkonflikten und potenziellen Leistungsproblemen führen kann. Dies kann sich auf unterschiedliche Art und Weise negativ auf den Selbstbereinigungsprozess auswirken:
+ **Tabellenaktivität:** Bei der spezifischen Tabelle, die bereinigt wird, kann es zu einem hohen Transaktionsvolumen kommen, was möglicherweise Verzögerungen nach sich zieht.
+ **Systemressourcen:** Das gesamte System ist möglicherweise überlastet, sodass der Selbstbereinigungsprozess möglicherweise nur schwer auf die erforderlichen Ressourcen zugreifen kann, die für eine effiziente Durchführung erforderlich sind.
Ziehen Sie die folgenden Strategien in Betracht, damit der Selbstbereinigungsprozess effektiver verlaufen und seine Aufgaben ohne große Verzögerungen erfüllen kann.
1. Reduzieren Sie nach Möglichkeit die Transaktionsrate. Erwägen Sie, ähnliche Transaktionen nach Möglichkeit zu Stapeln zusammenzufassen oder zu gruppieren.
1. Nehmen Sie häufig aktualisierte Tabellen ins Visier und verlegen Sie deren manuelle nächtliche, wöchentlich oder zweiwöchentliche `VACUUM FREEZE`-Operationen auf Zeiträume außerhalb der Spitzenzeiten.
1. Erwägen Sie, Ihre Instance-Klasse hochzuskalieren, um mehr Systemressourcen für das hohe Transaktionsvolumen und die Selbstbereinigung zur Verfügung zu haben.
# Beheben von Leistungsproblemen bei der Bereinigung in RDS für PostgreSQL
In diesem Abschnitt werden Faktoren erörtert, die häufig zu einer schlechteren Bereinigungsleistung führen. Zudem wird beschrieben, wie diese Probleme behoben werden können.
**Topics**
+ [Bereinigen großer Indizes](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Zu viele Tabellen oder Datenbanken zum Bereinigen](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Bereinigen großer Indizes
Der VACUUM-Prozess durchläuft aufeinanderfolgende Phasen: Initialisierung, Heap-Scanning, Index- und Heap-Bereinigung, Indexsäuberung, Heap-Kürzung und abschließende Bereinigung. Während des Heap-Scans bereinigt der Prozess Seiten, defragmentiert sie und friert sie ein. Nach Abschluss des Heap-Scans bereinigt VACUUM Indizes, gibt leere Seiten an das Betriebssystem zurück und führt abschließende Aufgaben wie das Bereinigen der freien Speicherzuweisung und das Aktualisieren von Statistiken durch.
Das Bereinigen von Indizes kann mehrere Durchläufe erfordern, wenn `maintenance_work_mem` (oder `autovacuum_work_mem`) nicht ausreicht, um den Index zu verarbeiten. In PostgreSQL 16 und früheren Versionen bedingte ein Speicherlimit von 1 GB für das Speichern toter Tupel-IDs häufig mehrere Durchläufe großer Indizes. PostgreSQL 17 führt `TidStore` ein, sodass kein Array mit einer einzelnen Zuweisung verwendet, sondern Speicher dynamisch zugewiesen wird. Dadurch wird die Beschränkung auf 1 GB aufgehoben, der Arbeitsspeicher effizienter genutzt und der Bedarf an mehreren Index-Scans pro Index reduziert.
Große Indizes können in PostgreSQL 17 immer noch mehrere Durchläufe erfordern, wenn der verfügbare Speicher nicht die gesamte Indexverarbeitung auf einmal bewältigen kann. In der Regel enthalten größere Indizes mehr tote Tupel, für die mehrere Durchläufe erforderlich sind.
**Erkennen langsamer Bereinigungsvorgänge**
Die `postgres_get_av_diag()`-Funktion erkennt, wenn Bereinigungsvorgänge aufgrund unzureichenden Speichers langsam ausgeführt werden. Weitere Informationen zu dieser Funktionen finden Sie unter [Installieren von Überwachungs- und Diagnosetools für die Selbstbereinigung in RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
Die `postgres_get_av_diag()`-Funktion gibt die folgenden Hinweise aus, wenn der verfügbare Speicher nicht ausreicht, um die Indexbereinigung in einem einzigen Durchgang abzuschließen.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**Anmerkung**
Die `postgres_get_av_diag()`-Funktion stützt sich auf `pg_stat_all_tables.n_dead_tup`, um die Menge an Speicher zu schätzen, der für die Indexbereinigung benötigt wird.
Wenn die `postgres_get_av_diag()`-Funktion einen langsamen Bereinigungsvorgang feststellt, für den mehrere Index-Scans erforderlich sind, weil `autovacuum_work_mem` nicht ausreicht, wird folgende Meldung generiert:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Empfehlungen**
Sie können die folgenden Abhilfemaßnahmen mittels manuellem `VACUUM FREEZE` anwenden, um das Einfrieren der Tabelle zu beschleunigen.
**Erhöhen des Speichers für die Bereinigung**
Wie von der `postgres_get_av_diag()`-Funktion vorgeschlagen ist es ratsam, den `autovacuum_work_mem`-Parameter zu erhöhen, um möglichen Speicherbeschränkungen auf Instance-Ebene zu begegnen. Zwar ist `autovacuum_work_mem` ein dynamischer Parameter, dennoch muss beachtet werden, dass der Daemon für die Selbstbereinigung seine Worker neu starten muss, damit die neuen Speichereinstellungen wirksam werden. So können Sie dies erreichen:
1. Bestätigen Sie, dass die neue Einstellung festgelegt wurde.
1. Beenden Sie die Prozesse, die derzeit die Selbstbereinigung durchführen.
Dieser Ansatz stellt sicher, dass die angepasste Speicherzuweisung auf neue Selbstbereinigungsvorgänge angewendet wird.
Um unmittelbarere Ergebnisse zu erzielen, sollten Sie erwägen, manuell eine `VACUUM FREEZE`-Operation mit einer höheren `maintenance_work_mem`-Einstellung innerhalb Ihrer Sitzung durchzuführen:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Wenn Sie Amazon RDS verwenden und feststellen, dass Sie zusätzlichen Speicher benötigen, um höhere Werte für `maintenance_work_mem` oder `autovacuum_work_mem` unterstützen zu können, sollten Sie ein Upgrade auf eine Instance-Klasse mit mehr Speicher in Betracht ziehen. Dadurch können die erforderlichen Ressourcen bereitgestellt werden, um sowohl die manuellen als auch die automatischen Bereinigungsvorgänge zu verbessern, was insgesamt zu einer verbesserten Bereinigungs- und Datenbankleistung führt.
**Deaktivieren von INDEX\$1CLEANUP**
Ein manuelles `VACUUM` in PostgreSQL-Version 12 und höher ermöglicht das Überspringen der Indexbereinigungsphase, während die Notfall-Selbstbereinigung in PostgreSQL-Version 14 und höher dies automatisch auf der Grundlage des Parameters [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE) erledigt.
**Warnung**
Das Überspringen der Indexbereinigung kann zu einer Aufblähung des Index führen und sich negativ auf die Abfrageleistung auswirken. Um dem entgegenzuwirken, sollten Sie erwägen, die betroffenen Indizes während eines Wartungsfensters neu zu indizieren oder zu bereinigen.
Weitere Anleitungen zum Umgang mit großen Indizes finden Sie in der Dokumentation zu [Verwalten der automatischen Bereinigung mit großen Indizes](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Parallele Indexbereinigung**
Ab PostgreSQL 13 können Indizes standardmäßig mit manuellem `VACUUM` parallel bereinigt und gesäubert werden, wobei jedem Index ein Bereinigungs-Worker zugewiesen wird. Damit PostgreSQL jedoch feststellen kann, ob ein Bereinigungsvorgang für eine parallele Ausführung infrage kommt, müssen bestimmte Kriterien erfüllt sein:
+ Es müssen mindestens zwei Indizes vorhanden sein.
+ Der `max_parallel_maintenance_workers`-Parameter sollte auf mindestens 2 gesetzt werden.
+ Die Indexgröße muss den `min_parallel_index_scan_size`-Grenzwert überschreiten, der standardmäßig 512 KB beträgt.
Sie können die `max_parallel_maintenance_workers`-Einstellung auf der Grundlage der Anzahl der auf Ihrer Amazon-RDS-Instance verfügbaren vCPUs und der Anzahl der Indizes in der Tabelle anpassen, um die Bearbeitungszeit für das Bereinigen zu optimieren.
Weitere Informationen finden Sie unter [Parallele Selbstbereinigung in Amazon RDS für PostgreSQL und Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Zu viele Tabellen oder Datenbanken zum Bereinigen
Wie in der PostgreSQL-Dokumentation [Der Selbstbereinigungsdaemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') angegeben, durchläuft der Bereinigungsdaemon mehrere Prozesse. Dazu gehört auch ein persistenter Launcher für die Selbstbereinigung, der für das Starten von Selbstbereinigungs-Worker-Prozessen für jede Datenbank innerhalb des Systems verantwortlich ist. Der Launcher plant, dass diese Worker ungefähr alle `autovacuum_naptime` Sekunden pro Datenbank initiiert werden.
Bei „N“ Datenbanken startet ungefähr alle [`autovacuum_naptime`/N Sekunden] ein neuer Worker. Die Gesamtzahl der gleichzeitigen Worker ist jedoch durch die `autovacuum_max_workers`-Einstellung begrenzt. Wenn die Anzahl der Datenbanken oder Tabellen, die bereinigt werden müssen, diesen Grenzwert überschreitet, wird die nächste Datenbank oder Tabelle verarbeitet, sobald ein Worker verfügbar ist.
Wenn viele große Tabellen oder Datenbanken gleichzeitig bereinigt werden müssen, kann es sein, dass alle verfügbaren Bereinigungs-Worker für einen längeren Zeitraum ausgelastet sind, was die Wartung anderer Tabellen und Datenbanken verzögert. In Umgebungen mit hohen Transaktionsraten kann dieser Engpass schnell eskalieren und möglicherweise zu komplexeren Bereinigungsproblemen innerhalb Ihrer Amazon-RDS-Instance führen.
Wenn `postgres_get_av_diag()` eine große Anzahl von Tabellen oder Datenbanken erkennt, wird folgende Empfehlung bereitgestellt:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Empfehlungen**
**Erhöhen von autovacuum\$1max\$1workers**
Um das Bereinigen zu beschleunigen, empfehlen wir, den `autovacuum_max_workers`-Parameter so anzupassen, dass mehr gleichzeitige Worker möglich sind. Wenn weiterhin Leistungsengpässe bestehen, sollten Sie erwägen, Ihre Amazon-RDS-Instance auf eine Klasse mit mehr vCPUs zu skalieren, wodurch die Möglichkeiten der Parallelverarbeitung weiter optimiert werden können.
## Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)
Das Alter der Datenbank (MaximumUsedTransactionIDs) in PostgreSQL nimmt nur ab, wenn erfolgreich eine aggressive Bereinigung (zur Wraparound-Verhinderung) durchgeführt wird. Bis diese Bereinigung beendet ist, wird das Alter je nach Transaktionsrate weiter zunehmen.
Die `postgres_get_av_diag()`-Funktion generiert folgenden `NOTICE`, wenn sie eine aggressive Bereinigung erkennt. Sie löst diese Ausgabe jedoch erst aus, wenn die Bereinigung mindestens zwei Minuten lang aktiv war.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Weitere Informationen zu aggressivem Bereinigungen finden Sie unter [Wenn bereits eine aggressive Bereinigung läuft](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Mit der folgenden Abfrage können Sie überprüfen, ob eine aggressive Bereinigung läuft:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Sie können anhand der Abfragespalte in der Ausgabe feststellen, ob es sich um eine aggressive Bereinigung (zur Wraparound-Verhinderung) handelt. Der Ausdruck „zur Wraparound-Verhinderung“ weist darauf hin, dass es sich um eine aggressive Bereinigung handelt.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Angenommen, Sie haben einen Blocker mit einem Transaktionsalter von 1 Milliarde und eine Tabelle, die eine aggressive Bereinigung erfordert, um einen Wraparound im gleichen Transaktionsalter zu verhindern. Darüber hinaus gibt es einen weiteren Blocker mit einem Transaktionsalter von 750 Millionen. Nach der Aufhebung des Blockers mit einem Transaktionsalter von 1 Milliarde wird das Transaktionsalter nicht sofort auf 750 Millionen sinken. Es wird so lange hoch bleiben, bis die Tabelle, für die die aggressive Bereinigung erforderlich ist, oder eine andere Transaktion mit einem Alter von über 750 Millionen abgeschlossen ist. Während dieses Zeitraums wird das Transaktionsalter Ihres PostgreSQL-Clusters weiter steigen. Sobald der Bereinigungsvorgang abgeschlossen ist, wird das Transaktionsalter auf 750 Millionen sinken, aber es wird wieder steigen, bis das weitere Bereinigen abgeschlossen ist. Dieser Zyklus wird so lange fortgesetzt, wie diese Bedingungen bestehen, bis das Transaktionsalter schließlich auf das für Ihre Amazon-RDS-Instance konfigurierte Niveau fällt, das durch `autovacuum_freeze_max_age` angegeben ist.
# Erläuterung der HINWEIS-Meldungen in RDS für PostgreSQL
Die `postgres_get_av_diag()`-Funktion stellt die folgenden HINWEIS-Meldungen bereit:
**Wenn für das Alter der Überwachungsschwellenwert noch nicht erreicht ist**
Die Überwachungsschwellenwert für `postgres_get_av_diag()` zur Identifizierung von Blockern liegt standardmäßig bei 500 Millionen Transaktionen. Wenn `postgres_get_av_diag()` den folgenden HINWEIS generiert, bedeutet dies, dass das Transaktionsalter diesen Schwellenwert noch nicht erreicht hat.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Keine Verbindung zur Datenbank mit dem Alter der ältesten Transaktions-ID**
Die `postgres_get_av_diag()`-Funktion liefert die genaueste Ausgabe, wenn sie mit der Datenbank mit dem Alter der ältesten Transaktions-ID verbunden ist. Die Datenbank mit dem ältesten von `postgres_get_av_diag()` gemeldeten Transaktions-ID-Alter unterscheidet sich in Ihrem Fall von „my\$1database“. Wenn Sie nicht mit der richtigen Datenbank verbunden sind, wird der folgende HINWEIS generiert:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Aus folgenden Gründen ist es wichtig, eine Verbindung zur Datenbank mit dem ältesten Transaktionsalter herzustellen:
+ **Identifizierung temporärer Tabellenblocker:** Da die Metadaten für temporäre Tabellen für jede Datenbank spezifisch sind, befinden sie sich normalerweise in der Datenbank, in der sie erstellt wurden. Wenn jedoch eine temporäre Tabelle der primäre Blocker ist und sich in der Datenbank mit der ältesten Transaktion befindet, könnte dies zu falschen Annahmen führen. Durch die Verbindung mit der richtigen Datenbank wird die genaue Identifizierung des Blockers für temporäre Tabellen gewährleistet.
+ **Diagnose langsamer Bereinigungen:** Die Index-Metadaten und die Informationen zur Anzahl der Tabellen sind datenbankspezifisch und für die Diagnose von Problemen im Zusammenhang mit langsamen Bereinigungen erforderlich.
**Die Datenbank mit der ältesten Transaktion nach Alter befindet sich in einer rdsadmin- oder template0-Datenbank**
In bestimmten Fällen kann die `rdsadmin`- oder die `template0`-Datenbank als die Datenbank mit dem ältesten Transaktions-ID-Alter identifiziert werden. In diesem Fall gibt `postgres_get_av_diag()` folgenden HINWEIS aus:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Stellen Sie sicher, dass der aufgelistete Blocker nicht aus einer dieser beiden Datenbanken stammt. Wenn gemeldet wird, dass der Blocker in `rdsadmin` oder `template0` vorhanden ist, wenden Sie sich an den Support, da Benutzer nicht auf diese Datenbanken zugreifen können und ein Eingreifen erforderlich ist.
Es ist sehr unwahrscheinlich, dass die `rdsadmin`-Datenbank oder die `template0`-Datenbank einen primären Blocker enthält.
**Wenn bereits eine aggressive Bereinigung läuft**
Die `postgres_get_av_diag()`-Funktion ist so konzipiert, dass sie es meldet, wenn ein aggressiver Bereinigungsprozess läuft, löst diese Ausgabe jedoch erst aus, wenn die Bereinigungsfunktion seit mindestens 1 Minute aktiv ist. Diese absichtliche Verzögerung trägt dazu bei, die Wahrscheinlichkeit falsch-positiver Ergebnisse zu verringern. Durch das Warten stellt die Funktion sicher, dass nur effektive, signifikante Bereinigungen gemeldet werden, was zu einer genaueren und zuverlässigeren Überwachung der Bereinigungsaktivität führt.
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn sie feststellt, dass eine oder mehrere aggressive Bereinigungen laufen.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Wie im HINWEIS angegeben sollten Sie die Leistung der Bereinigung weiterhin überwachen. Mehr über aggressive Bereinigungen erfahren Sie unter [Es läuft eine aggressive Bereinigung (um ein Wraparound zu verhindern)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Wenn die Selbstbereinigung deaktiviert ist**
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn die Selbstbereinigung auf Ihrer Datenbank-Instance deaktiviert ist:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Die Selbstbereinigung ist eine wichtige Funktion Ihrer Instance von RDS für PostgreSQL, die einen reibungslosen Datenbankbetrieb gewährleistet. Sie entfernt automatisch alte Zeilenversionen, fordert Speicherplatz zurück, verhindert ein Aufblähen von Tabellen und trägt so dazu bei, dass Tabellen und Indizes zwecks optimaler Leistung effizient bleiben. Darüber hinaus schützt sie vor einem Transaktions-ID-Wraparound, wodurch Transaktionen auf Ihrer Amazon-RDS-Instance gestoppt werden können. Die Deaktivierung der Selbstbereinigung kann zu langfristigen Einbußen bei der Datenbankleistung und -stabilität führen. Wir empfehlen Ihnen, sie ständig aktiviert zu lassen. Weitere Informationen finden Sie unter [Grundlegendes zur Selbstbereinigung in RDS für PostgreSQL-Umgebungen](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
Durch das Deaktivieren der Selbstbereinigung werden aggressive Bereinigungen nicht gestoppt. Diese treten weiterhin auf, sobald Ihre Tabellen den `autovacuum_freeze_max_age`-Schwellenwert erreichen.
**Die Anzahl der verbleibenden Transaktionen ist äußerst gering**
Die `postgres_get_av_diag()`-Funktion generiert den folgenden HINWEIS, wenn eine Wraparound-Bereinigung unmittelbar bevorsteht. Dieser HINWEIS wird ausgegeben, wenn Ihre Amazon-RDS-Instance 100 Millionen Transaktionen davon entfernt ist, neue Transaktionen möglicherweise abzulehnen.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Ihr sofortiges Handeln ist erforderlich, um Ausfallzeiten der Datenbank zu vermeiden. Sie sollten Ihre Bereinigungsvorgänge genau überwachen und erwägen, manuell einen `VACUUM FREEZE`-Vorgang in der betroffenen Datenbank zu initiieren, um Transaktionsfehler zu vermeiden.
# Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL
PostgreSQL-Einschränkungen sind zwar theoretisch, aber extrem hohe Objektzahlen in einer Datenbank haben spürbare Auswirkungen auf die Leistung verschiedener Operationen. Diese Dokumentation behandelt mehrere gängige Objekttypen, die bei einer hohen Gesamtzahl zu mehreren möglichen Auswirkungen führen können.
Die folgende Tabelle enthält eine Zusammenfassung der Objekttypen und ihrer möglichen Auswirkungen:
**Objekttypen und mögliche Auswirkungen**
| Art des Objekts | Autovakuum | Logische Replikation | Upgrade einer Hauptversion | pg\$1dump//pg\$1restore | Allgemeine Leistung | Neustart der Instanz |
| --- | --- | --- | --- | --- | --- | --- |
| [Beziehungen](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Temporäre Tabellen](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Nicht protokollierte Tabellen](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partitionen](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Temporäre Dateien](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Sequenzen](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Große Objekte](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relationen
Es gibt kein bestimmtes festes Limit für die Anzahl der Tabellen in einer PostgreSQL-Datenbank. Die theoretische Grenze ist extrem hoch, aber es gibt noch andere praktische Grenzen, die beim Datenbankentwurf berücksichtigt werden müssen.
**Auswirkung: Autovacuum gerät ins Hintertreffen**
Autovacuum kann Schwierigkeiten haben, mit dem Wachstum der Transaktions-IDs Schritt zu halten, oder es kann sein, dass die Tabelle aufgrund des Mangels an Mitarbeitern im Verhältnis zum Arbeitsaufwand überfüllt wird.
**Empfohlene Maßnahme:** Es gibt mehrere Faktoren, um Autovacuum so einzustellen, dass es mit einer bestimmten Anzahl von Tabellen und einer bestimmten Arbeitslast Schritt hält. Vorschläge [zur Festlegung geeigneter Autovacuum-Einstellungen finden Sie unter Bewährte Methoden für die Arbeit mit PostgreSQL-Autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) .
**Auswirkung: Upgrade der Hauptversion//pg\$1dump und Wiederherstellung**
Amazon RDS verwendet während der Ausführung von pg\$1upgrade die Option „--link“, um zu vermeiden, dass Kopien von Datendateien erstellt werden müssen. Die Schema-Metadaten müssen dennoch in der neuen Version der Datenbank wiederhergestellt werden. Selbst bei parallelem pg\$1restore erhöht dies die Ausfallzeit, wenn es eine beträchtliche Anzahl von Beziehungen gibt.
**Auswirkung: Allgemeiner Leistungsabfall**
Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Jede Tabelle und die zugehörigen Spalten werden zu `pg_depend` Tabellen hinzugefügt`pg_attribute`, `pg_class` die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.
**Empfohlene Maßnahme:** Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine `VACUUM FULL` Überprüfung dieser spezifischen Tabellen durch. Beachten Sie, dass `VACUUM FULL` für Katalogtabellen eine `ACCESS EXCLUSIVE` Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.
**Auswirkung: Erschöpfung des Dateideskriptors**
Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter `max_files_per_process` bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.
**Empfohlene Maßnahme:**
+ Wenn Sie den Wert des Parameters verringern, `max_files_per_process` kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.
+ Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html), oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie [PgBouncer auf der Website](https://www.pgbouncer.org/).
**Auswirkung: Inode-Erschöpfung**
Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.
**[Ungefährer Schwellenwert: Millionen](#PostgreSQL.HighObjectCount.Note)**
## Temporäre Tabellen
Die Verwendung temporärer Tabellen ist nützlich für Testdaten oder Zwischenergebnisse und ist ein gängiges Muster, das in vielen Datenbank-Engines zu finden ist. Die Auswirkungen der starken Nutzung von PostgreSQL müssen verstanden werden, um einige der Fallstricke zu vermeiden. Bei jedem Erstellen und Löschen temporärer Tabellen werden den Systemkatalogtabellen Zeilen hinzugefügt, was zu allgemeinen Leistungsproblemen führt, wenn sie aufgebläht werden.
**Auswirkung: Autovacuum gerät ins Hintertreffen**
Temporäre Tabellen werden nicht automatisch gelöscht, sondern speichern Transaktionen IDs , solange sie existieren. Wenn sie nicht entfernt werden, kann es zu einem Wraparound kommen.
**Empfohlene Maßnahme:** Temporäre Tabellen bleiben für die Dauer der Sitzung bestehen, in der sie erstellt wurden, oder können manuell gelöscht werden. Eine bewährte Methode zur Vermeidung lang andauernder Transaktionen mit temporären Tabellen verhindert, dass diese Tabellen zum Anstieg der maximal genutzten Transaktions-IDs beitragen.
**Auswirkung: Allgemeiner Leistungsabfall**
Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Wenn Sitzungen kontinuierlich temporäre Tabellen erstellen und löschen, werden `pg_depend` Tabellen hinzugefügt`pg_attribute`, `pg_class` die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.
**Empfohlene Maßnahme:**
+ Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine `VACUUM FULL` Prüfung für diese spezifischen Tabellen durch. Beachten Sie, dass `VACUUM FULL` für Katalogtabellen eine `ACCESS EXCLUSIVE` Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.
+ Wenn temporäre Tabellen stark genutzt werden, wird vor einem Upgrade einer Hauptversion dringend empfohlen, eine `VACUUM FULL` dieser speziellen Katalogtabellen zu verwenden, um Ausfallzeiten zu reduzieren.
**Allgemeine bewährte Methoden:**
+ Reduzieren Sie die Verwendung temporärer Tabellen, indem Sie allgemeine Tabellenausdrücke verwenden, um Zwischenergebnisse zu erzielen. Diese können manchmal die erforderlichen Abfragen verkomplizieren, verhindern jedoch die oben aufgeführten Auswirkungen.
+ Verwenden Sie temporäre Tabellen erneut, indem Sie den `TRUNCATE` Befehl verwenden, um den Inhalt zu löschen, anstatt drop/create Schritte auszuführen. Dadurch wird auch das Problem des durch temporäre Tabellen verursachten Wachstums der Transaktions-IDs behoben.
**Ungefährer Schwellenwert:** [Zehntausende](#PostgreSQL.HighObjectCount.Note)
## Nicht protokollierte Tabellen
Nicht protokollierte Tabellen können Leistungssteigerungen bieten, da sie keine WAL-Informationen generieren. Sie müssen vorsichtig verwendet werden, da sie bei der Wiederherstellung nach einem Datenbankabsturz keine Beständigkeit bieten, da sie gekürzt werden. Dies ist eine teure Operation in PostgreSQL, da jede nicht protokollierte Tabelle seriell gekürzt wird. Dieser Vorgang ist zwar bei einer geringen Anzahl nicht protokollierter Tabellen schnell, kann aber bei Tausenden von Tabellen zu erheblichen Verzögerungen beim Start führen.
**Auswirkung: Logische Replikation**
Nicht protokollierte Tabellen sind im Allgemeinen nicht in der logischen Replikation enthalten, einschließlich [Blue/Green-Bereitstellungen ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), da die logische Replikation zur Erfassung und Übertragung von Änderungen auf der WAL basiert.
**Auswirkung: Verlängerte Ausfallzeit während der Wiederherstellung**
Bei jedem Datenbankstatus, der eine Wiederherstellung nach einem Datenbankabsturz beinhaltet, wie z. B. Multi-AZ-Neustart mit Failover, Amazon point-in-time RDS-Wiederherstellung und Amazon RDS-Hauptversions-Upgrade, erfolgt der serialisierte Vorgang, bei dem die nicht protokollierten Tabellen gekürzt werden. Dies kann zu wesentlich höheren Ausfallzeiten als erwartet führen.
**Empfohlene Maßnahme:**
+ Beschränken Sie die Verwendung nicht protokollierter Tabellen auf Daten, deren Verlust bei der Wiederherstellung nach einem Datenbankabsturz akzeptabel ist.
+ Reduzieren Sie die Verwendung von Tabellen, die nicht protokolliert wurden, da das derzeitige Verhalten der seriellen Kürzung dazu führen kann, dass der Start einer Datenbank viel Zeit in Anspruch nimmt.
**Allgemeine bewährte Methoden:**
+ Nicht protokollierte Tabellen sind nicht absturzsicher. Das Initiieren einer point-in-time Wiederherstellung, die eine Wiederherstellung nach einem Absturz beinhaltet, nimmt in PostgreSQL viel Zeit in Anspruch, da es sich um einen seriellen Prozess handelt, bei dem jede Tabelle gekürzt wird.
**[Ungefährer](#PostgreSQL.HighObjectCount.Note)** Schwellenwert: Tausende
## Partitionen
Durch Partitionierung kann die Abfrageleistung erhöht und eine logische Organisation der Daten ermöglicht werden. Im Idealfall ist die Partitionierung so organisiert, dass das Bereinigen von Partitionen bei der Planung und Ausführung von Abfragen verwendet werden kann. Die Verwendung zu vieler Partitionen kann sich negativ auf die Abfrageleistung und die Datenbankwartung auswirken. Die Wahl, wie eine Tabelle partitioniert werden soll, sollte sorgfältig getroffen werden, da die Leistung der Abfrageplanung und -ausführung durch einen schlechten Entwurf negativ beeinflusst werden kann. Einzelheiten zur Partitionierung finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Auswirkung: Allgemeiner Leistungsabfall**
Manchmal nimmt der Zeitaufwand für die Planung zu und die Erläuterung der Pläne für Ihre Abfragen wird komplizierter, sodass es schwierig wird, Optimierungsmöglichkeiten zu identifizieren. Bei PostgreSQL-Versionen vor 18 können viele Partitionen mit hoher Arbeitslast zu `LWLock:LockManager` Wartezeiten führen.
**Empfohlene Maßnahme:** Legen Sie eine Mindestanzahl von Partitionen fest, die es Ihnen ermöglicht, sowohl die Organisation Ihrer Daten abzuschließen als auch gleichzeitig eine performante Abfrageausführung zu gewährleisten.
**Auswirkung: Komplexität der Wartung**
Eine sehr hohe Anzahl von Partitionen führt zu Wartungsschwierigkeiten wie der Erstellung und Entfernung vor der Erstellung und Entfernung. Autovacuum behandelt Partitionen wie normale Relationen und muss regelmäßige Säuberungen durchführen, weshalb genügend Mitarbeiter erforderlich sind, um die Aufgabe zu erledigen.
**Empfohlene Maßnahme:**
+ Stellen Sie sicher, dass Sie Partitionen vorab erstellen, damit die Arbeitslast nicht blockiert wird, wenn eine neue Partition benötigt wird (z. B. monatliche Partitionen) und alte Partitionen gelöscht werden.
+ Stellen Sie sicher, dass Sie über genügend Autovacuum-Mitarbeiter verfügen, um die normale Säuberung und Wartung aller Partitionen durchzuführen.
**Ungefährer Schwellenwert**[: Hunderte](#PostgreSQL.HighObjectCount.Note)
## Temporäre Dateien
Im Gegensatz zu den oben genannten temporären Tabellen werden temporäre Dateien von PostgreSQL erstellt, wenn eine komplexe Abfrage mehrere Sortier- oder Hashoperationen gleichzeitig ausführt, wobei jede Operation Instanzspeicher verwendet, um Ergebnisse bis zu dem `work_mem` im Parameter angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Weitere Informationen zu [temporären Dateien](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) finden Sie unter . Wenn Ihr Workload eine große Anzahl dieser Dateien generiert, kann dies verschiedene Auswirkungen haben.
**Auswirkung: Erschöpfung des Dateideskriptors**
Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter `max_files_per_process` bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.
**Empfohlene Maßnahme:**
+ Wenn Sie den Wert des Parameters verringern, `max_files_per_process` kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.
+ Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie [PgBouncer auf der Website](https://www.pgbouncer.org/).
**Auswirkung: Inode-Erschöpfung**
Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.
**Allgemeine bewährte Methoden:**
+ Überwachen Sie die Nutzung Ihrer temporären Dateien mit [Performance Insights ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Optimieren Sie Abfragen, die umfangreiche temporäre Dateien generieren, um festzustellen, ob es möglich ist, die Gesamtzahl der temporären Dateien zu reduzieren.
**[Ungefährer Schwellenwert: Tausende](#PostgreSQL.HighObjectCount.Note)**
## Sequenzen
Sequenzen sind das zugrunde liegende Objekt, das für die automatische Inkrementierung von Spalten in PostgreSQL verwendet wird. Sie bieten Einzigartigkeit und einen Schlüssel für die Daten. Diese können für einzelne Tabellen verwendet werden, ohne dass dies im normalen Betrieb Auswirkungen hat, mit einer Ausnahme der logischen Replikation.
In PostgreSQL repliziert die logische Replikation derzeit den aktuellen Wert einer Sequenz auf keinen Abonnenten. Weitere Informationen finden Sie auf der [Seite Einschränkungen in der PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Auswirkung: Verlängerte Switchover-Zeit**
Wenn Sie [Amazon RDS Blue/Green Deployments ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) für jede Art von Konfigurationsänderung oder Upgrade verwenden möchten, ist es wichtig, die Auswirkungen einer hohen Anzahl von Sequenzen auf den Switchover zu verstehen. In einer der letzten Phasen eines Switchovers wird der aktuelle Wert der Sequenzen synchronisiert, und wenn es mehrere Tausend gibt, verlängert sich dadurch die Gesamtswitchover-Zeit.
**Empfohlene Maßnahme:** Wenn Ihre Datenbank-Arbeitslast die Verwendung einer gemeinsamen UUID anstelle eines sequence-per-table Ansatzes zulassen würde, würde dies den Synchronisationsschritt während eines Switchovers reduzieren.
**Ungefährer Schwellenwert**[: Tausende](#PostgreSQL.HighObjectCount.Note)
## Große Objekte
Große Objekte werden in einer einzigen Systemtabelle namens pg\$1largeobject gespeichert. Jedes große Objekt hat auch einen Eintrag in der Systemtabelle pg\$1largeobject\$1metadata. Diese Objekte werden ganz anders erstellt, geändert und bereinigt als Standardbeziehungen. Große Objekte werden nicht mit Autovakuumverfahren behandelt und müssen in regelmäßigen Abständen mit einem separaten Verfahren, dem sogenannten Vacuumlo, gereinigt werden. Beispiele zur Verwaltung großer Objekte finden Sie unter Verwaltung großer Objekte mit dem Modul lo.
**Auswirkung: Logische Replikation**
Große Objekte werden derzeit während der logischen Replikation nicht in PostgreSQL repliziert. Weitere Informationen finden Sie auf der [Seite Einschränkungen in der PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). In einer [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) bedeutet dies, dass große Objekte in der blauen Umgebung nicht in die grüne Umgebung repliziert werden.
**Auswirkung: Upgrade der Hauptversion**
Bei einem Upgrade kann der Arbeitsspeicher knapp werden und es kann fehlschlagen, wenn Millionen großer Objekte vorhanden sind und die Instanz diese während eines Upgrades nicht verarbeiten kann. Der Upgrade-Prozess für die PostgreSQL-Hauptversion besteht aus zwei großen Phasen: dem Dumping des Schemas über pg\$1dump und dem Wiederherstellen über pg\$1restore. Wenn Ihre Datenbank Millionen großer Objekte enthält, müssen Sie sicherstellen, dass Ihre Instanz über ausreichend Speicher verfügt, um pg\$1dump und pg\$1restore während eines Upgrades zu verarbeiten, und sie auf einen größeren Instanztyp skalieren.
**Allgemeine bewährte Methoden:**
+ Verwenden Sie regelmäßig das Programm vacuumlo, um eventuell verwaiste große Objekte zu entfernen.
+ Erwägen Sie, den BYTEA-Datentyp zum Speichern Ihrer großen Objekte in der Datenbank zu verwenden.
**Ungefährer Schwellenwert**[: Millionen](#PostgreSQL.HighObjectCount.Note)
## Ungefähre Schwellenwerte
Die in diesem Thema genannten ungefähren Schwellenwerte werden nur verwendet, um abzuschätzen, wie weit eine bestimmte Ressource skaliert werden kann. Sie stellen den allgemeinen Bereich dar, in dem die beschriebenen Auswirkungen wahrscheinlicher werden. Das tatsächliche Verhalten hängt jedoch von Ihrer spezifischen Arbeitslast, Instanzgröße und Konfiguration ab. Auch wenn es möglich sein kann, diese Schätzungen zu übertreffen, müssen Sorgfalt und Wartung eingehalten werden, um die aufgeführten Auswirkungen zu vermeiden.
#
TOAST (The Oversized-Attribute Storage Technique) ist eine PostgreSQL-Funktion, die für die Verarbeitung großer Datenwerte entwickelt wurde, die die typische Datenbankblockgröße von 8 KB überschreiten. PostgreSQL erlaubt nicht, dass sich physische Zeilen über mehrere Blöcke erstrecken. Die Blockgröße dient als Obergrenze für die Zeilengröße. TOAST überwindet diese Einschränkung, indem große Feldwerte in kleinere Blöcke aufgeteilt werden. Es speichert sie separat in einer speziellen TOAST-Tabelle, die mit der Haupttabelle verknüpft ist. Weitere Informationen finden Sie in der Dokumentation zum [PostgreSQL TOAST-Speichermechanismus und](https://www.postgresql.org/docs/current/storage-toast.html) zur Implementierung.
**Topics**
+ [TOAST-Operationen verstehen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [Identifizierung von Leistungsherausforderungen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [Empfehlungen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [Überwachen](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## TOAST-Operationen verstehen
TOAST führt eine Komprimierung durch und speichert große Feldwerte außerhalb der Zeile. TOAST weist jedem Block übergroßer Daten, die in der TOAST-Tabelle gespeichert sind, eine eindeutige OID (Object Identifier) zu. Die Haupttabelle speichert die TOAST-Wert-ID und die Beziehungs-ID auf der Seite, um auf die entsprechende Zeile in der TOAST-Tabelle zu verweisen. Dadurch kann PostgreSQL diese TOAST-Chunks effizient lokalisieren und verwalten. Wenn die TOAST-Tabelle jedoch wächst, besteht die Gefahr, dass das System die verfügbaren OIDs Ressourcen ausschöpft, was sowohl zu Leistungseinbußen als auch zu potenziellen Ausfallzeiten aufgrund der OID-Erschöpfung führt.
### Objektkennungen in TOAST
Ein Object Identifier (OID) ist ein systemweiter eindeutiger Identifier, der von PostgreSQL verwendet wird, um Datenbankobjekte wie Tabellen, Indizes und Funktionen zu referenzieren. Diese Identifikatoren spielen eine wichtige Rolle bei den internen Vorgängen von PostgreSQL und ermöglichen es der Datenbank, Objekte effizient zu lokalisieren und zu verwalten.
Für Tabellen mit Datensätzen, die für das Toasten in Frage kommen, weist PostgreSQL jedem übergroßen Datenblock, der in der zugehörigen TOAST-Tabelle gespeichert ist, eine eindeutige Identifizierung OIDs zu. Das System verknüpft jeden Chunk mit einem`chunk_id`, was PostgreSQL hilft, diese Chunks effizient in der TOAST-Tabelle zu organisieren und zu lokalisieren.
## Identifizierung von Leistungsherausforderungen
Das OID-Management von PostgreSQL stützt sich auf einen globalen 32-Bit-Zähler, sodass es nach der Generierung von 4 Milliarden eindeutigen Werten einen Umbruch durchführt. Der Datenbank-Cluster teilt sich diesen Zähler, aber die OID-Zuweisung umfasst bei TOAST-Vorgängen zwei Schritte:
+ **Globaler Zähler für die Zuweisung** — Der globale Zähler weist dem gesamten Cluster eine neue OID zu.
+ **Lokale Suche nach Konflikten** — Die TOAST-Tabelle stellt sicher, dass die neue OID nicht mit der in dieser bestimmten Tabelle OIDs bereits verwendeten OID in Konflikt steht.
Leistungseinbußen können auftreten, wenn:
+ Die TOAST-Tabelle weist eine hohe Fragmentierung oder eine hohe OID-Auslastung auf, was zu Verzögerungen bei der Zuweisung der OID führt.
+ OIDs In Umgebungen mit hoher Datenfluktuation oder großen Tabellen, in denen TOAST häufig verwendet wird, werden vom System häufig Zuweisungen vorgenommen und wiederverwendet.
Weitere Informationen finden Sie in der Dokumentation zur [PostgreSQL-TOAST-Tabellengröße und zur OID-Zuweisung](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit):
Ein globaler Zähler generiert die Werte OIDs und schließt sie etwa alle 4 Milliarden ab, sodass das System von Zeit zu Zeit erneut einen bereits verwendeten Wert generiert. PostgreSQL erkennt das und versucht es erneut mit der nächsten OID. Ein langsames INSERT kann auftreten, wenn es eine sehr lange Reihe von verwendeten OID-Werten ohne Lücken in der TOAST-Tabelle gibt. Diese Probleme werden immer ausgeprägter, je größer der OID-Speicherplatz ist, was zu langsameren Einfügungen und Aktualisierungen führt.
### Identifizierung des Problems
+ Einfache `INSERT` Aussagen dauern auf inkonsistente und zufällige Weise deutlich länger als gewöhnlich.
+ Verzögerungen treten nur bei `INSERT` und bei `UPDATE` Anweisungen auf, die TOAST-Operationen beinhalten.
+ Die folgenden Protokolleinträge erscheinen in PostgreSQL-Protokollen, wenn das System Schwierigkeiten hat, verfügbare OIDs TOAST-Tabellen zu finden:
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights weist auf eine hohe Anzahl von durchschnittlichen aktiven Sitzungen (AAS) hin, die mit Ereignissen verknüpft sind `LWLock:buffer_io` und `LWLock:OidGenLock` warten.
Sie können die folgende SQL-Abfrage ausführen, um lang andauernde INSERT-Transaktionen mit Warteereignissen zu identifizieren:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Beispiel für Abfrageergebnisse, die INSERT-Operationen mit längeren Wartezeiten anzeigen:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Das Problem isolieren
+ **Test small insert — Fügt** einen Datensatz ein, der kleiner als der `toast_tuple_target` Schwellenwert ist. Denken Sie daran, dass die Komprimierung vor der TOAST-Speicherung angewendet wird. Wenn dies ohne Leistungsprobleme funktioniert, hängt das Problem mit TOAST-Vorgängen zusammen.
+ **Neue Tabelle testen** — Erstellen Sie eine neue Tabelle mit derselben Struktur und fügen Sie einen Datensatz ein, der größer als `toast_tuple_target` ist. Wenn das ohne Probleme funktioniert, ist das Problem auf die OID-Zuordnung der Originaltabelle beschränkt.
## Empfehlungen
Die folgenden Lösungsansätze können dabei helfen, Probleme mit TOAST-OID-Konflikten zu lösen.
+ **Datenbereinigung und Archivierung** — Überprüfen und löschen Sie alle veralteten oder unnötigen Daten, um sie OIDs für die future Verwendung freizugeben, oder archivieren Sie sie. Erwägen Sie die folgenden Einschränkungen:
+ Eingeschränkte Skalierbarkeit, da eine future Bereinigung möglicherweise nicht immer möglich ist.
+ Möglicher lang andauernder VACUUM-Vorgang, um die resultierenden toten Tupel zu entfernen.
+ In **eine neue Tabelle schreiben** — Erstellen Sie eine neue Tabelle für future Einfügungen und verwenden Sie eine `UNION ALL` Ansicht, um alte und neue Daten für Abfragen zu kombinieren. In dieser Ansicht werden die kombinierten Daten aus alten und neuen Tabellen dargestellt, sodass Abfragen auf sie als eine einzige Tabelle zugreifen können. Erwägen Sie die folgenden Einschränkungen:
+ Aktualisierungen der alten Tabelle können immer noch zu einer Überlastung der OID führen.
+ **Partition oder Shard** — Partitionieren Sie die Tabellen- oder Shard-Daten, um die Skalierbarkeit und Leistung zu verbessern. Erwägen Sie die folgenden Einschränkungen:
+ Höhere Komplexität bei der Abfragelogik und Wartung, potenzielle Notwendigkeit von Anwendungsänderungen, um partitionierte Daten korrekt verarbeiten zu können.
## Überwachen
### Verwendung von Systemtabellen
Sie können die Systemtabellen von PostgreSQL verwenden, um das Wachstum der OID-Nutzung zu überwachen.
**Warnung**
Je nach Anzahl der Einträge OIDs in der TOAST-Tabelle kann es einige Zeit dauern, bis der Vorgang abgeschlossen ist. Wir empfehlen, die Überwachung außerhalb der Geschäftszeiten einzuplanen, um die Auswirkungen zu minimieren.
Der folgende anonyme Block zählt die Anzahl der in jeder TOAST-Tabelle OIDs verwendeten Zeichen und zeigt die Informationen zur übergeordneten Tabelle an:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Beispielausgabe mit OID-Nutzungsstatistiken nach TOAST-Tabelle:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Der folgende anonyme Block ruft die maximal zugewiesene OID für jede nicht leere TOAST-Tabelle ab:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Beispielausgabe, die den maximalen Teil für TOAST-Tabellen IDs anzeigt:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Verwendung von Performance-Insights
Die Warteereignisse `LWLock:buffer_io` `LWLock:OidGenLock` werden in Performance Insights bei Vorgängen angezeigt, für die neue Objektkennungen () OIDs zugewiesen werden müssen. High Average Active Sessions (AAS) für diese Ereignisse deuten in der Regel auf Konflikte bei der OID-Zuweisung und der Ressourcenverwaltung hin. Dies ist besonders häufig in Umgebungen mit hoher Datenfluktuation, umfangreicher Datennutzung oder häufiger Objekterstellung der Fall.
#### LWLockDies ist besonders häufig in Umgebungen mit hoher Datenfluktuation, umfangreicher Datennutzung oder häufiger Objekterstellung der Fall. ----sep----:buffer\$1io
`LWLock:buffer_io`ist ein Wartungsereignis, das auftritt, wenn eine PostgreSQL-Sitzung auf den Abschluss von I/O Vorgängen in einem gemeinsam genutzten Puffer wartet. Dies passiert normalerweise, wenn die Datenbank Daten von der Festplatte in den Speicher liest oder geänderte Seiten vom Speicher auf die Festplatte schreibt. Das `BufferIO` Wait-Ereignis gewährleistet Konsistenz, indem es verhindert, dass mehrere Prozesse während laufender I/O Operationen auf denselben Puffer zugreifen oder ihn ändern. Ein häufiges Auftreten dieses Warteereignisses kann auf Festplattenengpässe oder übermäßige I/O Aktivität bei der Datenbank-Arbeitslast hinweisen.
Während TOAST-Vorgängen:
+ PostgreSQL weist OIDs große Objekte zu und stellt deren Einzigartigkeit sicher, indem es den Index der TOAST-Tabelle scannt.
+ Große TOAST-Indizes erfordern möglicherweise den Zugriff auf mehrere Seiten, um die Eindeutigkeit der OID zu überprüfen. Dies führt zu mehr Festplatten-E/A, insbesondere wenn der Pufferpool nicht alle erforderlichen Seiten zwischenspeichern kann.
Die Größe des Indexes wirkt sich direkt auf die Anzahl der Pufferseiten aus, auf die während dieser Operationen zugegriffen werden muss. Selbst wenn der Index nicht aufgebläht ist, kann seine bloße Größe die Puffer-I/O erhöhen, insbesondere in Umgebungen mit hoher Parallelität oder hoher Kundenabwanderung. [Weitere Informationen finden Sie unter: Anleitung zur Fehlerbehebung bei BufferiO-WarteereignissenLWLock.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)
#### LWLock:OidGenLock
`OidGenLock`ist ein Wartungsereignis, das auftritt, wenn eine PostgreSQL-Sitzung darauf wartet, einen neuen Objektbezeichner (OID) zuzuweisen. Diese Sperre stellt sicher, dass OIDs sie sequentiell und sicher generiert werden, sodass jeweils nur ein Prozess generiert OIDs werden kann.
Während TOAST-Vorgängen:
+ **OID-Zuweisung für Chunks in der TOAST-Tabelle** — PostgreSQL weist Chunks in TOAST-Tabellen OIDs zu, wenn große Datensätze verwaltet werden. Jede OID muss eindeutig sein, um Konflikte im Systemkatalog zu vermeiden.
+ **Hohe Parallelität** — Da der Zugriff auf den OID-Generator sequentiell erfolgt, kann es zu Konflikten kommen, wenn mehrere Sitzungen gleichzeitig Objekte erstellen OIDs, die dies erfordern. `OidGenLock` Dies erhöht die Wahrscheinlichkeit, dass Sitzungen auf den Abschluss der OID-Zuweisung warten.
+ **Abhängigkeit vom Systemkatalogzugriff** — Für die Zuweisung OIDs sind Aktualisierungen der gemeinsam genutzten Systemkatalogtabellen wie `pg_class` und `pg_type` erforderlich. Wenn diese Tabellen stark beansprucht werden (aufgrund häufiger DDL-Operationen), kann sich der Sperrkonflikt für erhöhen. `OidGenLock`
+ **Hohe Nachfrage nach OID-Zuweisungen** — TOAST-Arbeitslasten mit großen Datensätzen erfordern eine konstante OID-Zuweisung, was zu mehr Konflikten führt.
Zusätzliche Faktoren, die den OID-Konflikt erhöhen:
+ **Häufige Objekterstellung** — Workloads, bei denen häufig Objekte erstellt und gelöscht werden, wie z. B. temporäre Tabellen, verstärken den Konflikt auf dem globalen OID-Zähler.
+ **Globales Sperren von Leistungsindikatoren** — Auf den globalen OID-Zähler wird seriell zugegriffen, um die Eindeutigkeit sicherzustellen, wodurch in Umgebungen mit hoher Parallelität ein einziger Streitpunkt entsteht.
## Arbeiten mit Protokollierungsmechanismen, die von RDS für PostgreSQL unterstützt werden
Es gibt mehrere Parameter, Erweiterungen und andere konfigurierbare Elemente, die Sie festlegen können, um Aktivitäten zu protokollieren, die auf Ihrer PostgreSQL-DB-Instance auftreten. Diese umfassen u. a. folgende:
+ Der Parameter `log_statement` kann verwendet werden, um in Ihrer PostgreSQL-Datenbank Benutzeraktivitäten zu protokollieren. Weitere Informationen über RDS für PostgreSQL-Protokollierung und zur Überwachung der Protokolle finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
+ Der Parameter `rds.force_admin_logging_level` protokolliert Aktionen durch den internen Amazon-RDS-Benutzer (rdsadmin) in den Datenbanken in der DB-Instance. Die Ausgabe wird in das PostgreSQL-Fehlerprotokoll geschrieben. Zulässige Werte sind `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, Protokoll, `fatal` und `panic`. Der Standardwert ist `disabled`.
+ Der `rds.force_autovacuum_logging_level`-Parameter kann festgelegt werden, um verschiedene Selbstbereinigungsoperationen im PostgreSQL-Fehlerprotokoll zu erfassen. Weitere Informationen finden Sie unter [Protokollieren von Selbstbereinigung- und Bereinigungsaktivitäten](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ Die PostgreSQL Audit (pgAudit)-Erweiterung kann installiert und konfiguriert werden, um Aktivitäten auf Sitzungsebene oder auf Objektebene zu erfassen. Weitere Informationen finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Die `log_fdw`-Erweiterung ermöglicht es Ihnen, über SQL auf das Datenbank-Engine-Protokoll zuzugreifen. Weitere Informationen 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).
+ Die `pg_stat_statements`-Bibliothek ist als Standardwert für den `shared_preload_libraries`-Parameter in RDS für PostgreSQL Version 10 und höher angegeben. Mit dieser Bibliothek können Sie laufende Abfragen analysieren. Stellen Sie sicher, dass `pg_stat_statements` in Ihrer DB-Parametergruppe festgelegt ist. Weitere Informationen zur Überwachung Ihrer DB-Instance von RDS for PostgreSQL unter Verwendung der Informationen, die diese Bibliothek bereitstellt, finden Sie unter [SQL-Statistiken für RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Der `log_hostname`-Parameter erfasst den Hostnamen jeder Client-Verbindung im Protokoll. Für RDS für PostgreSQL Version 12 und höhere Versionen ist dieser Parameter standardmäßig auf `off` festgelegt. Wenn Sie ihn aktivieren, achten Sie darauf, die Verbindungszeiten der Sitzung zu überwachen. Wenn diese Option aktiviert ist, verwendet der Dienst die Reverse-Lookup-Anfrage des Domain Name Systems (DNS), um den Hostnamen des Clients, der die Verbindung herstellt, abzurufen und dem PostgreSQL-Protokoll hinzuzufügen. Dies hat spürbare Auswirkungen während der Sitzungsverbindung. Wir empfehlen, diesen Parameter nur für Fehlerbehebungszwecke zu aktivieren.
Im Allgemeinen ist der Zweck der Protokollierung, dass der DBA die Leistung überwachen, optimieren und Fehler beheben kann. Viele der Protokolle werden automatisch auf Amazon CloudWatch oder Performance Insights hochgeladen. Hier werden sie sortiert und gruppiert, um vollständige Metriken für die DB-Instance bereitzustellen. Weitere Informationen zur Amazon-RDS-Überwachung und -Metriken finden Sie unter [Überwachen von Metriken in einer Amazon-RDS-Instance](CHAP_Monitoring.md).
# Verwalten temporärer Dateien mit PostgreSQL
In PostgreSQL kann eine komplexe Abfrage möglicherweise mehrere Sortier- und Hash-Vorgänge gleichzeitig durchführen, wobei jeder Vorgang Instance-Speicher verwendet, um Ergebnisse bis zu dem im [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Diese werden auf die Festplatte geschrieben, um die Abfrageausführung abzuschließen. Später werden diese Dateien automatisch entfernt, nachdem die Abfrage abgeschlossen ist. In RDS für PostgreSQL werden diese Dateien in Amazon EBS auf dem Datenvolume gespeichert. Weitere Informationen finden Sie unter [Amazon-RDS-DB-Instance Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Sie können die in veröffentlichte `FreeStorageSpace` Metrik überwachen CloudWatch , um sicherzustellen, dass Ihre DB-Instance über ausreichend freien Speicherplatz verfügt. Weitere Informationen finden Sie unter [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Wir empfehlen die Verwendung von Instances für Amazon-RDS-optimierte Lesevorgänge für Workloads mit mehreren gleichzeitigen Abfragen, die mehr temporäre Dateien nutzen. Diese verwenden lokalen, auf Non-Volatile Memory Express (NVMe) basierenden Solid-State-Drive-Speicher (SSD) auf Blockebene, um die temporären Dateien zu platzieren. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für RDS für PostgreSQL mit Amazon-RDS-optimierten Lesevorgängen](USER_PostgreSQL.optimizedreads.md).
Sie können die folgenden Parameter und Funktionen verwenden, um die temporären Dateien in Ihrer Instance zu verwalten.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Dieser Parameter bricht jede Abfrage ab, die die Größe von temp\$1files in KB überschreitet. Dieses Limit verhindert, dass Abfragen endlos ausgeführt werden und Speicherplatz mit temporären Dateien belegen. Sie können den Wert anhand der Ergebnisse des Parameters `log_temp_files` schätzen. Es hat sich bewährt, das Workload-Verhalten zu untersuchen und das Limit der Schätzung entsprechend festzulegen. Das folgende Beispiel zeigt, wie eine Abfrage abgebrochen wird, wenn sie das Limit überschreitet.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Dieser Parameter sendet Nachrichten an die Datei postgresql.log, wenn die temporären Dateien einer Sitzung entfernt werden. Dieser Parameter erstellt Protokolle, nachdem eine Abfrage erfolgreich abgeschlossen wurde. Daher ist er bei der Fehlerbehebung aktiver, lang andauernder Abfragen möglicherweise nicht hilfreich.
Das folgende Beispiel zeigt, dass nach erfolgreichem Abschluss der Abfrage die Einträge in der Datei postgresql.log protokolliert werden, während die temporären Dateien bereinigt werden.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Diese Funktion, die von RDS für PostgreSQL 13 und höher verfügbar ist, bietet Einblick in die aktuelle Nutzung temporärer Dateien. Die abgeschlossene Abfrage erscheint nicht in den Ergebnissen der Funktion. Im folgenden Beispiel können Sie sich die Ergebnisse dieser Funktion ansehen.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Der Dateiname enthält die Verarbeitungs-ID (PID) der Sitzung, die die temporäre Datei generiert hat. Eine komplexere Abfrage, wie im folgenden Beispiel, führt eine Summenberechnung der temporären Dateien für jede PID durch.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Wenn Sie den Parameter pg\$1stat\$1statements aktivieren, können Sie die durchschnittliche Nutzung temporärer Dateien pro Aufruf einsehen. Sie können die query\$1id der Abfrage identifizieren und verwenden, um die Nutzung temporärer Dateien zu untersuchen, wie im folgenden Beispiel gezeigt.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Im Performance-Insights-Dashboard können Sie die Nutzung temporärer Dateien einsehen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Anschließend können Sie den Durchschnitt dieser beiden Metriken sehen und feststellen, wie sie dem Abfrage-Workload entsprechen. In der Ansicht in Performance Insights werden nicht speziell die Abfragen angezeigt, die die temporären Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler in Ihrem Abfrage-Workload beheben, analysieren und die Änderungen ermitteln.
Weitere Informationen zur Analyse von Metriken und Abfragen mit Performance Insights finden Sie unter [Analyse der Metriken mit dem Performance-Insights-Dashboard](USER_PerfInsights.UsingDashboard.md).
Ein Beispiel für die Anzeige der Nutzung temporärer Dateien mit Performance Insights finden Sie unter [Anzeigen der Nutzung temporärer Dateien mit Performance Insights](PostgreSQL.ManagingTempFiles.Example.md).
# Anzeigen der Nutzung temporärer Dateien mit Performance Insights
Sie können Performance Insights verwenden, um die Nutzung temporärer Dateien anzuzeigen, indem Sie die Metriken **temp\$1bytes** und **temp\$1files** aktivieren. Die Ansicht in Performance Insights zeigt nicht die spezifischen Abfragen an, die temporäre Dateien generieren. Wenn Sie jedoch Performance Insights mit der für `pg_ls_tmpdir` angezeigten Abfrage kombinieren, können Sie Fehler beheben, analysieren und die Änderungen in Ihrem Abfrage-Workload ermitteln.
1. Wählen Sie im Performance-Insights-Dashboard **Metriken verwalten** aus.
1. Wählen Sie **Datenbankmetriken** und die Metriken **temp\$1bytes** und **temp\$1files** aus, wie im folgenden Screenshot gezeigt.
![\[Im Diagramm dargestellte Metriken.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Wählen Sie auf der Registerkarte **Top SQL** das Symbol **Einstellungen** aus.
1. Schalten Sie im Fenster **Einstellungen** die folgenden Statistiken ein, damit sie auf der Registerkarte **Top SQL** angezeigt werden, und wählen Sie **Weiter** aus.
+ Temporäre Schreibvorgänge pro Sekunde
+ Temporäre Lesevorgänge pro Sekunde
+ Temporäre Massenschreibvorgänge/Aufruf
+ Temporäre Massenlesevorgänge/Aufruf
1. Die temporäre Datei wird aufgegliedert, wenn sie mit der für `pg_ls_tmpdir` gezeigten Abfrage kombiniert wird, wie im folgenden Beispiel gezeigt.
![\[Abfrage, die die Nutzung temporärer Dateien anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Die `IO:BufFileRead`- und `IO:BufFileWrite`-Ereignisse treten auf, wenn die häufigsten Abfragen in Ihrem Workload häufig temporäre Dateien erstellen. Mit Performance Insights können Sie die häufigsten Abfragen identifizieren, die auf `IO:BufFileRead` und `IO:BufFileWrite` warten, indem Sie die Abschnitte Durchschnittliche aktive Vorträge (AAS) in Datenbanklast und Top SQL überprüfen.
![\[IO: BufFileRead und IO: BufFileWrite in der Grafik.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Weitere Informationen zur Analyse von Top-Abfragen und Last nach Warteereignis mit Performance Insights finden Sie unter [Überblick über die Registerkarte „Top SQL“](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Sie sollten die Abfragen identifizieren und optimieren, die zu einer erhöhten Nutzung temporärer Dateien und damit verbundenen Warteereignissen führen. Weitere Informationen zu diesen Warteereignissen und deren Behebung finden Sie unter [IO: BufFileRead und IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .
**Anmerkung**
Der Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) steuert, wann der Sortiervorgang nicht mehr genügend Speicherplatz hat und die Ergebnisse in temporäre Dateien geschrieben werden. Wir empfehlen, die Einstellung dieses Parameters nicht höher als auf den Standardwert festzulegen, da dadurch jede Datenbanksitzung mehr Speicher belegen würde. Außerdem kann eine einzelne Sitzung, die komplexe Verknüpfungen und Sortierungen durchführt, parallele Operationen ausführen, bei denen jeder Vorgang Speicherplatz belegt.
Wenn Sie einen umfangreichen Bericht mit mehreren Verknüpfungen und Sortierungen haben, empfiehlt es sich, diesen Parameter mit dem Befehl `SET work_mem` auf Sitzungsebene festzulegen. Dann wird die Änderung nur auf die aktuelle Sitzung angewendet und der Wert nicht global geändert.
## Verwenden von pgBadger für die Protokollanalyse mit PostgreSQL
Sie können einen Protokollanalysierer wie [pgBadger](http://dalibo.github.io/pgbadger/) verwenden, um PostgreSQL-Protokolle zu analysieren. Die pgBadger-Dokumentation besagt, dass das Muster %l (Die Protokollzeile für die Sitzung oder den Prozess) ein Teil des Präfixes sein muss. Wenn Sie jedoch das aktuelle RDS `log_line_prefix` als Parameter für pgBadger angeben, wird dennoch ein Bericht erstellt.
Beispielsweise formatiert der folgende Befehl eine Amazon-RDS-for-PostgreSQL-Protokolldatei mit dem Datum 2014-02-04 korrekt unter Verwendung von pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## PGSnapper Für die Überwachung von PostgreSQL verwenden
Sie können PGSnapper es als Unterstützung bei der regelmäßigen Erfassung leistungsbezogener Statistiken und Metriken von Amazon RDS for PostgreSQL verwenden. Weitere Informationen finden Sie unter [Überwachen der Leistung von Amazon RDS for PostgreSQL mithilfe](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/) von. PGSnapper
#
**Typumwandlung** in PostgreSQL ist der Prozess der Konvertierung eines Werts von einem Datentyp in einen anderen. PostgreSQL bietet integrierte Umwandlungen für viele gängige Konvertierungen, aber Sie können auch benutzerdefinierte Umwandlungen erstellen, um zu definieren, wie sich bestimmte Typkonvertierungen verhalten sollen.
Eine Umwandlung gibt an, wie eine Konvertierung von einem Datentyp in einen anderen durchgeführt wird. Zum Beispiel die Konvertierung von Text in `'123'` eine Ganzzahl `123` oder einer Zahl `45.67` in Text`'45.67'`.
Umfassende Informationen zu PostgreSQL-Casting-Konzepten und -Syntax finden Sie in der [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html) CREATE CAST-Dokumentation.
Ab den Versionen 13.23, 14.20, 15.15, 16.11, 17.7 und 18.1, können Sie die Erweiterung rds\$1casts verwenden, um zusätzliche Umwandlungen für integrierte Typen zu installieren und gleichzeitig Ihre eigenen Umwandlungen für benutzerdefinierte Typen zu erstellen.
**Topics**
+ [Installation und Verwendung der Erweiterung rds\$1casts](#PostgreSQL.CustomCasts.Installing)
+ [Unterstützte Casts](#PostgreSQL.CustomCasts.Supported)
+ [Umwandlungen erstellen oder löschen](#PostgreSQL.CustomCasts.Creating)
+ [Erstellen von benutzerdefinierten Besetzungen mit der richtigen Kontextstrategie](#PostgreSQL.CustomCasts.BestPractices)
## Installation und Verwendung der Erweiterung rds\$1casts
Um die `rds_casts` Erweiterung zu erstellen, stellen Sie eine Verbindung zur (Ihre RDS for PostgreSQL-DB-Instance) her `rds_superuser` und führen Sie den folgenden Befehl aus:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Unterstützte Casts
Erstellen Sie die Erweiterung in jeder Datenbank, in der Sie benutzerdefinierte Casts verwenden möchten. Verwenden Sie nach dem Erstellen der Erweiterung den folgenden Befehl, um alle verfügbaren Casts anzuzeigen:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Diese Funktion listet die verfügbaren Cast-Kombinationen auf (Quelltyp, Zieltyp, Zwangskontext und Cast-Funktion). Zum Beispiel, wenn Sie to `numeric` als Besetzung erstellen `text` möchten. `implicit` Sie können die folgende Abfrage verwenden, um herauszufinden, ob die Besetzung zum Erstellen verfügbar ist:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
Die Erweiterung rds\$1casts bietet zwei Arten von Konvertierungsfunktionen für jede Besetzung:
+ *\$1inout-Funktionen* — Verwenden Sie den I/O Standard-Konvertierungsmechanismus von PostgreSQL, der sich genauso verhält wie Casts, die mit der INOUT-Methode erstellt wurden
+ *\$1benutzerdefinierte Funktionen* — Stellen eine erweiterte Konvertierungslogik bereit, die Sonderfälle behandelt, z. B. die Konvertierung leerer Zeichenketten in NULL-Werte, um Konvertierungsfehler zu vermeiden
Die `inout` Funktionen replizieren das native Casting-Verhalten von PostgreSQL, während `custom` Funktionen diese Funktionalität erweitern, indem sie Szenarien behandeln, die mit Standard-INOUT-Umwandlungen nicht berücksichtigt werden können, wie z. B. die Konvertierung leerer Zeichenketten in ganze Zahlen.
## Umwandlungen erstellen oder löschen
Sie können unterstützte Besetzungen mit zwei Methoden erstellen und löschen:
### Erstellung von Darstellern
**Methode 1: Verwenden des nativen CREATE CAST-Befehls**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Methode 2: Verwendung der Funktion rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
Die `create_cast` Funktion verwendet die ID aus der Ausgabe. `list_supported_casts()` Diese Methode ist einfacher und stellt sicher, dass Sie die richtige Kombination aus Funktion und Kontext verwenden. Es ist garantiert, dass diese ID in verschiedenen Postgres-Versionen gleich bleibt.
Um zu überprüfen, ob der Cast erfolgreich erstellt wurde, fragen Sie den pg\$1cast-Systemkatalog ab:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
Die `castcontext` Spalte zeigt: `e` für EXPLICIT, für ASSIGNMENT oder `a` `i` für IMPLICIT.
### Besetzungen löschen
**Methode 1: Verwenden des Befehls DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Methode 2: Verwendung der Funktion rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
Die `drop_cast` Funktion verwendet dieselbe ID, die bei der Erstellung der Besetzung verwendet wurde. Diese Methode stellt sicher, dass Sie genau die Besetzung löschen, die mit der entsprechenden ID erstellt wurde.
## Erstellen von benutzerdefinierten Besetzungen mit der richtigen Kontextstrategie
Beim Erstellen mehrerer Umwandlungen für Integer-Typen können Operator-Mehrdeutigkeitsfehler auftreten, wenn alle Umwandlungen als IMPLIZIT erstellt werden. Das folgende Beispiel veranschaulicht dieses Problem, indem zwei implizite Umwandlungen von Text in unterschiedliche Ganzzahlbreiten erstellt werden:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
Der Fehler tritt auf, weil PostgreSQL nicht bestimmen kann, welche implizite Umwandlung beim Vergleich einer Integer-Spalte mit einem Textwert verwendet werden soll. Sowohl die implizite Umwandlung von int4 als auch die implizite Umwandlung von int8 sind gültige Kandidaten, was zu Mehrdeutigkeiten führt.
Um diese Mehrdeutigkeit der Operatoren zu vermeiden, verwenden Sie den ASSIGNMENT-Kontext für kleinere Ganzzahlbreiten und den IMPLIZITEN Kontext für größere Ganzzahlbreiten:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Bei dieser Strategie ist nur die int8-Umwandlung implizit, sodass PostgreSQL eindeutig bestimmen kann, welche Umwandlung verwendet werden soll.
# Bewährte Methoden für parallele Abfragen in
Die parallele Abfrageausführung ist eine Funktion in PostgreSQL, mit der eine einzelne SQL-Abfrage in kleinere Aufgaben aufgeteilt werden kann, die gleichzeitig von mehreren Hintergrund-Worker-Prozessen verarbeitet werden. Anstatt eine Abfrage vollständig in einem einzigen Backend-Prozess auszuführen, kann PostgreSQL Teile der Abfrage, wie Scans, Joins, Aggregationen oder Sortierungen, auf mehrere CPU-Kerne verteilen. Der *Leader-Prozess* koordiniert diese Ausführung und sammelt die Ergebnisse der *parallel Mitarbeiter*.
Für die meisten Produktionsworkloads, insbesondere OLTP-Systeme mit hoher Parallelität, empfehlen wir jedoch, die automatische parallel Abfrageausführung zu deaktivieren. Parallelität kann zwar Abfragen großer Datenmengen bei Analyse- oder Berichtsworkloads beschleunigen, birgt jedoch erhebliche Risiken, die in geschäftigen Produktionsumgebungen häufig die Vorteile überwiegen.
Die parallele Ausführung bringt auch einen erheblichen Mehraufwand mit sich. Jeder parallel Worker ist ein vollständiger PostgreSQL-Backend-Prozess, der Prozessforking (Kopieren von Speicherstrukturen und Initialisieren des Prozessstatus) und Authentifizierung (Nutzung von Verbindungssteckplätzen von Ihrem Limit) erfordert. `max_connections` Jeder Worker verbraucht außerdem seinen eigenen Speicher, auch `work_mem` für Sortier- und Hashing-Operationen. Bei mehreren Workern pro Abfrage vervielfacht sich die Speicherbelegung schnell (z. B. 4 Worker × 64 MB = 256 MB pro Abfrage). `work_mem` Aus diesem Grund können parallel Abfragen erheblich mehr Systemressourcen verbrauchen als Abfragen mit einem einzigen Prozess. Wenn sie nicht richtig eingestellt sind, können sie zu CPU-Sättigung (mehrere Worker überfordern die verfügbare Verarbeitungskapazität), verstärktem Kontextwechsel (das Betriebssystem wechselt häufig zwischen zahlreichen Worker-Prozessen, was den Overhead erhöht und den Durchsatz reduziert) oder zu Verbindungsausfällen führen (da jeder parallel Worker einen Verbindungssteckplatz beansprucht, verwendet eine einzelne Abfrage mit 4 Workern insgesamt 5 Verbindungen, 1 Leader und 4 Worker, was Ihren Verbindungspool bei hoher Parallelität schnell erschöpfen kann, wodurch neue Clientverbindungen verhindert und Anwendungsausfälle verursacht werden). Diese Probleme sind besonders schwerwiegend bei Workloads mit hoher Parallelität, bei denen mehrere Abfragen versuchen können, gleichzeitig ausgeführt zu werden.
PostgreSQL entscheidet auf der Grundlage von Kostenschätzungen, ob Parallelität verwendet werden soll. In einigen Fällen kann der Planer automatisch zu einem Parallelplan wechseln, wenn dieser günstiger erscheint, auch wenn er in der Praxis nicht ideal ist. Dies kann der Fall sein, wenn Indexstatistiken veraltet sind oder wenn durch Aufblähung sequentielle Scans attraktiver erscheinen als Indexsuchen. Aufgrund dieses Verhaltens können automatische parallel Pläne manchmal zu Regressionen bei der Abfrageleistung oder Systemstabilität führen.
Um den größtmöglichen Nutzen aus parallel Abfragen in zu ziehen, ist es wichtig, sie auf der Grundlage Ihrer Arbeitslast zu testen und zu optimieren, die Auswirkungen auf das System zu überwachen und die automatische parallel Planauswahl zugunsten der Steuerung auf Abfrageebene zu deaktivieren.
## Konfigurationsparameter
PostgreSQL verwendet mehrere Parameter, um das Verhalten und die Verfügbarkeit parallel Abfragen zu steuern. Diese zu verstehen und zu optimieren, ist entscheidend, um eine vorhersehbare Leistung zu erzielen:
| Parameter | Description | Standard |
| --- | --- | --- |
| max\$1parallel\$1workers | Maximale Anzahl von Hintergrund-Worker-Prozessen, die insgesamt ausgeführt werden können | AM GRÖSSTEN (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Maximale Anzahl von Workern pro Abfrageplanknoten (z. B. pro) Gather | 2 |
| parallel\$1setup\$1cost | Zusätzliche Planerkosten für die Initiierung einer parallel Abfrageinfrastruktur | 1000 |
| parallel\$1tuple\$1cost | Kosten pro im Parallelmodus verarbeitetem Tupel (wirkt sich auf die Entscheidung des Planers aus) | 0.1 |
| force\$1parallel\$1mode | Zwingt den Planer, parallel Pläne zu testen (off,on,regress) | off |
### Wichtige Überlegungen
+ `max_parallel_workers`kontrolliert den gesamten Pool parallel Mitarbeiter. Wenn der Wert zu niedrig ist, können einige Abfragen auf die serielle Ausführung zurückgreifen.
+ `max_parallel_workers_per_gather`wirkt sich darauf aus, wie viele Worker eine einzelne Abfrage verwenden kann. Ein höherer Wert erhöht die Parallelität, erhöht aber auch die Ressourcennutzung.
+ `parallel_setup_cost`und `parallel_tuple_cost` wirken sich auf das Kostenmodell des Planers aus. Eine Senkung dieser Werte kann die Wahrscheinlichkeit erhöhen, dass parallel Pläne gewählt werden.
+ `force_parallel_mode`ist für Tests nützlich, sollte aber nicht in der Produktion verwendet werden, sofern dies nicht erforderlich ist.
**Anmerkung**
Der Standardwert des `max_parallel_workers` Parameters wird anhand der Instanzgröße anhand der Formel dynamisch berechnet`GREATEST($DBInstanceVCPU/2, 8)`. Das heißt, wenn Sie Ihre auf eine größere Rechengröße mit mehr v skalierenCPUs, wird die maximale Anzahl verfügbarer parallel Worker automatisch erhöht. Infolgedessen können Abfragen, die zuvor seriell oder mit eingeschränkter Parallelität ausgeführt wurden, nach einem Scale-up-Vorgang plötzlich mehr parallel Worker verwenden, was möglicherweise zu einem unerwarteten Anstieg der Verbindungs-, CPU- und Speicherauslastung führen kann. Es ist wichtig, das Verhalten parallel Abfragen nach jedem Rechenskalierungsereignis zu überwachen und `max_parallel_workers_per_gather` gegebenenfalls anzupassen, um eine vorhersehbare Ressourcennutzung aufrechtzuerhalten.
## Identifizieren Sie die Nutzung paralleler Abfragen
Abfragen können zu parallel Plänen wechseln, die auf Datenverteilung oder Statistiken basieren. Beispiel:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Diese Abfrage verwendet möglicherweise einen Index für aktuelle Daten, wechselt jedoch zu einem parallel sequentiellen Scan für historische Daten.
Sie können Ausführungspläne für Abfragen protokollieren, indem Sie das `auto_explain` Modul laden. Weitere Informationen finden Sie im AWS Knowledge Center unter [Ausführungspläne von Abfragen protokollieren](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#).
Sie können [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) auf Warteereignisse im Zusammenhang mit parallelen Abfragen überwachen. Weitere Informationen zu Warteereignissen im Zusammenhang mit Parallel Query finden Sie unter [IPC:Parallele](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html) Warteereignisse
Ab PostgreSQL Version 18 können Sie parallel Worker-Aktivitäten mithilfe neuer Spalten in [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)und überwachen: [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html)
+ `parallel_workers_to_launch`: Anzahl der parallel arbeitenden Mitarbeiter, deren Einführung geplant ist
+ `parallel_workers_launched`: Anzahl der tatsächlich eingeführten Parallelarbeiter
Diese Kennzahlen helfen dabei, Diskrepanzen zwischen der geplanten und der tatsächlichen Parallelität zu erkennen, die auf Ressourcenbeschränkungen oder Konfigurationsprobleme hinweisen können. Verwenden Sie die folgenden Abfragen, um die parallel Ausführung zu überwachen:
Für Parallel-Worker-Metriken auf Datenbankebene:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Für Parallel-Worker-Metriken auf Abfrageebene
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Wie kontrolliert man Parallelität
Es gibt mehrere Möglichkeiten, die Abfrageparallelität zu kontrollieren, die jeweils für unterschiedliche Szenarien und Anforderungen konzipiert sind.
Um die automatische Parallelität global zu deaktivieren, und legen [Sie Folgendes fest](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html):
```
max_parallel_workers_per_gather = 0;
```
Für persistente, benutzerspezifische Einstellungen bietet der Befehl ALTER ROLE eine Möglichkeit, Parameter festzulegen, die für alle future Sitzungen eines bestimmten Benutzers gelten.
Beispiel:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`stellt sicher, dass jedes Mal, wenn dieser Benutzer eine Verbindung zur Datenbank herstellt, seine Sitzungen bei Bedarf diese Parallel-Worker-Einstellung verwenden.
Die Steuerung auf Sitzungsebene kann mit dem Befehl SET erreicht werden, der die Parameter für die Dauer der aktuellen Datenbanksitzung ändert. Dies ist besonders nützlich, wenn Sie Einstellungen vorübergehend anpassen müssen, ohne dass dies Auswirkungen auf andere Benutzer oder future Sitzungen hat. Einmal festgelegt, bleiben diese Parameter gültig, bis sie explizit zurückgesetzt werden oder bis die Sitzung beendet wird. Die Befehle sind einfach:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Für eine noch detailliertere Steuerung können Sie mit SET LOCAL die Parameter für eine einzelne Transaktion ändern. Dies ist ideal, wenn Sie die Einstellungen für einen bestimmten Satz von Abfragen innerhalb einer Transaktion anpassen müssen. Danach werden die Einstellungen automatisch auf ihre vorherigen Werte zurückgesetzt. Dieser Ansatz trägt dazu bei, unbeabsichtigte Auswirkungen auf andere Vorgänge innerhalb derselben Sitzung zu verhindern.
## Diagnostizieren des Verhaltens paralleler Abfragen
Wird verwendet`EXPLAIN (ANALYZE, VERBOSE)`, um zu überprüfen, ob eine Abfrage parallel ausgeführt wurde:
+ Suchen Sie nach Knoten wie `Gather``Gather Merge`, oder`Parallel Seq Scan`.
+ Vergleichen Sie Pläne mit und ohne Parallelität.
So deaktivieren Sie die Parallelität vorübergehend zum Vergleich:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL
In einigen Fällen können Sie eine DB-Instance für RDS for PostgreSQL erstellen, ohne eine benutzerdefinierte Parametergruppe anzugeben. In diesem Fall wird Ihre DB-Instance mit der Standardparametergruppe für die von Ihnen gewählte Version von PostgreSQL erstellt. Angenommen, Sie erstellen eine DB-Instance für RDS for PostgreSQL mit PostgreSQL 13.3. In diesem Fall wird die DB-Instance unter Verwendung der Werte in der Parametergruppe für PostgreSQL-13-Versionen, `default.postgres13`, erstellt.
Sie können auch eine eigene benutzerdefinierte DB-Parametergruppe erstellen. Sie müssen dies tun, wenn Sie die Einstellungen der Standardwerte für die DB-Instance von RDS for PostgreSQL ändern möchten. Um zu erfahren wie dies geht, vgl. [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können die Einstellungen auf der DB-Instance von RDS for PostgreSQL auf verschiedene Arten verfolgen. Sie können die AWS-Managementkonsole AWS CLI, oder die Amazon RDS-API verwenden. Sie können die Werte auch aus der PostgreSQL `pg_settings`-Tabelle Ihrer Instance abfragen, wie im Folgenden dargestellt.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Weitere Informationen zu von dieser Abfrage zurückgegebenen Werten finden Sie unter [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) in der PostgreSQL-Dokumentation.
Seien Sie besonders vorsichtig, wenn Sie die Einstellungen für `max_connections` und `shared_buffers` auf Ihrer DB-Instance von RDS für PostgreSQL ändern. Nehmen Sie zum Beispiel an, dass Sie die Einstellungen für `max_connections` oder `shared_buffers` ändern und Werte verwenden, die für den tatsächlichen Workload zu hoch sind. In diesem Fall wird die DB-Instance von RDS for PostgreSQL nicht gestartet. In diesem Fall wird Ihnen in `postgres.log` ein Fehler ähnlich dem folgenden angezeigt:
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Sie können jedoch keine Werte der Einstellungen ändern, die in Standard-RDS-for-PostgreSQL-DB-Parametergruppen enthalten sind. Um die Einstellungen für Parameter zu ändern, erstellen Sie zuerst eine benutzerdefinierte DB-Parametergruppe. Ändern Sie dann die Einstellungen in dieser benutzerdefinierten Gruppe und wenden Sie dann die benutzerdefinierte Parametergruppe auf die DB-Instance von RDS for PostgreSQL an. Weitere Informationen hierzu finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Für PostgreSQL-DB-Parameter gibt es zwei Arten von Parametern.
+ **Statische Parameter** – Statische Parameter erfordern den Neustart der DB-Instance von RDS für PostgreSQL nach einer Änderung, damit der neue Wert angewendet wird.
+ **Dynamische Parameter** – Dynamische Parameter erfordern keinen Neustart, nachdem ihre Einstellungen geändert wurden.
**Anmerkung**
Wenn Ihre DB-Instance von RDS für PostgreSQL Ihre eigene benutzerdefinierte DB-Parametergruppe verwendet, können Sie die Werte dynamischer Parameter auf der laufenden DB-Instance ändern. Sie können dies tun, indem Sie die AWS-Managementkonsole AWS CLI, oder die Amazon RDS-API verwenden.
Wenn Sie die nötigen Berechtigungen dafür besitzen, können Sie Parameterwerte auch ändern, indem Sie die Befehle `ALTER DATABASE`, `ALTER ROLE` und `SET` verwenden.
## DB-Instance-Parameterliste von RDS für PostgreSQL
In der folgenden Tabelle sind einige (nicht alle) Parameter aufgeführt, die in einer DB-Instance von RDS für PostgreSQL verfügbar sind. Um alle verfügbaren Parameter anzuzeigen, verwenden Sie den [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI Befehl. Wenn Sie beispielsweise die Liste aller Parameter abrufen möchten, die in der Standardparametergruppe für Version 13 von RDS für PostgreSQL verfügbar sind, führen Sie den folgenden Befehl aus.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Sie können auch die Konsole verwenden. Wählen Sie **Parameter groups** (Parametergruppen) aus dem Amazon-RDS-Menü und dann die Parametergruppe aus den in Ihrer AWS-Region verfügbaren Gruppen aus.
| Parametername | Apply\$1Type | Beschreibung |
| --- | --- | --- |
| `application_name` | Dynamisch | Legt den Namen der Anwendung fest, der in Statistiken und Protokollen verwendet werden soll. |
| `archive_command` | Dynamisch | Legt den Shell-Befehl fest, der zum Archivieren einer WAL-Datei aufgerufen wird. |
| `array_nulls` | Dynamisch | Ermöglicht die Eingabe von NULL-Elementen in Arrays. |
| `authentication_timeout` | Dynamisch | Legt die Zeit fest, die maximal zulässig ist, um die Client-Authentifizierung durchzuführen. |
| `autovacuum` | Dynamisch | Startet den Untervorgang der Selbstbereinigung. |
| `autovacuum_analyze_scale_factor` | Dynamisch | Anzahl von Tupel-Einfügungen, -Aktualisierungen oder -Löschungen vor der Analyse als Bruchteil von Reltupeln. |
| `autovacuum_analyze_threshold` | Dynamisch | Mindestanzahl von Tupel-Einfügungen, -Aktualisierungen oder -Löschungen vor der Analyse. |
| `autovacuum_freeze_max_age` | Statisch | Alter, bei dem eine Selbstbereinigung für eine Tabelle ausgeführt werden soll, um einen Transaktions-ID-Wraparound zu verhindern. |
| `autovacuum_naptime` | Dynamisch | Inaktivitätszeit zwischen Selbstbereinigungen. |
| `autovacuum_max_workers` | Statisch | Legt die maximale Anzahl gleichzeitig ausgeführter Worker-Vorgänge für die Selbstbereinigung fest. |
| `autovacuum_vacuum_cost_delay` | Dynamisch | Bereinigungskostenverzögerung (in Millisekunden) für die Selbstbereinigung. |
| `autovacuum_vacuum_cost_limit` | Dynamisch | Bereinigungskostenbetrag für die Selbstbereinigung, der vor der Inaktivität verfügbar ist. |
| `autovacuum_vacuum_scale_factor` | Dynamisch | Anzahl von Tupel-Aktualisierungen oder -Löschungen vor der Bereinigung als Bruchteil von Reltupeln. |
| `autovacuum_vacuum_threshold` | Dynamisch | Mindestanzahl von Tupel-Aktualisierungen oder -Löschungen vor der Bereinigung. |
| `backslash_quote` | Dynamisch | Legt fest, ob in Zeichenfolgeliteralen ein Backslash (\$1) zulässig ist. |
| `bgwriter_delay` | Dynamisch | Inaktivitätszeit des Hintergrundschreibers zwischen Runden. |
| `bgwriter_lru_maxpages` | Dynamisch | Maximale Anzahl von LRU-Seiten eines Hintergrundschreibers, für die pro Runde ein Flush ausgeführt werden kann. |
| `bgwriter_lru_multiplier` | Dynamisch | Mehrfaches der durchschnittlichen Puffernutzung, die pro Runde freigegeben werden soll. |
| `bytea_output` | Dynamisch | Legt das Ausgabeformat für Bytes fest. |
| `check_function_bodies` | Dynamisch | Überprüft die Funktionstexte während CREATE FUNCTION. |
| `checkpoint_completion_target` | Dynamisch | Zeit für den Flush ungültiger Puffer während des Prüfpunkts als Bruchteil des Prüfpunktintervalls. |
| `checkpoint_segments` | Dynamisch | Legt die maximale Entfernung in Protokollsegmenten zwischen automatischen Write-Ahead Log (WAL)-Prüfpunkten fest. |
| `checkpoint_timeout` | Dynamisch | Legt die maximale Zeit zwischen automatischen WAL-Prüfpunkten fest. |
| `checkpoint_warning` | Dynamisch | Ermöglicht Warnungen, wenn Prüfpunktsegmente häufiger als hierdurch angegeben gefüllt werden. |
| `client_connection_check_interval` | Dynamisch | Legt das Zeitintervall zwischen Prüfungen auf Verbindungsabbrüche während der Ausführung von Abfragen fest. |
| `client_encoding` | Dynamisch | Legt die Zeichensatzkodierung des Client fest. |
| `client_min_messages` | Dynamisch | Legt die Nachrichtenebenen fest, die an den Client gesendet werden. |
| `commit_delay` | Dynamisch | Legt die Verzögerung (in Mikrosekunden) zwischen dem Transaktions-Commit und dem Flush von WAL zum Datenträger fest. |
| `commit_siblings` | Dynamisch | Legt die Mindestzahl gleichzeitiger offener Transaktionen fest, bevor eine Commit-Verzögerung ausgeführt wird. |
| `constraint_exclusion` | Dynamisch | Ermöglicht dem Planer die Verwendung von Einschränkungen, um Abfragen zu optimieren. |
| `cpu_index_tuple_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Indexeinträge während einer Indexprüfung fest. |
| `cpu_operator_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Operator- oder Funktionsaufrufe fest. |
| `cpu_tuple_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten der Verarbeitung der einzelnen Tupeln (Zeilen) fest. |
| `cursor_tuple_fraction` | Dynamisch | Legt die Schätzung des Planers für den Bruchteil der Zeilen eines Cursors fest, die abgerufen werden. |
| `datestyle` | Dynamisch | Legt das Anzeigeformat für Datum- und Uhrzeitwerte fest. |
| `deadlock_timeout` | Dynamisch | Legt die Zeit fest, die während einer Sperre gewartet wird, bevor auf einen Deadlock geprüft wird. |
| `debug_pretty_print` | Dynamisch | Erstellt Einschübe für Analyse- und Planstrukturanzeigen. |
| `debug_print_parse` | Dynamisch | Protokolliert die Analysestruktur der einzelnen Abfragen. |
| `debug_print_plan` | Dynamisch | Protokolliert den Ausführungsplan der einzelnen Abfragen. |
| `debug_print_rewritten` | Dynamisch | Protokolliert die neu geschriebene Analysestruktur der einzelnen Abfragen. |
| `default_statistics_target` | Dynamisch | Legt das Standardstatistikziel fest. |
| `default_tablespace` | Dynamisch | Legt den Standardtabellenraum fest, in dem Tabellen und Indexe erstellt werden. |
| `default_transaction_deferrable` | Dynamisch | Legt den Standardaufschiebbarkeitsstatus neuer Transaktionen fest. |
| `default_transaction_isolation` | Dynamisch | Legt die Transaktionsisolierungsstufe jeder neuen Transaktion fest. |
| `default_transaction_read_only` | Dynamisch | Legt den Standardschreibschutzstatus neuer Transaktionen fest. |
| `default_with_oids` | Dynamisch | Erstellt standardmäßig neue Tabellen mit object IDs (OIDs). |
| `effective_cache_size` | Dynamisch | Legt die Annahme des Planers hinsichtlich der Größe des Datenträger-Caches fest. |
| `effective_io_concurrency` | Dynamisch | Die Anzahl der gleichzeitigen Anfragen, die durch das Datenträgersubsystem effizient bearbeitet werden können. |
| `enable_bitmapscan` | Dynamisch | Ermöglicht die Verwendung von Bitmap-Prüfungsplänen durch den Planer. |
| `enable_hashagg` | Dynamisch | Ermöglicht die Verwendung von Hash-Aggregationsplänen durch den Planer. |
| `enable_hashjoin` | Dynamisch | Ermöglicht die Verwendung von Hash-Join-Plänen durch den Planer. |
| `enable_indexscan` | Dynamisch | Ermöglicht die Verwendung von Indexprüfungsplänen durch den Planer. |
| `enable_material` | Dynamisch | Ermöglicht die Verwendung von Materialisierung durch den Planer. |
| `enable_mergejoin` | Dynamisch | Ermöglicht die Verwendung von Zusammenführungs-Join-Plänen durch den Planer. |
| `enable_nestloop` | Dynamisch | Ermöglicht die Verwendung von Join-Plänen mit verschachtelten Schleifen durch den Planer. |
| `enable_seqscan` | Dynamisch | Ermöglicht die Verwendung von sequenziellen Prüfungsplänen durch den Planer. |
| `enable_sort` | Dynamisch | Ermöglicht die Verwendung von expliziten Sortierschritten durch den Planer. |
| `enable_tidscan` | Dynamisch | Ermöglicht die Verwendung von TID-Prüfungsplänen durch den Planer. |
| `escape_string_warning` | Dynamisch | Gibt Warnungen zu Escape-Notierungen mit Backslash (\$1) in gewöhnlichen Zeichenfolgeliteralen aus. |
| `extra_float_digits` | Dynamisch | Legt die Anzahl der Stellen fest, die für Gleitkommawerte angezeigt werden. |
| `from_collapse_limit` | Dynamisch | Legt die Größe der FROM-Liste fest, jenseits der Unterabfragen nicht ausgeblendet werden. |
| `fsync` | Dynamisch | Erzwingt die Synchronisierung von Aktualisierungen zum Datenträger. |
| `full_page_writes` | Dynamisch | Schreibt bei der ersten Änderung nach einem Prüfpunkt vollständige Seiten zu WAL. |
| `geqo` | Dynamisch | Ermöglicht die genetische Abfrageoptimierung. |
| `geqo_effort` | Dynamisch | GEQO: Der Aufwand, der verwendet wird, um den Standard für andere GEQO-Parameter festzulegen. |
| `geqo_generations` | Dynamisch | GEQO: Die Zahl der Iterationen des Algorithmus. |
| `geqo_pool_size` | Dynamisch | GEQO: Die Anzahl der Personen in der Population. |
| `geqo_seed` | Dynamisch | GEQO: Der Seed für die zufällige Pfadauswahl. |
| `geqo_selection_bias` | Dynamisch | GEQO: Selektiver Druck innerhalb der Population. |
| `geqo_threshold` | Dynamisch | Legt den Schwellenwert für FROM-Elemente fest, jenseits derer GEQO verwendet wird. |
| `gin_fuzzy_search_limit` | Dynamisch | Legt das maximal zulässige Ergebnis für die exakte Suche durch GIN fest. |
| `hot_standby_feedback` | Dynamisch | Legt fest, ob ein Hot Standby Rückmeldungen an den primären oder Upstream Standby sendet. |
| `intervalstyle` | Dynamisch | Legt das Anzeigeformat für Intervallwerte fest. |
| `join_collapse_limit` | Dynamisch | Legt die Größe der FROM-Liste fest, jenseits der JOIN-Konstrukte nicht auf eine Ebene gebracht werden. |
| `lc_messages` | Dynamisch | Legt die Sprache fest, in der Nachrichten angezeigt werden. |
| `lc_monetary` | Dynamisch | Legt das Gebietsschema für die Formatierung von monetären Beträgen fest. |
| `lc_numeric` | Dynamisch | Legt das Gebietsschema für die Formatierung von Zahlen fest. |
| `lc_time` | Dynamisch | Legt das Gebietsschema für die Formatierung von Datum- und Uhrzeitwerten fest. |
| `log_autovacuum_min_duration` | Dynamisch | Legt die Mindestausführungszeit fest, ab der Aktionen für die Selbstbereinigung protokolliert werden. |
| `log_checkpoints` | Dynamisch | Protokolliert jeden Prüfpunkt. |
| `log_connections` | Dynamisch | Protokolliert jede erfolgreiche Verbindung. |
| `log_disconnections` | Dynamisch | Protokolliert das Ende einer Sitzung einschließlich der Dauer. |
| `log_duration` | Dynamisch | Protokolliert die Dauer jeder abgeschlossenen SQL-Anweisung. |
| `log_error_verbosity` | Dynamisch | Legt die Ausführlichkeit protokollierter Nachrichten fest. |
| `log_executor_stats` | Dynamisch | Schreibt die Leistungsstatistik des Executors in das Serverprotokoll. |
| `log_filename` | Dynamisch | Legt das Dateinamenmuster für Protokolldateien fest. |
| `log_file_mode` | Dynamisch | Legt Dateiberechtigungen für Protokolldateien fest. Der Standardwert ist 0644. |
| `log_hostname` | Dynamisch | Protokolliert den Hostnamen in den Verbindungsprotokollen. Ab PostgreSQL 12 und späteren Versionen ist dieser Parameter standardmäßig „off“. Wenn diese Option aktiviert ist, verwendet die Verbindung DNS-Reverse-Lookup, um den Hostnamen abzurufen, der in den Verbindungsprotokollen erfasst wird. Wenn Sie diesen Parameter aktivieren, sollten Sie überwachen, welche Auswirkungen er auf die Zeit hat, die für den Verbindungsaufbau benötigt wird. |
| `log_line_prefix ` | Dynamisch | Steuert Informationen, die jeder Protokollzeile vorangestellt sind. |
| `log_lock_waits` | Dynamisch | Protokolliert lange Sperrenwartezeiten. |
| `log_min_duration_statement` | Dynamisch | Legt die Mindestausführungszeit fest, ab der Anweisungen protokolliert werden. |
| `log_min_error_statement` | Dynamisch | Veranlasst, dass alle Anweisungen, die einen Fehler auf oder jenseits dieser Stufe generieren, protokolliert werden. |
| `log_min_messages` | Dynamisch | Legt die Nachrichtenebenen fest, die protokolliert werden. |
| `log_parser_stats` | Dynamisch | Schreibt die Leistungsstatistik des Parsers in das Serverprotokoll. |
| `log_planner_stats` | Dynamisch | Schreibt die Leistungsstatistik des Planers in das Serverprotokoll. |
| `log_rotation_age` | Dynamisch | Die automatische Protokolldateirotation wird nach N Minuten ausgeführt. |
| `log_rotation_size` | Dynamisch | Die automatische Protokolldateirotation wird nach N Kilobytes ausgeführt. |
| `log_statement` | Dynamisch | Legt den Typ der protokollierten Anweisungen fest. |
| `log_statement_stats` | Dynamisch | Schreibt kumulative Leistungsstatistiken in das Serverprotokoll. |
| `log_temp_files` | Dynamisch | Protokolliert die Verwendung temporärer Dateien, die größer als diese Zahl von Kilobytes sind. |
| `log_timezone` | Dynamisch | Legt die Zeitzone fest, die in Protokollmeldungen verwendet werden soll. |
| `log_truncate_on_rotation` | Dynamisch | Kürzt vorhandene Protokolldateien mit demselben Namen während der Protokollrotation. |
| `logging_collector` | Statisch | Startet einen Unterprozess, um die and/or CSVLogs der STDERR-Ausgabe in Protokolldateien zu erfassen. |
| `maintenance_work_mem` | Dynamisch | Legt den maximalen Arbeitsspeicher fest, der für Wartungsoperationen verwendet werden darf. |
| `max_connections` | Statisch | Legt die maximale Anzahl gleichzeitiger Verbindungen fest. |
| `max_files_per_process` | Statisch | Legt die maximale Anzahl gleichzeitig geöffneter Dateien für die einzelnen Serverprozesse fest. |
| `max_locks_per_transaction` | Statisch | Legt die maximale Anzahl von Sperren pro Transaktion fest. |
| `max_pred_locks_per_transaction` | Statisch | Legt die maximale Anzahl von Prädikatssperren pro Transaktion fest. |
| `max_prepared_transactions` | Statisch | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. |
| `max_stack_depth` | Dynamisch | Legt die maximale Stack-Tiefe in Kilobytes fest. |
| `max_standby_archive_delay` | Dynamisch | Legt die maximale Verzögerung fest, bevor Abfragen storniert werden, wenn ein Hot-Standby-Server archivierte WAL-Daten verarbeitet. |
| `max_standby_streaming_delay` | Dynamisch | Legt die maximale Verzögerung fest, bevor Abfragen storniert werden, wenn ein Hot-Standby-Server gestreamte WAL-Daten verarbeitet. |
| max\$1wal\$1size | Dynamisch | Legt die WAL-Größe (MB) fest, die den Prüfpunkt auslöst. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Verwenden Sie den folgenden Befehl auf der DB-Instance von RDS für PostgreSQL, um den aktuellen Wert zu sehen.
SHOW max_wal_size;
|
| min\$1wal\$1size | Dynamisch | Legt die Mindestgröße fest, auf die das WAL verkleinert werden soll. Für PostgreSQL-Version 9.6 und früher liegt min\$1wal\$1size in Einheiten von 16 MB vor. Für PostgreSQ-Version 10 und höher liegt min\$1wal\$1size in Einheiten von 1 MB vor. |
| `quote_all_identifiers` | Dynamisch | Fügt beim Generieren von SQL-Fragmenten allen Bezeichnern Anführungszeichen (") hinzu. |
| `random_page_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten einer nicht sequenziell abgerufenen Datenträgerseite fest. Dieser Parameter hat keinen Wert, es sei denn, die Abfrageplanverwaltung (QPM) ist aktiviert. Wenn QPM aktiviert ist, lautet der Standardwert für diesen Parameter 4. |
| rds.adaptive\$1autovacuum | Dynamisch | Optimiert die Selbstbereinigungsparameter automatisch, wenn die Transaktions-ID-Schwellenwerte überschritten werden. |
| rds.force\$1ssl | Dynamisch | Erfordert die Verwendung von SSL-Verbindungen. Der Standardwert ist für RDS für PostgreSQL Version 15 auf 1 (ein) festgelegt. Bei allen anderen Hauptversionen von RDS für PostgreSQL bis 14 ist der Standardwert auf 0 (aus) festgelegt. |
| `rds.local_volume_spill_enabled` | Statisch | Ermöglicht das Schreiben logischer Spill-Dateien auf das lokale Volume. |
| `rds.log_retention_period` | Dynamisch | Legt die Protokollaufbewahrung so fest, dass Amazon RDS PostgreSQL-Protokolle löscht, die älter als n Minuten sind. |
| rds.rds\$1superuser\$1reserved\$1connections | Statisch | Legt die Anzahl der Verbindungs-Slots fest, die für rds\$1superusers reserviert sind. Dieser Parameter ist nur für Version 15 und niedriger verfügbar. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Dynamisch | Wenn Sie diesen Parameter auf `on` festlegen, überschreibt er die Einstellung der Replikatidentität für alle Datenbanktabellen auf `FULL`. Das bedeutet, dass alle Spaltenwerte unabhängig von Ihren `REPLICA IDENTITY FULL`-Einstellungen in das Write-Ahead-Protokoll (WAL) geschrieben werden. Das Aktivieren dieses Parameters kann die IOPS Ihrer Datenbank-Instance aufgrund der zusätzlichen WAL-Protokollierung erhöhen. |
| rds.restrict\$1password\$1commands | Statisch | Schränkt ein, wer Passwörter für Benutzer mit der Rolle rds\$1password verwalten darf. Setzen Sie diesen Parameter auf 1, um die Passwortbeschränkung zu aktivieren. Der Standardwert ist 0. |
| `search_path` | Dynamisch | Legt die Schemasuchreihenfolge für Namen fest, die nicht schemaqualifiziert sind. |
| `seq_page_cost` | Dynamisch | Legt die Schätzung des Planers für die Kosten einer sequenziell abgerufenen Datenträgerseite fest. |
| `session_replication_role` | Dynamisch | Legt das Sitzungsverhalten für Auslöser und Neuschreibungsregeln fest. |
| `shared_buffers` | Statisch | Legt die maximale Anzahl freigegebener Arbeitsspeicherpuffer fest, die vom Server verwendet werden. |
| `shared_preload_libraries ` | Statisch | Listet die freigegebenen Bibliotheken auf, die in die DB-Instance von RDS für PostgreSQL vorab geladen werden sollen. Zu den unterstützten Werten gehören: auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler und plrust. |
| `ssl` | Dynamisch | Ermöglicht SSL-Verbindungen. |
| `sql_inheritance` | Dynamisch | Veranlasst den standardmäßigen Einschluss von Untertabellen in verschiedene Befehle. |
| `ssl_renegotiation_limit` | Dynamisch | Legt die Menge des Datenverkehrs fest, der gesendet und empfangen werden soll, bevor die Verschlüsselungsschlüssel neu verhandelt werden. |
| `standard_conforming_strings` | Dynamisch | Veranlasst Zeichenfolgen „...“, Backslashes als Zeichen zu behandeln. |
| `statement_timeout` | Dynamisch | Legt die maximal zulässige Dauer von Anweisungen fest. |
| `synchronize_seqscans` | Dynamisch | Ermöglicht synchronisierte sequenzielle Prüfungen. |
| `synchronous_commit` | Dynamisch | Legt die Synchronisierungsstufe aktueller Transaktionen fest. |
| `tcp_keepalives_count` | Dynamisch | Maximale Anzahl von TCP-Keepalive-Neuübertragungen. |
| `tcp_keepalives_idle` | Dynamisch | Zeit zwischen der Ausgabe von TCP-Keepalives. |
| `tcp_keepalives_interval` | Dynamisch | Zeit zwischen der Ausgabe von TCP-Keepalive-Neuübertragungen. |
| `temp_buffers` | Dynamisch | Legt die maximale Anzahl der temporären Puffer fest, die von den einzelnen Sitzungen verwendet werden. |
| temp\$1file\$1limit | Dynamisch | Legt die maximale Größe in KB fest, temporären Dateien maximal annehmen können. |
| `temp_tablespaces` | Dynamisch | Legt die Tabellenräume fest, die für temporäre Tabellen und Sortierdateien verwendet werden sollen. |
| `timezone` | Dynamisch | Legt die Zeitzone für die Anzeige und Interpretation von Zeitstempeln fest. Die Internet Assigned Numbers Authority (IANA) veröffentlicht mehrmals im Jahr neue Zeitzonen unter [https://www.iana.org/time-zones](https://www.iana.org/time-zones). Jedes Mal, wenn RDS eine neue Wartungsnebenversion von PostgreSQL veröffentlicht, wird diese mit den neuesten Zeitzonendaten zum Zeitpunkt der Veröffentlichung ausgeliefert. Wenn Sie die neuesten Versionen von RDS für PostgreSQL verwenden, verfügen Sie über aktuelle Zeitzonendaten von RDS. Wenn Sie sichergehen möchten, dass Ihre DB-Instance über aktuelle Zeitzonendaten verfügt, empfehlen wir ein Upgrade auf eine höhere DB-Engine-Version. Sie können die Zeitzonen-Tabellen in PostgreSQL-DB-Instances nicht ändern. Die Zeitzonendaten laufender DB-Instances werden von RDS nicht geändert oder zurückgesetzt. Neue Zeitzonendaten werden nur installiert, wenn Sie ein Upgrade der Datenbank-Engine-Version durchführen. |
| `track_activities` | Dynamisch | Sammelt Informationen zu Befehlen, die ausgeführt werden. |
| `track_activity_query_size` | Statisch | Legt die für pg\$1stat\$1activity.current\$1query reservierte Größe in Bytes fest. |
| `track_counts` | Dynamisch | Sammelt Statistiken zur Datenbankaktivität. |
| `track_functions` | Dynamisch | Sammelt Statistiken auf Funktionsebene zur Datenbankaktivität. |
| `track_io_timing` | Dynamisch | Sammelt Zeitstatistiken zur Datenbankaktivität. I/O |
| `transaction_deferrable` | Dynamisch | Gibt an, ob eine schreibgeschützte serialisierbare Transaktion aufgeschoben werden kann, bis sie ohne mögliche Serialisierungsfehler gestartet werden kann. |
| `transaction_isolation` | Dynamisch | Legt die Isolierungsstufe aktueller Transaktionen fest. |
| `transaction_read_only` | Dynamisch | Legt den Schreibschutzstatus aktueller Transaktionen fest. |
| `transform_null_equals` | Dynamisch | Behandelt expr=NULL als expr IS NULL. |
| `update_process_title` | Dynamisch | Aktualisiert den Titel des Vorgangs, um den aktiven SQL-Befehl anzuzeigen. |
| `vacuum_cost_delay` | Dynamisch | Bereinigungskostenverzögerung (in Millisekunden). |
| `vacuum_cost_limit` | Dynamisch | Bereinigungskostenbetrag, der vor der Inaktivität verfügbar ist. |
| `vacuum_cost_page_dirty` | Dynamisch | Bereinigungskosten für eine Seite, die durch eine Bereinigung ungültig wurde. |
| `vacuum_cost_page_hit` | Dynamisch | Bereinigungskosten für eine Seite, die im Puffer-Cache gefunden wurde. |
| `vacuum_cost_page_miss` | Dynamisch | Bereinigungskosten für eine Seite, die nicht im Puffer-Cache gefunden wurde. |
| `vacuum_defer_cleanup_age` | Dynamisch | Anzahl der Transaktionen, um die Bereinigung und Hot Cleanup aufgeschoben werden sollen, wenn vorhanden. |
| `vacuum_freeze_min_age` | Dynamisch | Mindestalter, bei dem die Bereinigung eine Tabellenzeile eingefroren werden sollte. |
| `vacuum_freeze_table_age` | Dynamisch | Alter, bei dem die Bereinigung eine Tabelle vollständig scannen sollte, um Tupel einzufrieren. |
| `wal_buffers` | Statisch | Legt die Anzahl von Datenträgerseitenpuffern im freigegebenen Arbeitsspeicher für WAL fest. |
| `wal_writer_delay` | Dynamisch | Inaktivitätszeit des WAL-Schreibers zwischen WAL-Flushes. |
| `work_mem` | Dynamisch | Legt den maximalen Arbeitsspeicher fest, der für Abfrage-Workspaces verwendet werden darf. |
| `xmlbinary` | Dynamisch | Legt die Kodierung von Binärwerten in XML fest. |
| `xmloption` | Dynamisch | Legt fest, ob XML-Daten in impliziten Parsing- und Serialisierungsoperationen als Dokumente oder Inhaltsfragmente betrachtet werden sollen. |
Amazon RDS verwendet die PostgreSQL-Standardeinheiten für alle Parameter. Die folgende Tabelle zeigt die PostgreSQL-Standardeinheit für die einzelnen Parameter.
| Parametername | Einheit |
| --- | --- |
| `archive_timeout` | S |
| `authentication_timeout` | S |
| `autovacuum_naptime` | S |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | S |
| `checkpoint_warning` | S |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | Minuten |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | S |
| `pre_auth_delay` | S |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | S |
| `tcp_keepalives_interval` | S |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | S |
# Optimierung mit Warteereignissen für RDS für PostgreSQL
Warteereignisse sind ein wichtiges Optimierungs-Tool für RDS für PostgreSQL. Wenn Sie herausfinden können, warum Sitzungen auf Ressourcen warten und was sie tun, können Sie Engpässe besser reduzieren. Anhand der Informationen in diesem Abschnitt können Sie mögliche Ursachen und Abhilfemaßnahmen ermitteln. In diesem Abschnitt werden außerdem grundlegende PostgreSQL-Optimierungskonzepte erörtert.
Die Warteereignisse in diesem Abschnitt gelten speziell für RDS für PostgreSQL.
**Topics**
+ [Grundlegende Konzepte für die Optimierung von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.md)
+ [Warteereignisse von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.summary.md)
+ [Kunde: ClientRead](wait-event.clientread.md)
+ [Kunde: ClientWrite](wait-event.clientwrite.md)
+ [CPU](wait-event.cpu.md)
+ [IO: BufFileRead und IO: BufFileWrite](wait-event.iobuffile.md)
+ [IO: DataFileRead](wait-event.iodatafileread.md)
+ [IO:WALWrite](wait-event.iowalwrite.md)
+ [IPC:parallel-Warteereignisse](rpg-ipc-parallel.md)
+ [IPC: ProcArrayGroupUpdate](apg-rpg-ipcprocarraygroup.md)
+ [Lock:advisory](wait-event.lockadvisory.md)
+ [Lock:extend](wait-event.lockextend.md)
+ [Lock:Relation](wait-event.lockrelation.md)
+ [Lock:transactionid](wait-event.locktransactionid.md)
+ [Lock:tuple](wait-event.locktuple.md)
+ [LWLock: BufferMapping (:buffer\$1mapping) LWLock](wait-event.lwl-buffer-mapping.md)
+ [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md)
+ [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md)
+ [LWLock:lock\$1manager (:lockmanager) LWLock](wait-event.lw-lock-manager.md)
+ [LWLock:pg\$1stat\$1statements](apg-rpg-lwlockpgstat.md)
+ [LWLock:subtransSLRU (:) LWLock SubtransControlLock](wait-event.lwlocksubtransslru.md)
+ [Timeout:PgSleep](wait-event.timeoutpgsleep.md)
+ [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md)
# Grundlegende Konzepte für die Optimierung von RDS für PostgreSQL
Bevor Sie Ihre Datenbank von RDS für PostgreSQL optimieren, sollten Sie wissen, was Warteereignisse sind und warum sie auftreten. Sehen Sie sich auch die grundlegende Speicher- und Festplattenarchitektur von RDS für PostgreSQL an. Ein hilfreiches Architekturdiagramm finden Sie im [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture)-Wikibook.
**Topics**
+ [Warteereignisse von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.waits.md)
+ [Speicher von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.memory.md)
+ [Prozesse von RDS für PostgreSQL](PostgreSQL.Tuning.concepts.processes.md)
# Warteereignisse von RDS für PostgreSQL
Ein *Warteereignis* ist ein Hinweis darauf, dass die Sitzung auf eine Ressource wartet. Das Warteereignis `Client:ClientRead` tritt beispielsweise auf, wenn RDS für PostgreSQL darauf wartet, Daten vom Client zu empfangen. Sitzungen warten in der Regel auf Ressourcen wie die folgenden.
+ Singlethread-Zugriff auf einen Puffer, beispielsweise wenn eine Sitzung versucht, einen Puffer zu ändern
+ Eine Zeile, die derzeit von einer anderen Sitzung gesperrt ist
+ Eine gelesene Datendatei
+ Eine geschriebene Protokolldatei
Um beispielsweise eine Abfrage zu erfüllen, kann die Sitzung einen vollständigen Tabellenscan durchführen. Wenn sich die Daten noch nicht im Arbeitsspeicher befinden, wartet die Sitzung, bis die Datenträger-I/O abgeschlossen ist. Wenn die Puffer in den Speicher gelesen werden, muss die Sitzung möglicherweise warten, da andere Sitzungen auf dieselben Puffer zugreifen. Die Datenbank zeichnet die Wartezeiten unter Verwendung eines vordefinierten Warteereignisses auf. Diese Ereignisse sind in Kategorien eingeteilt.
Ein einzelnes Warteereignis ist kein Anzeichen für ein Leistungsproblem. Wenn sich beispielsweise die angeforderten Daten nicht im Speicher befinden, müssen die Daten von der Festplatte gelesen werden. Wenn eine Sitzung eine Zeile für eine Aktualisierung sperrt, wartet eine andere Sitzung darauf, dass die Zeile entsperrt wird, damit sie sie aktualisieren kann. Bei einem Commit muss gewartet werden, bis der Schreibvorgang in eine Protokolldatei abgeschlossen ist. Wartezeiten sind ein wesentlicher Bestandteil des normalen Funktionierens einer Datenbank.
Eine große Anzahl von Warteereignissen hingegen weist normalerweise auf ein Leistungsproblem hin. In solchen Fällen können Sie Warteereignisdaten verwenden, um zu bestimmen, wo die Sitzungen Zeit verbringen. Wenn beispielsweise ein Bericht, der normalerweise in Minuten ausgeführt wird, jetzt Stunden dauert, können Sie die Warteereignisse identifizieren, die am meisten zur Gesamtwartezeit beitragen. Wenn Sie die Ursachen für die häufigsten Warteereignisse ermitteln können, können Sie manchmal Änderungen vornehmen, die die Leistung verbessern. Wenn Ihre Sitzung beispielsweise auf eine Zeile wartet, die von einer anderen Sitzung gesperrt wurde, können Sie die Sperrsitzung beenden.
# Speicher von RDS für PostgreSQL
Der Arbeitsspeicher von RDS für PostgreSQL ist in gemeinsam genutztem und lokalem Speicher unterteilt.
**Topics**
+ [Gemeinsam genutzter Arbeitsspeicher von RDS für PostgreSQL](#PostgreSQL.Tuning.concepts.shared)
+ [Lokaler Arbeitsspeicher in RDS für PostgreSQL](#PostgreSQL.Tuning.concepts.local)
## Gemeinsam genutzter Arbeitsspeicher von RDS für PostgreSQL
RDS für PostgreSQL weist beim Start der Instance gemeinsam genutzten Speicher zu. Shared Memory ist in mehrere Teilbereiche unterteilt. Die folgenden Abschnitte enthalten Beschreibungen der wichtigsten Teilbereiche.
**Topics**
+ [Freigegebene Puffer](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [Write-Ahead-Protokoll (WAL)-Puffer](#PostgreSQL.Tuning.concepts.WAL)
### Freigegebene Puffer
Der *freigegebene Pufferpool* ist ein Speicherbereich von RDS für PostgreSQL, der alle Seiten enthält, die von Anwendungsverbindungen verwendet werden oder wurden. Eine *Seite* ist die Speicherversion eines Plattenblocks. Der gemeinsam genutzte Pufferpool zwischenspeichert die von der Platte gelesenen Datenblöcke. Der Pool reduziert die Notwendigkeit, Daten erneut von der Festplatte zu lesen, wodurch die Datenbank effizienter arbeitet.
Jede Tabelle und jeder Index wird als Array von Seiten einer festen Größe gespeichert. Jeder Block enthält mehrere Tupel, die Zeilen entsprechen. Ein Tupel kann auf jeglicher Seite gespeichert werden.
Der gemeinsam genutzte Pufferpool hat endlichen Speicher. Wenn eine neue Anforderung eine Seite erfordert, die sich nicht im Speicher befindet und kein Speicher mehr vorhanden ist, entfernt RDS für PostgreSQL eine weniger häufig verwendete Seite, um die Anforderung zu erfüllen. Die Räumungsrichtlinie wird durch einen Takt-Sweep-Algorithmus implementiert.
Der Parameter `shared_buffers` bestimmt, wie viel Speicher der Server für das Caching von Daten bereitstellt. Der Standardwert ist auf `{DBInstanceClassMemory/32768}` Byte festgelegt, basierend auf dem verfügbaren Speicher für die DB-Instance.
### Write-Ahead-Protokoll (WAL)-Puffer
Ein *Write-Ahead-Protokoll-Puffer (WAL)* enthält Transaktionsdaten, die RDS für PostgreSQL später in den persistenten Speicher schreibt. Mithilfe des WAL-Mechanismus kann RDS für PostgreSQL folgende Vorgänge ausführen:
+ Daten nach einem Fehler wiederherstellen
+ Reduzieren Sie die I/O Festplattenkapazität, indem Sie häufige Schreibvorgänge auf die Festplatte vermeiden
Wenn ein Client Daten ändert, schreibt RDS für PostgreSQL die Änderungen in den WAL-Puffer. Wenn der Client einen `COMMIT` ausgibt, schreibt der WAL-Writerprozess Transaktionsdaten in die WAL-Datei.
Der Parameter `wal_level` bestimmt, wie viele Informationen in das WAL geschrieben werden. Mögliche Werte sind zum Beispiel `minimal`, `replica` und `logical`.
## Lokaler Arbeitsspeicher in RDS für PostgreSQL
Jeder Backend-Prozess weist lokalen Speicher für die Abfrageverarbeitung zu.
**Topics**
+ [Arbeitsspeicherbereich](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [Wartungs-Arbeitsspeicherbereich](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [Temporärer Pufferbereich](#PostgreSQL.Tuning.concepts.temp)
### Arbeitsspeicherbereich
Der *Arbeitsspeicherbereich* enthält temporäre Daten für Abfragen, die Sortierungen und Hashes durchführen. Beispielsweise führt eine Abfrage mit einer `ORDER BY`-Klausel eine Sortierung durch. Abfragen verwenden Hash-Tabellen in Hash-Joins und Aggregationen.
Der Parameter `work_mem` für die Speichergröße, die von internen Sortiervorgängen und Hash-Tabellen belegt werden soll, bevor in temporäre Festplattendateien geschrieben wird, gemessen in Megabyte. Der Standardwert lautet 4 MB. Mehrere Sitzungen können gleichzeitig ausgeführt werden, und jede Sitzung kann Wartungsvorgänge parallel ausführen. Aus diesem Grund kann der gesamte verwendete Arbeitsspeicher ein Vielfaches der Einstellung `work_mem` betragen.
### Wartungs-Arbeitsspeicherbereich
Der *Wartungsarbeitsspeicherbereich* speichert Daten für Wartungsvorgänge zwischen. Zu diesen Vorgängen gehören das Vakuumieren, das Erstellen eines Index und das Hinzufügen von Fremdschlüsseln.
Der Parameter `maintenance_work_mem` gibt die maximale Speichergröße an, die von Wartungsvorgängen verwendet werden soll, gemessen in Megabyte. Der Standardwert lautet 64 MB. In einer Datenbanksitzung kann jeweils nur ein Wartungsvorgang ausgeführt werden.
### Temporärer Pufferbereich
Der *temporäre Pufferbereich* speichert temporäre Tabellen für jede Datenbanksitzung zwischen.
Jede Sitzung weist temporäre Puffer nach Bedarf bis zu dem von Ihnen angegebenen Limit zu. Wenn die Sitzung endet, löscht der Server die Puffer.
Der Parameter `temp_buffers` legt die maximale Anzahl temporärer Puffer fest, die von der jeweiligen Sitzung verwendet werden, gemessen in Megabyte. Der Standardwert ist 8 MB. Vor der ersten Verwendung temporärer Tabellen innerhalb einer Sitzung können Sie den `temp_buffers`-Wert ändern.
# Prozesse von RDS für PostgreSQL
RDS für PostgreSQL verwendet mehrere Prozesse.
**Topics**
+ [Postmaster-Prozess](#PostgreSQL.Tuning.concepts.postmaster)
+ [Backend-Prozesse](#PostgreSQL.Tuning.concepts.backend)
+ [Hintergrundprozesse](#PostgreSQL.Tuning.concepts.vacuum)
## Postmaster-Prozess
Der *Postmaster-Prozess* ist der erste Prozess, der beim Öffnen von RDS für PostgreSQL gestartet wird. Der Postmaster-Prozess hat die folgenden Hauptaufgaben:
+ Hintergrundprozesse teilen und überwachen
+ Empfangen Sie Authentifizierungsanfragen von Clientprozessen und authentifizieren Sie sie, bevor Sie der Datenbank erlauben, Anfragen zu bearbeiten
## Backend-Prozesse
Wenn der Postmaster eine Client-Anfrage authentifiziert, forkisiert der Postmaster einen neuen Backend-Prozess, auch Postgres-Prozess genannt. Ein Client-Prozess verbindet sich mit genau einem Backend-Prozess. Der Client-Prozess und der Backend-Prozess kommunizieren direkt ohne Eingriff des Postmaster-Prozesses.
## Hintergrundprozesse
Der Postmaster-Prozess teilt mehrere Prozesse, die unterschiedliche Backend-Aufgaben ausführen. Einige der wichtigeren sind die folgenden:
+ WAL-Writer
Aurora PostgreSQL schreibt Daten im WAL-Puffer (Write Ahead Logging) in die Protokolldateien. Das Prinzip der Write-Ahead-Protokollierung besteht darin, dass die Datenbank keine Änderungen in die Datendateien schreiben kann, bis die Datenbank Protokolldatensätze geschrieben hat, die diese Änderungen auf die Festplatte beschreiben. Der WAL-Mechanismus reduziert Festplatten-I/O und ermöglicht RDS für PostgreSQL, die Protokolle zu verwenden, um die Datenbank nach einem Fehler wiederherzustellen.
+ Hintergrund-Autor
Dieser Prozess schreibt regelmäßig schmutzige (modifizierte) Seiten aus den Speicherpuffern in die Datendateien. Eine Seite wird schmutzig, wenn ein Backend-Prozess sie im Speicher ändert.
+ Autovacuum-Daemon
Der Daemon besteht aus Folgendem:
+ Der Autovacuum-Launcher
+ Die Autovacuum-Worker-Prozesse
Wenn Autovacuum aktiviert ist, sucht es nach Tabellen mit einer großen Anzahl eingefügter, aktualisierter oder gelöschter Tupel. Der Daemon hat folgende Aufgaben:
+ Wiederherstellen oder Wiederverwenden von Speicherplatz, der von aktualisierten oder gelöschten Zeilen belegt ist
+ Vom Planer verwendete Statistiken aktualisieren
+ Schutz vor Verlust alter Daten durch Transaktions-ID-Wraparound
Die Autovacuum-Funktion automatisiert die Ausführung von `VACUUM`- und `ANALYZE`-Befehlen. `VACUUM` hat folgende Varianten: Standard und Voll. Standardvakuum läuft parallel zu anderen Datenbankvorgängen. `VACUUM FULL` erfordert eine exklusive Sperre für die Tabelle, an der es arbeitet. Daher kann es nicht parallel zu Vorgängen ausgeführt werden, die auf dieselbe Tabelle zugreifen. `VACUUM`erzeugt eine beträchtliche Menge an I/O Datenverkehr, was zu Leistungseinbußen bei anderen aktiven Sitzungen führen kann.
# Warteereignisse von RDS für PostgreSQL
Die folgende Tabelle listet die Warteereignisse für RDS für PostgreSQL auf, die am häufigsten auf Leistungsprobleme hinweisen, und fasst die häufigsten Ursachen und Korrekturmaßnahmen zusammen.
| Warteereignis | Definition |
| --- | --- |
| [Kunde: ClientRead](wait-event.clientread.md) | Dieses Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, Daten vom Client zu empfangen. |
| [Kunde: ClientWrite](wait-event.clientwrite.md) | Dieses Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, Daten an den Client zu schreiben. |
| [CPU](wait-event.cpu.md) | Dieses Ereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet. |
| [IO: BufFileRead und IO: BufFileWrite](wait-event.iobuffile.md) | Diese Ereignisse treten auf, wenn RDS für PostgreSQL temporäre Dateien erstellt. |
| [IO: DataFileRead](wait-event.iodatafileread.md) | Dieses Ereignis tritt auf, wenn eine Verbindung darauf wartet, dass ein Backend-Prozess eine erforderliche Seite aus dem Speicher liest, da die Seite nicht im gemeinsam genutzten Speicher verfügbar ist. |
| [IO:WALWrite](wait-event.iowalwrite.md) | Dieses Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, dass die Write-Ahead-Protokoll-Puffer (WAL) in eine WAL-Datei geschrieben werden. |
| [Lock:advisory](wait-event.lockadvisory.md) | Dieses Ereignis tritt auf, wenn eine PostgreSQL-Anwendung eine Sperre verwendet, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren. |
| [Lock:extend](wait-event.lockextend.md) | Dieses Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Beziehung zu sperren, um sie zu erweitern, während ein anderer Prozess diese Beziehung für denselben Zweck gesperrt hat. |
| [Lock:Relation](wait-event.lockrelation.md) | Dieses Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Ansicht zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist. |
| [Lock:transactionid](wait-event.locktransactionid.md) | Dieses Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet. |
| [Lock:tuple](wait-event.locktuple.md) | Dieses Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Sperre für ein Tupel zu erlangen. |
| [LWLock: BufferMapping (:buffer\$1mapping) LWLock](wait-event.lwl-buffer-mapping.md) | Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Datenblock einem Puffer im gemeinsam genutzten Pufferpool zuzuordnen. |
| [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md) | Dieses Ereignis tritt auf, wenn RDS for PostgreSQL darauf wartet, dass andere Prozesse ihre input/output (I/O-) Operationen beenden, wenn gleichzeitig versucht wird, auf eine Seite zuzugreifen. |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, eine Datenseite im Speicher zu lesen oder zu schreiben, während eine andere Sitzung diese Seite zum Schreiben gesperrt hat. |
| [LWLock:lock\$1manager (:lockmanager) LWLock](wait-event.lw-lock-manager.md) | Dieses Ereignis tritt auf, wenn die Engine von RDS für PostgreSQL den Speicherbereich der gemeinsam genutzten Sperre verwaltet, um eine Sperre zuzuweisen, zu überprüfen und aufzuheben, wenn eine Fast-Path-Sperre nicht möglich ist. |
| [LWLock:subtransSLRU (:) LWLock SubtransControlLock](wait-event.lwlocksubtransslru.md) | Dieses Ereignis tritt auf, wenn ein Prozess darauf wartet, auf den SLRU-Cache (Simple Least-Recently Used) für eine Subtransaktion zuzugreifen. |
| [Timeout:PgSleep](wait-event.timeoutpgsleep.md) | Dieses Ereignis tritt ein, wenn ein Serverprozess die Funktion `pg_sleep` aufgerufen hat und darauf wartet, dass das Sleep-Timeout abläuft. |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | Dieses Ereignis weist darauf hin, dass der Bereinigungsprozess inaktiv ist, da die geschätzte Kostengrenze erreicht wurde. |
# Kunde: ClientRead
Das `Client:ClientRead`-Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, Daten vom Client zu empfangen.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.clientread.context.supported)
+ [Kontext](#wait-event.clientread.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.clientread.causes)
+ [Aktionen](#wait-event.clientread.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für RDS für PostgreSQL Version 10 und höher unterstützt.
## Kontext
Eine DB-Instance von RDS für PostgreSQL wartet darauf, Daten vom Client zu empfangen. Die DB-Instance von RDS für PostgreSQL muss die Daten vom Client empfangen, bevor sie weitere Daten an den Client senden kann. Die Zeit, die die Instance wartet, bevor sie Daten vom Client empfängt, ist ein `Client:ClientRead`-Ereignis.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Häufige Gründe dafür, dass das `Client:ClientRead`-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:
**Erhöhte Netzwerklatenz**
Es kann zu einer erhöhten Netzwerklatenz zwischen dem DB-Cluster von RDS für PostgreSQL und dem Client kommen. Eine höhere Netzwerklatenz erhöht die Zeit, die die DB-Instance benötigt, um Daten vom Client zu empfangen.
**Erhöhte Belastung des Clients**
Auf dem Client kann es zu CPU-Druck oder Netzwerksättigung kommen. Eine Zunahme der Last auf dem Client kann die Übertragung von Daten vom Client zur DB-Instance von RDS für PostgreSQL verzögern.
**Übermäßige Netzwerkrundfahrten**
Eine große Anzahl von Netzwerk-Roundtrips zwischen der DB-Instance von RDS für PostgreSQL und dem Client kann die Datenübertragung vom Client zur DB-Instance von RDS für PostgreSQL verzögern.
**Großer Kopiervorgang**
Während eines Kopiervorgangs werden die Daten vom Dateisystem des Clients an die DB-Instance von RDS für PostgreSQL übertragen. Das Senden einer großen Datenmenge an die DB-Instance kann die Übertragung von Daten vom Client zur DB-Instance verzögern.
**Verbindung von Clients im Leerlauf**
Wenn sich ein Client in einem `idle in transaction`-Zustand mit der DB-Instance von RDS für PostgreSQL verbindet, wartet die DB-Instance möglicherweise darauf, dass der Client weitere Daten sendet oder einen Befehl ausgibt. Eine Verbindung in diesem Zustand kann zu einer Zunahme von `Client:ClientRead`-Ereignissen führen.
**PgBouncer wird für das Verbindungspooling verwendet**
PgBouncer hat eine Netzwerkkonfigurationseinstellung auf niedriger Ebene aufgerufen`pkt_buf`, die standardmäßig auf 4.096 gesetzt ist. Wenn der Workload Abfragepakete mit mehr als 4.096 Byte durchsendet, empfehlen wir PgBouncer, die Einstellung auf 8.192 zu erhöhen. `pkt_buf` Wenn die neue Einstellung die Anzahl der `Client:ClientRead`-Ereignisse nicht verringert, empfehlen wir, die `pkt_buf`-Einstellung auf höhere Werte zu erhöhen, z. B. 16.384 oder 32.768. Wenn der Abfragetext groß ist, kann die größere Einstellung besonders hilfreich sein.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Platzieren Sie die Clients in derselben Availability Zone und im gleichen VPC-Subnetz wie die Instance](#wait-event.clientread.actions.az-vpc-subnet)
+ [Skalieren Sie Ihren -C](#wait-event.clientread.actions.scale-client)
+ [Instances der aktuellen Generation verwenden](#wait-event.clientread.actions.db-instance-class)
+ [Erhöhung der Netzwerkbandbreite](#wait-event.clientread.actions.increase-network-bandwidth)
+ [Überwachen Sie Maximen für die Netzwerkleistung](#wait-event.clientread.actions.monitor-network-performance)
+ [Überwachen Sie auf Transaktionen im Status „Leerlauf in Transaktion“](#wait-event.clientread.actions.check-idle-in-transaction)
### Platzieren Sie die Clients in derselben Availability Zone und im gleichen VPC-Subnetz wie die Instance
Um die Netzwerklatenz zu reduzieren und den Netzwerkdurchsatz zu erhöhen, platzieren Sie Clients in dieselbe Availability Zone und das gleiche Virtual Private Cloud (VPC)-Subnetz wie die DB-Instance von RDS für PostgreSQL. Stellen Sie sicher, dass sich die Clients geografisch so nah wie möglich an der DB-Instance befinden.
### Skalieren Sie Ihren -C
Ermitteln Sie anhand von Amazon CloudWatch oder anderen Host-Metriken, ob Ihr Client derzeit durch CPU- oder Netzwerkbandbreite oder beides eingeschränkt ist. Wenn der Kunde eingeschränkt ist, skalieren Sie Ihren Kunden entsprechend.
### Instances der aktuellen Generation verwenden
In einigen Fällen verwenden Sie möglicherweise keine DB-Instance-Klasse, die Jumbo-Frames unterstützt. Wenn Sie Ihre Anwendung auf Amazon EC2 ausführen, sollten Sie eine Instance der aktuellen Generation für den Client verwenden. Konfigurieren Sie außerdem die maximale Übertragungseinheit (MTU) im Kundenvorgangssystem Diese Technik könnte die Anzahl der Netzläufe reduzieren und den Netzwerkdurchsatz erhöhen. Weitere Informationen finden Sie unter [Jumbo-Frames (9.001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) im *Amazon-EC2-Benutzerhandbuch*.
Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md). Um die DB-Instance-Klasse zu bestimmen, die einem Amazon EC2-Instance-Typ entspricht, platzieren Sie `db.` vor dem Namen des Amazon EC2-Instance-Typs. Beispielsweise entspricht die `r5.8xlarge`-Amazon EC2-Instance der `db.r5.8xlarge`-DB-Instance-Klasse.
### Erhöhung der Netzwerkbandbreite
Verwenden Sie `NetworkReceiveThroughput` und `NetworkTransmitThroughput` CloudWatch Amazon-Metriken, um den eingehenden und ausgehenden Netzwerkverkehr auf der DB-Instance zu überwachen. Diese Metriken können Ihnen helfen festzustellen, ob die Netzwerkbandbreite für Ihre Workload ausreicht.
Wenn Ihre Netzwerkbandbreite nicht ausreicht, erhöhen Sie sie. Wenn der AWS Client oder Ihre DB-Instance die Netzwerkbandbreitenlimits erreicht, besteht die einzige Möglichkeit, die Bandbreite zu erhöhen, darin, Ihre DB-Instance-Größe zu erhöhen. Weitere Informationen finden Sie unter [DB-Instance-Klassenarten](Concepts.DBInstanceClass.Types.md).
Weitere Informationen zu CloudWatch Metriken finden Sie unter[CloudWatch Amazon-Metriken für Amazon RDS](rds-metrics.md).
### Überwachen Sie Maximen für die Netzwerkleistung
Wenn Sie Amazon EC2-Clients verwenden, bietet Amazon EC2 Maximum für Netzwerkleistungsmetriken, einschließlich der aggregierten eingehenden und ausgehenden Netzwerkbandbreite. Es bietet auch Verbindungsverfolgung, um sicherzustellen, dass Pakete wie erwartet zurückgegeben werden, und Zugriff auf Link-lokale Dienste für Dienste wie das Domain Name System (DNS). Um diese Maximen zu überwachen, verwenden Sie einen aktuell erweiterten Netzwerktreiber und überwachen Sie die Netzwerkleistung für Ihren Client.
Weitere Informationen finden Sie unter [Überwachen der Netzwerkleistung für Ihre Amazon-EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) im *Amazon-EC2-Benutzerhandbuch* und unter [Überwachen der Netzwerkleistung für Ihre Amazon-EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) im *Amazon-EC2-Benutzerhandbuch*.
### Überwachen Sie auf Transaktionen im Status „Leerlauf in Transaktion“
Überprüfen Sie, ob Sie eine steigende Anzahl von `idle in transaction`-Verbindungen haben. Beobachten Sie dazu die `state`-Spalte in der `pg_stat_activity`-Tabelle. Möglicherweise können Sie die Verbindungsquelle identifizieren, indem Sie eine Abfrage ähnlich der folgenden ausführen.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# Kunde: ClientWrite
Das `Client:ClientWrite`-Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, Daten an den Client zu schreiben.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.clientwrite.context.supported)
+ [Kontext](#wait-event.clientwrite.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.clientwrite.causes)
+ [Aktionen](#wait-event.clientwrite.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für RDS für PostgreSQL Version 10 und höher unterstützt.
## Kontext
Ein Clientprozess muss alle Daten lesen, die von einem DB-Cluster von RDS für PostgreSQL empfangen wurden, bevor der Cluster weitere Daten senden kann. Die Zeit, die der Cluster wartet, bevor weitere Daten an den Client gesendet werden, ist ein `Client:ClientWrite`-Ereignis.
Ein reduzierter Netzwerkdurchsatz zwischen dem DB-Cluster von RDS für PostgreSQL und dem Client kann dieses Ereignis verursachen. CPU-Druck und Netzwerksättigung auf dem Client können dieses Ereignis ebenfalls verursachen. *CPU-Druck* liegt vor, wenn die CPU voll ausgelastet ist und Aufgaben auf CPU-Zeit warten. *Eine Netzwerksättigung* liegt vor, wenn das Netzwerk zwischen Datenbank und Client mehr Daten überträgt, als es verarbeiten kann.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Häufige Gründe dafür, dass das `Client:ClientWrite`-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:
**Erhöhte Netzwerklatenz**
Es kann zu einer erhöhten Netzwerklatenz zwischen dem DB-Cluster von RDS für PostgreSQL und dem Client kommen. Eine höhere Netzwerklatenz erhöht die Zeit, die der Client benötigt, um die Daten zu empfangen.
**Erhöhte Belastung des Clients**
Auf dem Client kann es zu CPU-Druck oder Netzwerksättigung kommen. Eine Erhöhung der Last des Clients verzögert den Empfang von Daten aus der DB-Instance von RDS für PostgreSQL.
**Große Datenmenge, die an den Kunden gesendet werden**
Die DB-Instance von RDS für PostgreSQL sendet möglicherweise eine große Datenmenge an den Client. Ein Client kann die Daten möglicherweise nicht so schnell empfangen, wie der Cluster sie sendet. Aktivitäten wie das Kopieren einer großen Tabelle können zu einer Zunahme von `Client:ClientWrite`-Ereignissen führen.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Platzieren Sie die Clients im selben Availability Zone- und VPC-Subnetz wie der Cluster](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [Instances der aktuellen Generation verwenden](#wait-event.clientwrite.actions.db-instance-class)
+ [Reduzieren Sie die an den Kunden gesendeten Daten](#wait-event.clientwrite.actions.reduce-data)
+ [Skalieren Sie Ihren -C](#wait-event.clientwrite.actions.scale-client)
### Platzieren Sie die Clients im selben Availability Zone- und VPC-Subnetz wie der Cluster
Um die Netzwerklatenz zu reduzieren und den Netzwerkdurchsatz zu erhöhen, platzieren Sie Clients in dieselbe Availability Zone und das gleiche Virtual Private Cloud (VPC)-Subnetz wie die DB-Instance von RDS für PostgreSQL.
### Instances der aktuellen Generation verwenden
In einigen Fällen verwenden Sie möglicherweise keine DB-Instance-Klasse, die Jumbo-Frames unterstützt. Wenn Sie Ihre Anwendung auf Amazon EC2 ausführen, sollten Sie eine Instance der aktuellen Generation für den Client verwenden. Konfigurieren Sie außerdem die maximale Übertragungseinheit (MTU) im Kundenvorgangssystem Diese Technik könnte die Anzahl der Netzläufe reduzieren und den Netzwerkdurchsatz erhöhen. Weitere Informationen finden Sie unter [Jumbo-Frames (9.001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) im *Amazon-EC2-Benutzerhandbuch*.
Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md). Um die DB-Instance-Klasse zu bestimmen, die einem Amazon EC2-Instance-Typ entspricht, platzieren Sie `db.` vor dem Namen des Amazon EC2-Instance-Typs. Beispielsweise entspricht die `r5.8xlarge`-Amazon EC2-Instance der `db.r5.8xlarge`-DB-Instance-Klasse.
### Reduzieren Sie die an den Kunden gesendeten Daten
Passen Sie Ihre Anwendung nach Möglichkeit an, um die Datenmenge zu reduzieren, die die DB-Instance von RDS für PostgreSQL Cluster an den Client sendet. Solche Anpassungen entlasten die CPU- und Netzwerkkonflikte auf dem Client.
### Skalieren Sie Ihren -C
Ermitteln Sie anhand von Amazon CloudWatch oder anderen Host-Metriken, ob Ihr Client derzeit durch CPU- oder Netzwerkbandbreite oder beides eingeschränkt ist. Wenn der Client eingeschränkt ist, skalieren Sie Ihren Client entsprechend.
# CPU
Dieses Ereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.cpu.context.supported)
+ [Kontext](#wait-event.cpu.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.cpu.causes)
+ [Aktionen](#wait-event.cpu.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen sind für alle Versionen von RDS für PostgreSQL relevant.
## Kontext
Die *Zentrale Verarbeitungseinheit (CPU)* ist die Komponente eines Computers, die Anweisungen ausführt. Beispielsweise führen CPU-Anweisungen arithmetische Vorgänge aus und tauschen Daten im Speicher aus. Wenn eine Abfrage die Anzahl der Anweisungen erhöht, die sie über das Datenbank-Engine ausführt, erhöht sich der Zeitaufwand für die Ausführung der Abfrage. *CPU-Scheduling* gibt einem Prozess CPU-Zeit. Die Planung wird vom Kernel des Betriebssystems orchestriert.
**Topics**
+ [Wie kann man sagen, wann diese Wartezeit stattfindet](#wait-event.cpu.when-it-occurs)
+ [DBLoadCPU-Metrik](#wait-event.cpu.context.dbloadcpu)
+ [Metriken für Os.cPuUtilization](#wait-event.cpu.context.osmetrics)
+ [Wahrscheinliche Ursache für CPU-Planung](#wait-event.cpu.context.scheduling)
### Wie kann man sagen, wann diese Wartezeit stattfindet
Dieses `CPU`-Warteereignis zeigt an, dass ein Backend-Prozess in der CPU aktiv ist oder auf die CPU wartet. Sie wissen, dass es passiert, wenn eine Abfrage die folgenden Informationen anzeigt:
+ Die Spalte `pg_stat_activity.state` hat den Wert `active`.
+ Die Spalten `wait_event_type` und `wait_event` in `pg_stat_activity` sind beide `null`.
Führen Sie die folgende Abfrage aus, um die Backend-Prozesse anzuzeigen, die auf der CPU verwenden oder auf dieser warten.
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### DBLoadCPU-Metrik
Die Performance Insights-Metrik für CPU ist `DBLoadCPU`. Der Wert für `DBLoadCPU` kann vom Wert für die CloudWatch Amazon-Metrik abweichen`CPUUtilization`. Die letztere Metrik wird aus der HyperVisor für eine Datenbank-Instance erfasst.
### Metriken für Os.cPuUtilization
Performance Insights Betriebssystem-Metriken liefern detaillierte Informationen zur CPU-Auslastung. Sie können beispielsweise die folgenden Metriken anzeigen:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights meldet die CPU-Auslastung durch die Datenbank-Engine als `os.cpuUtilization.nice.avg`.
### Wahrscheinliche Ursache für CPU-Planung
Der Betriebssystem-Kernel übernimmt die Planung für die CPU. Wenn die CPU *aktiv* ist, muss ein Prozess möglicherweise warten, bis er geplant wird. Die CPU ist aktiv, während sie Berechnungen durchführt. Sie ist auch aktiv, wenn sie einen inaktiven Thread hat, der nicht läuft, d. h. ein inaktiver Thread, der auf Speicher wartet, I/O. This type of I/O dominiert die typische Datenbank-Arbeitslast.
Wenn die folgenden Bedingungen erfüllt sind, werden Prozesse wahrscheinlich warten, bis die folgenden Bedingungen erfüllt sind:
+ Die CloudWatch `CPUUtilization` Metrik liegt bei fast 100 Prozent.
+ Die durchschnittliche Last ist größer als die Zahl von vCPUs, was auf eine hohe Last hindeutet. Sie finden die `loadAverageMinute`-Metrik im Abschnitt Betriebssystemmetriken in Performance Insights.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das CPU-Warteereignis mehr als normal auftritt und möglicherweise auf ein Leistungsproblem hinweist, sind typische Ursachen die folgenden.
**Topics**
+ [Wahrscheinliche Ursachen für plötzliche Stacheln](#wait-event.cpu.causes.spikes)
+ [Wahrscheinliche Ursachen für langfristige Hochfrequenz](#wait-event.cpu.causes.long-term)
+ [Corner Cases](#wait-event.cpu.causes.corner-cases)
### Wahrscheinliche Ursachen für plötzliche Stacheln
Die wahrscheinlichsten Ursachen für plötzliche Stacheln sind wie folgt:
+ Ihre Anwendung hat zu viele gleichzeitige Verbindungen zur Datenbank geöffnet. Dieses Szenario wird als „Verbindungssturm“ bezeichnet.
+ Ihre Anwendungs-Workload hat sich auf eine der folgenden Weisen geändert:
+ Neue Anfragen
+ Eine Zunahme der Größe Ihres Datensatzes
+ Indexpflege oder -erstellung
+ Neue Funktionen
+ Neue Betreiber
+ Eine Zunahme der parallelen Abfrageausführung
+ Ihre Abfrageausführungspläne haben sich geändert. In einigen Fällen kann eine Änderung zu einem Anstieg der Puffer führen. Beispielsweise verwendet die Abfrage jetzt einen sequentiellen Scan, als sie zuvor einen Index verwendet hat. In diesem Fall benötigen die Abfragen mehr CPU, um dasselbe Ziel zu erreichen.
### Wahrscheinliche Ursachen für langfristige Hochfrequenz
Die wahrscheinlichsten Ursachen für Ereignisse, die über einen langen Zeitraum auftreten:
+ Zu viele Backend-Prozesse laufen gleichzeitig auf der CPU. Diese Prozesse können parallele Arbeiter sein.
+ Abfragen funktionieren suboptimal, da sie eine große Anzahl von Puffern benötigen.
### Corner Cases
Wenn sich herausstellt, dass keine der wahrscheinlichen Ursachen tatsächliche Ursachen ist, können folgende Situationen auftreten:
+ Die CPU tauscht Prozesse ein- und aus.
+ Die CPU verwaltet möglicherweise Seitentabelleneinträge, wenn die Funktion *Huge Pages* deaktiviert wurde. Die Speicherverwaltungsfunktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium. Weitere Informationen finden Sie unter [Huge Pages für RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md).
## Aktionen
Wenn das `CPU`-Wait-Ereignis die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. Reagieren Sie auf dieses Ereignis nur, wenn sich die Leistung verschlechtert.
**Topics**
+ [Untersuchen Sie, ob die Datenbank den CPU-Anstieg verursacht](#wait-event.cpu.actions.db-CPU)
+ [Bestimmen Sie, ob die Anzahl der Verbindungen gestiegen ist](#wait-event.cpu.actions.connections)
+ [Reagieren auf Workload-Änderungen](#wait-event.cpu.actions.workload)
### Untersuchen Sie, ob die Datenbank den CPU-Anstieg verursacht
Untersuchen Sie die `os.cpuUtilization.nice.avg`-Metrik in Performance Insights. Wenn dieser Wert weit unter der CPU-Auslastung liegt, tragen Nicht-Datenbankprozesse den Hauptbeitrag zur CPU bei.
### Bestimmen Sie, ob die Anzahl der Verbindungen gestiegen ist
Untersuchen Sie die `DatabaseConnections` Metrik in Amazon CloudWatch. Ihre Aktion hängt davon ab, ob die Zahl während des Zeitraums erhöhter CPU-Warteereignisse erhöht oder gesunken ist.
#### Die Verbindungen nahmen zu
Wenn die Anzahl der Verbindungen gestiegen ist, vergleichen Sie die Anzahl der Backend-Prozesse, die CPU verbrauchen, mit der Anzahl von v. CPUs Die folgenden Szenarien sind möglich:
+ Die Anzahl der Backend-Prozesse, die CPU verbrauchen, ist geringer als die Anzahl von v. CPUs
In diesem Fall ist die Anzahl der Verbindungen kein Problem. Möglicherweise versuchen Sie jedoch weiterhin, die CPU-Auslastung zu reduzieren.
+ Die Anzahl der Backend-Prozesse, die CPU verbrauchen, ist größer als die Anzahl von v. CPUs
Ziehen Sie in diesem Fall die folgenden Optionen in Betracht:
+ Verringern Sie die Anzahl der Backend-Prozesse, die mit Ihrer Datenbank verbunden sind. Implementieren Sie beispielsweise eine Verbindungs-Pooling-Lösung wie RDS Proxy. Weitere Informationen hierzu finden Sie unter [Amazon RDS-Proxy ](rds-proxy.md).
+ Erhöhen Sie Ihre Instanzgröße, um eine höhere Anzahl von v CPUs zu erhalten.
+ Leiten Sie ggf. einige schreibgeschützte Workloads auf Reader-Knoten um.
#### Die Verbindungen haben nicht zugenommen
Untersuchen Sie die `blks_hit`-Metriken in Performance Insights. Suchen Sie nach einer Korrelation zwischen einem Anstieg von `blks_hit` und der CPU-Auslastung. Die folgenden Szenarien sind möglich:
+ CPU-Auslastung und `blks_hit` sind korreliert.
Suchen Sie in diesem Fall die wichtigsten SQL-Anweisungen, die mit der CPU-Auslastung verknüpft sind, und suchen Sie nach Planänderungen. Sie können eine der folgenden Techniken verwenden:
+ Erklären Sie die Pläne manuell und vergleichen Sie sie mit dem erwarteten Ausführungsplan.
+ Achten Sie auf eine Zunahme der Blocktreffer pro Sekunde und lokalen Blocktreffern pro Sekunde. Wählen Sie im Abschnitt **Top-SQL** des Performance Insights-Dashboards **Einstellungen** aus.
+ CPU-Auslastung und `blks_hit` sind nicht korreliert.
Stellen Sie in diesem Fall fest, ob einer der folgenden Fälle auftritt:
+ Die Anwendung stellt schnell eine Verbindung zur Datenbank her und trennt sie von dieser.
Diagnostizieren Sie dieses Verhalten, indem Sie `log_connections` und `log_disconnections` aktivieren und dann die PostgreSQL-Protokolle analysieren. Ziehen Sie in Erwägung, den `pgbadger`-Protokoll-Analyzer zu verwenden. Weitere Informationen finden Sie unter [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger).
+ Das Betriebssystem ist überlastet.
In diesem Fall zeigt Performance Insights, dass Backend-Prozesse länger CPU verbrauchen als gewöhnlich. Suchen Sie in den Performance Insights `os.cpuUtilization` Insights-Metriken oder der CloudWatch `CPUUtilization` Metrik nach Belegen. Wenn das Betriebssystem überlastet ist, sehen Sie sich Enhanced Monitoring-Metriken an, um eine weitere Diagnose zu erhalten. Schauen Sie sich insbesondere die Prozessliste und den Prozentsatz der CPU an, die von jedem Prozess verbraucht wird.
+ Top SQL-Anweisungen verbrauchen zu viel CPU.
Untersuchen Sie Anweisungen, die mit der CPU-Auslastung verknüpft sind, um festzustellen, ob sie weniger CPU verbrauchen können. Führen Sie einen `EXPLAIN`-Befehl aus und konzentrieren Sie sich auf die Planknoten, die die größte Auswirkung haben. Erwägen Sie, einen Visualizer für PostgreSQL-Ausführungspläne zu verwenden. Um dieses Tool auszuprobieren, siehe [http://explain.dalibo.com/](http://explain.dalibo.com/).
### Reagieren auf Workload-Änderungen
Wenn sich Ihre Workload geändert hat, suchen Sie nach folgenden Arten von Änderungen:
Neue Anfragen
Überprüfen Sie, ob die neuen Abfragen erwartet werden. Stellen Sie in diesem Fall sicher, dass ihre Ausführungspläne und die Anzahl der Ausführungen pro Sekunde erwartet werden.
Eine Zunahme der Größe des Datensatzes
Bestimmen Sie, ob die Partitionierung, falls sie noch nicht implementiert ist, helfen könnte. Diese Strategie könnte die Anzahl der Seiten verringern, die eine Abfrage abrufen muss.
Indexpflege oder -erstellung
Überprüfen Sie, ob der Zeitplan für die Wartung erwartet wird. Eine bewährte Methode besteht darin, Wartungsarbeiten außerhalb der Hauptverkehrszeiten zu planen.
Neue Funktionen
Überprüfen Sie, ob diese Funktionen während des Tests erwartungsgemäß funktionieren. Überprüfen Sie insbesondere, ob die Anzahl der Ausführungen pro Sekunde erwartet wird.
Neue Betreiber
Überprüfen Sie, ob sie während des Tests erwartungsgemäß funktionieren.
Eine Zunahme der laufenden parallelen Abfragen
Stellen Sie fest, ob eine der folgenden Situationen aufgetreten ist:
+ Die beteiligten Relationen oder Indizes sind plötzlich so groß geworden, dass sie sich deutlich von `min_parallel_table_scan_size` oder `min_parallel_index_scan_size` unterscheiden.
+ Die letzten Änderungen wurden an `parallel_setup_cost` oder `parallel_tuple_cost` vorgenommen.
+ Die letzten Änderungen wurden an `max_parallel_workers` oder `max_parallel_workers_per_gather` vorgenommen.
# IO: BufFileRead und IO: BufFileWrite
Die Ereignisse `IO:BufFileRead` und `IO:BufFileWrite` treten auf, wenn RDS für PostgreSQL temporäre Dateien erstellt. Wenn Vorgänge mehr Arbeitsspeicher benötigen, als die derzeit definierten Arbeitsspeicherparameter definieren, schreiben sie temporäre Daten in persistenten Speicher. Dieser Vorgang wird manchmal als Übertragung *auf die Festplatte* bezeichnet. Weitere Informationen zu den temporären Dateien und ihrer Verwendung finden Sie unter [Verwalten temporärer Dateien mit PostgreSQL](PostgreSQL.ManagingTempFiles.md).
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.iobuffile.context.supported)
+ [Kontext](#wait-event.iobuffile.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.iobuffile.causes)
+ [Aktionen](#wait-event.iobuffile.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
`IO:BufFileRead` und `IO:BufFileWrite` beziehen sich auf den Arbeitsspeicherbereich und den Wartungsarbeitsspeicherbereich. Weitere Informationen zu diesen lokalen Speicherbereichen finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
Der Standardwert für `work_mem` ist 4 MB. Wenn eine Sitzung parallel Vorgänge ausführt, verwendet jeder Worker, der die Parallelität bearbeitet, 4 MB Speicher. Stellen Sie `work_mem` daher sorgfältig ein. Wenn Sie den Wert zu stark erhöhen, verbraucht eine Datenbank mit vielen Sitzungen möglicherweise zu viel Speicher. Wenn Sie den Wert zu niedrig festlegen, erstellt RDS für PostgreSQL temporäre Dateien im lokalen Speicher. Die Festplatte I/O für diese temporären Dateien kann die Leistung beeinträchtigen.
Wenn Sie die folgende Ereignisfolge beobachten, generiert Ihre Datenbank möglicherweise temporäre Dateien:
1. Plötzlicher und starker Rückgang der Verfügbarkeit
1. Schnelle Erholung für den freien Speicherplatz
Möglicherweise sehen Sie auch ein „Kettensäge“ -Muster. Dieses Muster kann darauf hinweisen, dass Ihre Datenbank ständig kleine Dateien erstellt.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Im Allgemeinen werden diese Warteereignisse durch Vorgänge verursacht, die mehr Speicher verbrauchen, als die Parameter `work_mem` oder `maintenance_work_mem` zuweisen. Um dies zu kompensieren, schreiben die Vorgänge in temporäre Dateien. Häufige Ursachen für die `IO:BufFileRead`- und `IO:BufFileWrite`-Ereignisse sind die folgenden:
**Abfragen, die mehr Speicher benötigen als im Arbeitsspeicherbereich vorhanden**
Abfragen mit den folgenden Merkmalen verwenden den Arbeitsspeicherbereich:
+ Hash-Verknüpfungen
+ `ORDER BY`-Klausel
+ `GROUP BY`-Klausel
+ `DISTINCT`
+ Fensterfunktionen
+ `CREATE TABLE AS SELECT`
+ Aktualisierung der materialisierten Ansicht
**Anweisungen, die mehr Speicher benötigen als im Arbeitsspeicherbereich für Wartungsarbeiten vorhanden**
Die folgenden Anweisungen verwenden den Arbeitsspeicherbereich für Wartungsarbeiten:
+ `CREATE INDEX`
+ `CLUSTER`
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Identifizieren Sie das Problem](#wait-event.iobuffile.actions.problem)
+ [Untersuchen Sie Ihre Join-Anfragen](#wait-event.iobuffile.actions.joins)
+ [Überprüfen Sie Ihre ORDER BY- und GROUP BY Anfragen](#wait-event.iobuffile.actions.order-by)
+ [Verwenden Sie den DISTINCT-Vorgang nicht](#wait-event.iobuffile.actions.distinct)
+ [Erwägen Sie, Fensterfunktionen anstelle von GROUP-BY-Funktionen zu verwenden](#wait-event.iobuffile.actions.window)
+ [Untersuchen Sie materialisierte Ansichten und CTAS-Aussagen](#wait-event.iobuffile.actions.mv-refresh)
+ [Verwenden von pg\$1repack beim Neuerstellen von Indizes](#wait-event.iobuffile.actions.pg_repack)
+ [Erhöhen Sie maintenance work\$1mem, wenn Sie Tabellen clustern](#wait-event.iobuffile.actions.cluster)
+ [Passen Sie den Speicher an, um IO: BufFileRead und IO: zu verhindern BufFileWrite](#wait-event.iobuffile.actions.tuning-memory)
### Identifizieren Sie das Problem
Sie können die Nutzung temporärer Dateien direkt in Performance Insights anzeigen. Weitere Informationen finden Sie unter [Anzeigen der Nutzung temporärer Dateien mit Performance Insights](PostgreSQL.ManagingTempFiles.Example.md). Wenn Performance Insights deaktiviert ist, stellen Sie möglicherweise eine Zunahme der `IO:BufFileRead` `IO:BufFileWrite` Betriebsabläufe fest.
Um die Ursache des Problems zu ermitteln, können Sie den `log_temp_files`-Parameter so festlegen, dass alle Abfragen protokolliert werden, die mehr als den angegebenen Schwellenwert an temporären Dateien in KB generieren. `log_temp_files` ist standardmäßig auf `-1` festgelegt, wodurch diese Protokollierungsfunktion deaktiviert wird. Wenn Sie diesen Parameter auf `0` einstellen, protokolliert RDS für PostgreSQL alle temporären Dateien. Wenn der Wert `1024` ist, protokolliert RDS für PostgreSQL alle Abfragen, die temporäre Dateien erzeugen, die größer als 1 MB sind. Weitere Informationen zu `log_temp_files` finden Sie unter [Fehlerberichte und -protokollierung](https://www.postgresql.org/docs/current/runtime-config-logging.html) in der PostgreSQL-Dokumentation.
### Untersuchen Sie Ihre Join-Anfragen
Es ist wahrscheinlich, dass Ihre Abfrage Joins verwendet. Die folgende Abfrage verbindet beispielsweise vier Tabellen.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Eine mögliche Ursache für Spitzen bei der Verwendung temporärer Dateien ist ein Problem in der Abfrage selbst. Beispielsweise filtert eine defekte Klausel die Joins möglicherweise nicht richtig. Betrachten Sie den zweiten inneren Join im folgenden Beispiel.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Die obige Abfrage verknüpft fälschlicherweise `customer.id` mit `customer.id`, wodurch zwischen jedem Kunden und jeder Bestellung ein kartesisches Produkt generiert wird. Diese Art des versehentlichen Joins generiert große temporäre Dateien. Abhängig von der Größe der Tabellen kann eine kartesische Abfrage sogar Speicher füllen. Wenn die folgenden Bedingungen erfüllt sind, hat Ihre Anwendung möglicherweise kartesische Joins:
+ Sie sehen einen großen, starken Rückgang der Speicherverfügbarkeit, gefolgt von einer schnellen Wiederherstellung.
+ Es werden keine Indizes erstellt.
+ Es werden keine `CREATE TABLE FROM SELECT`-Anweisungen ausgegeben.
+ Es werden keine materialisierten Ansichten aktualisiert.
Um festzustellen, ob die Tabellen mit den richtigen Schlüsseln verbunden werden, überprüfen Sie Ihre Abfrage- und objektrelationalen Mapping-Anweisungen. Denken Sie daran, dass bestimmte Abfragen Ihrer Anwendung nicht ständig aufgerufen werden und einige Abfragen dynamisch generiert werden.
### Überprüfen Sie Ihre ORDER BY- und GROUP BY Anfragen
In einigen Fällen kann eine `ORDER BY`-Klausel zu übermäßig vielen temporären Dateien führen. Berücksichtigen Sie die folgenden Hinweise:
+ Schließen Sie Spalten nur dann in eine `ORDER BY`-Klausel ein, wenn sie sortiert werden müssen. Diese Richtlinie ist besonders wichtig für Abfragen, die Tausende von Zeilen zurückgeben und viele Spalten in der `ORDER BY`-Klausel angeben.
+ Ziehen Sie in Betracht, Indizes zu erstellen, um `ORDER BY`-Klauseln zu beschleunigen, wenn sie mit Spalten übereinstimmen, die dieselbe aufsteigende oder absteigende Reihenfolge aufweisen. Partielle Indizes sind vorzuziehen, da sie kleiner sind. Kleinere Indizes werden schneller gelesen und durchquert.
+ Wenn Sie Indizes für Spalten erstellen, die Nullwerte akzeptieren können, überlegen Sie, ob die Nullwerte am Ende oder am Anfang der Indizes gespeichert werden sollen.
Reduzieren Sie nach Möglichkeit die Anzahl der Zeilen, die sortiert werden müssen, indem Sie die Ergebnismenge filtern. Wenn Sie `WITH`-Klausel-Anweisungen oder Unterabfragen verwenden, denken Sie daran, dass eine innere Abfrage eine Ergebnismenge generiert und an die äußere Abfrage übergibt. Je mehr Zeilen eine Abfrage herausfiltern kann, desto weniger muss die Abfrage erledigen.
+ Wenn Sie nicht die vollständige Ergebnismenge abrufen müssen, verwenden Sie die `LIMIT`-Klausel. Wenn Sie beispielsweise nur die obersten fünf Zeilen benötigen, generiert eine Abfrage mit der `LIMIT`-Klausel keine Ergebnisse. Auf diese Weise benötigt die Abfrage weniger Speicher und temporäre Dateien.
Eine Abfrage, die eine `GROUP BY`-Klausel verwendet, kann auch temporäre Dateien erfordern. `GROUP BY`-Abfragen fassen Werte mithilfe von Funktionen wie den folgenden zusammen:
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
Befolgen Sie zum Optimieren von `GROUP BY`-Abfragen die Empfehlungen für `ORDER BY`-Abfragen.
### Verwenden Sie den DISTINCT-Vorgang nicht
Vermeiden Sie nach Möglichkeit die Verwendung des `DISTINCT`-Vorgangs, um doppelte Zeilen zu entfernen. Je mehr unnötige und doppelte Zeilen Ihre Abfrage zurückgibt, desto teurer wird der `DISTINCT`-Vorgang. Fügen Sie nach Möglichkeit Filter in der `WHERE`-Klausel hinzu, auch wenn Sie dieselben Filter für verschiedene Tabellen verwenden. Das Filtern der Abfrage und der korrekte Beitritt verbessern Ihre Leistung und reduziert den Ressourcennutzung. Es verhindert auch falsche Berichte und Ergebnisse.
Wenn Sie `DISTINCT` für mehrere Zeilen derselben Tabelle verwenden müssen, sollten Sie einen zusammengesetzten Index erstellen. Das Gruppieren mehrerer Spalten in einem Index kann die Zeit zum Auswerten verschiedener Zeilen verbessern. Wenn Sie Version 10 von RDS für PostgreSQL oder höher verwenden, können Sie außerdem mithilfe des `CREATE STATISTICS`-Befehls Statistiken zwischen mehreren Spalten korrelieren.
### Erwägen Sie, Fensterfunktionen anstelle von GROUP-BY-Funktionen zu verwenden
Mit `GROUP BY` ändern Sie die Ergebnismenge und rufen dann das aggregierte Ergebnis ab. Mithilfe von Fensterfunktionen aggregieren Sie Daten, ohne die Ergebnismenge zu ändern. Eine Fensterfunktion verwendet die `OVER`-Klausel, um Berechnungen über die von der Abfrage definierten Mengen durchzuführen und eine Zeile mit einer anderen zu korrelieren. Sie können alle `GROUP BY`-Funktionen in Fensterfunktionen verwenden, aber auch Funktionen wie die folgenden verwenden:
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
Um die Anzahl der temporären Dateien zu minimieren, die von einer Fensterfunktion generiert werden, entfernen Sie Duplikationen für dieselbe Ergebnismenge, wenn Sie zwei verschiedene Aggregationen benötigen. Betrachten Sie folgende Abfrage.
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
Sie können die Abfrage mit der `WINDOW`-Klausel wie folgt umschreiben.
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
Standardmäßig konsolidiert der Ausführungsplaner von RDS für PostgreSQL ähnliche Knoten, sodass keine Vorgänge dupliziert werden. Durch die Verwendung einer expliziten Deklaration für den Fensterblock können Sie die Abfrage jedoch einfacher pflegen. Sie können die Leistung auch verbessern, indem Sie Doppelarbeit verhindern.
### Untersuchen Sie materialisierte Ansichten und CTAS-Aussagen
Wenn eine materialisierte Ansicht aktualisiert wird, wird eine Abfrage ausgeführt. Diese Abfrage kann einen Vorgang wie `GROUP BY`, `ORDER BY` oder `DISTINCT` enthalten. Während einer Aktualisierung können Sie eine große Anzahl temporärer Dateien und die Warteereignisse `IO:BufFileWrite` und `IO:BufFileRead` beobachten. Wenn Sie eine Tabelle basierend auf einer `SELECT`-Anweisung erstellen, führt die `CREATE TABLE`-Anweisung eine Abfrage aus. Um die benötigten temporären Dateien zu reduzieren, optimieren Sie die Abfrage.
### Verwenden von pg\$1repack beim Neuerstellen von Indizes
Wenn Sie einen Index erstellen, ordnet die Engine die Ergebnismenge an. Wenn Tabellen größer werden und die Werte in der indizierten Spalte vielfältiger werden, benötigen die temporären Dateien mehr Speicherplatz. In den meisten Fällen können Sie die Erstellung temporärer Dateien für große Tabellen nicht verhindern, ohne den Speicherbereich für Wartungsarbeiten zu ändern. Weitere Informationen zu `maintenance_work_mem` finden Sie unter [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
Eine mögliche Problemumgehung beim Neuerstellen eines großen Index besteht darin, die pg\$1repack-Erweiterung zu verwenden. Weitere Informationen finden Sie unter [Reorganisieren von Tabellen in PostgreSQL-Datenbanken mit minimalen Sperren](https://reorg.github.io/pg_repack/) in der pg\$1repack-Dokumentation. Informationen zum Einrichten der Erweiterung in Ihrer DB-Instance von RDS for PostgreSQL finden Sie unter [Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md).
### Erhöhen Sie maintenance work\$1mem, wenn Sie Tabellen clustern
Der Befehl `CLUSTER` gruppiert die durch *table\$1name* angegebene Tabelle basierend auf einem vorhandenen Index, der durch *index\$1name* angegeben wird. RDS für PostgreSQL erstellt die Tabelle physisch so neu, dass sie der Reihenfolge eines bestimmten Indexes entspricht.
Als magnetische Speicherung vorherrschend war, war Clustering üblich, da der Speicherdurchsatz begrenzt war. Jetzt, da SSD-basierter Speicher üblich ist, ist Clustering weniger beliebt. Wenn Sie jedoch Tabellen clustern, können Sie die Leistung je nach Tabellengröße, Index, Abfrage usw. immer noch geringfügig steigern.
Wenn Sie den Befehl `CLUSTER` ausführen und die Warteereignisse `IO:BufFileWrite` und `IO:BufFileRead` beobachten, stimmen Sie `maintenance_work_mem` ab. Erhöhen Sie die Speichergröße auf einen ziemlich großen Betrag. Ein hoher Wert bedeutet, dass die Engine mehr Speicher für den Clustering-Vorgang verwenden kann.
### Passen Sie den Speicher an, um IO: BufFileRead und IO: zu verhindern BufFileWrite
In einigen Situationen müssen Sie den Speicher optimieren. Ihr Ziel ist es, mithilfe der entsprechenden Parameter den Arbeitsspeicher in den folgenden Verbrauchsbereichen wie folgt auszugleichen.
+ Der `work_mem`-Wert
+ Der Speicher, der nach Abzug des Werts `shared_buffers` verbleibt
+ Die maximale Anzahl geöffneter und verwendeter Verbindungen, die durch `max_connections` begrenzt ist
Weitere Informationen zum Optimieren des Arbeitsspeichers finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
#### Erhöhen Sie die Größe des Arbeitsspeicherbereichs
In einigen Situationen besteht Ihre einzige Möglichkeit darin, den von Ihrer Sitzung verwendeten Speicher zu erhöhen. Wenn Ihre Abfragen richtig geschrieben sind und die richtigen Schlüssel für Joins verwenden, sollten Sie den `work_mem`-Wert erhöhen.
Um herauszufinden, wie viele temporäre Dateien eine Abfrage generiert, setzen Sie `log_temp_files` auf `0`. Wenn Sie den `work_mem`-Wert auf den in den Protokollen angegebenen Höchstwert erhöhen, verhindern Sie, dass die Abfrage temporäre Dateien generiert. `work_mem` legt jedoch das Maximum pro Planknoten für jede Verbindung oder jeden parallelen Worker fest. Wenn die Datenbank über 5.000 Verbindungen verfügt und jede 256 MiB-Speicher verwendet, benötigt die Engine 1,2 TiB RAM. Daher kann es sein, dass Ihrer Instance der Speicher knapp wird.
#### Reservieren Sie ausreichend Speicher für den freigegebenen Pufferpool
Ihre Datenbank verwendet Speicherbereiche wie den freigegebenen Pufferpool, nicht nur den Arbeitsspeicherbereich. Berücksichtigen Sie die Anforderungen dieser zusätzlichen Speicherbereiche, bevor Sie `work_mem` erhöhen.
Angenommen, Ihre Instance-Klasse von RDS für PostgreSQL ist db.r5.2xlarge. Diese Klasse hat 64 GiB Speicher. Standardmäßig sind 25 Prozent des Arbeitsspeichers für den freigegebenen Pufferpool reserviert. Nachdem Sie den dem Shared Memory-Bereich zugewiesenen Betrag abgezogen haben, bleiben 16.384 MB übrig. Weisen Sie den verbleibenden Speicher nicht ausschließlich dem Arbeitsspeicherbereich zu, da das Betriebssystem und die Engine ebenfalls Speicher benötigen.
Der Speicher, den Sie `work_mem` zuordnen können, hängt von der Instance-Klasse ab. Wenn Sie eine größere Instance-Klasse verwenden, ist mehr Speicher verfügbar. Im vorhergehenden Beispiel können Sie jedoch nicht mehr als 16 GiB verwenden. Andernfalls ist Ihre Instance nicht verfügbar, wenn ihr der Speicher ausgeht. Um die Instance aus dem nicht verfügbaren Status wiederherzustellen, werden die Automatisierungsdienste von RDS für PostgreSQL automatisch neu gestartet.
#### Verwalten der Anzahl der Verbindungen
Angenommen, Ihre Datenbank-Instance hat 5.000 gleichzeitige Verbindungen. Jede Verbindung verwendet mindestens 4 MB `work_mem`. Der hohe Speicherverbrauch der Verbindungen dürfte die Leistung beeinträchtigen. Als Reaktion darauf haben Sie die folgenden Optionen:
+ Aktualisieren Sie auf eine größere Instance-Klasse.
+ Verringern Sie die Anzahl gleichzeitiger Datenbankverbindungen mit einem Verbindungsproxy oder Pooler.
Berücksichtigen Sie bei Proxys Amazon RDS Proxy, PGBouncer oder einen auf Ihrer Anwendung basierenden Verbindungspooler. Diese Lösung lindert die CPU-Last. Es reduziert auch das Risiko, wenn alle Verbindungen den Arbeitsspeicherbereich benötigen. Wenn weniger Datenbankverbindungen vorhanden sind, können Sie den Wert von `work_mem` erhöhen. Auf diese Weise reduzieren Sie das Auftreten der `IO:BufFileRead`- und `IO:BufFileWrite`-Warteereignisse. Auch die Abfragen, die auf den Arbeitsspeicherbereich warten, beschleunigen sich erheblich.
# IO: DataFileRead
Das `IO:DataFileRead`-Ereignis tritt auf, wenn eine Verbindung darauf wartet, dass ein Backend-Prozess eine erforderliche Seite aus dem Speicher liest, da die Seite nicht im gemeinsam genutzten Speicher verfügbar ist.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.iodatafileread.context.supported)
+ [Kontext](#wait-event.iodatafileread.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.iodatafileread.causes)
+ [Aktionen](#wait-event.iodatafileread.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Alle Abfragen und Datenmanipulationsvorgänge (DML) greifen auf Seiten im Pufferpool zu. Zu den Anweisungen, die Lesevorgänge auslösen können, gehören `SELECT`, `UPDATE` und `DELETE`. Ein `UPDATE` kann beispielsweise Seiten aus Tabellen oder Indizes lesen. Wenn sich die angeforderte oder aktualisierte Seite nicht im gemeinsam genutzten Pufferpool befindet, kann dieser Lesevorgang zum `IO:DataFileRead`-Ereignis führen.
Da der gemeinsame Pufferpool endlich ist, kann er sich füllen. In diesem Fall zwingen Anfragen nach Seiten, die sich nicht im Speicher befinden, die Datenbank dazu, Blöcke von der Festplatte zu lesen. Wenn das `IO:DataFileRead`-Ereignis häufig auftritt, ist Ihr gemeinsam genutzter Pufferpool möglicherweise zu klein für Ihre Workload. Dieses Problem ist bei `SELECT`-Abfragen akut, die eine große Anzahl von Zeilen lesen, die nicht in den Pufferpool passen. Weitere Informationen zum Pufferpool finden Sie unter [Ressourcenbnutzung](https://www.postgresql.org/docs/current/runtime-config-resource.html) in der PostgreSQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Häufige Ursachen für das Ereignis `IO:DataFileRead` sind die folgenden:
**Verbindungsspitzen**
Möglicherweise stellen Sie fest, dass mehrere Verbindungen dieselbe Anzahl von IO: DataFileRead Wait-Ereignissen generieren. In diesem Fall kann eine Spitze (plötzlicher und starker Anstieg) bei `IO:DataFileRead`-Ereignissen auftreten.
**SELECT- und DML-Anweisungen, die sequentielle Scans durchführen**
Ihre Anwendung führt möglicherweise einen neuen Vorgang aus. Oder ein vorhandener Vorgang könnte sich aufgrund eines neuen Ausführungsplans ändern. Suchen Sie in solchen Fällen nach Tabellen (insbesondere großen Tabellen), die einen größeren `seq_scan`-Wert haben. Finden Sie sie, indem Sie `pg_stat_user_tables` abfragen. Verwenden Sie die Erweiterung `pg_stat_statements`, um Abfragen zu verfolgen, die mehr Lesevorgänge generieren.
**CTAS und CREATE INDEX für große Datensätze**
Ein *CTAS* ist eine `CREATE TABLE AS SELECT`-Anweisung. Wenn Sie ein CTAS mit einem großen Datensatz als Quelle ausführen oder einen Index für eine große Tabelle erstellen, kann das `IO:DataFileRead`-Ereignis auftreten. Wenn Sie einen Index erstellen, muss die Datenbank möglicherweise das gesamte Objekt mithilfe eines sequentiellen Scans lesen. Ein CTAS generiert `IO:DataFile`-Reads, wenn Seiten nicht im Speicher sind.
**Mehrere Vakuumarbeiter laufen gleichzeitig**
Vakuumarbeiter können manuell oder automatisch ausgelöst werden. Wir empfehlen, eine aggressive Vakuumstrategie zu verabschieden. Wenn eine Tabelle jedoch viele aktualisierte oder gelöschte Zeilen enthält, erhöhen sich die `IO:DataFileRead`-Wartezeiten. Nachdem der Raum zurückgewonnen wurde, nimmt die für `IO:DataFileRead` aufgewendete Vakuumzeit ab.
**Aufnahme großer Datenmengen**
Wenn Ihre Anwendung große Datenmengen aufnimmt, können `ANALYZE`-Vorgänge häufiger auftreten. Der `ANALYZE`-Prozess kann durch einen Autovacuum Launcher ausgelöst oder manuell aufgerufen werden.
Der `ANALYZE`-Vorgang liest eine Teilmenge der Tabelle. Die Anzahl der zu scannenden Seiten wird berechnet, indem 30 mit dem `default_statistics_target`-Wert multipliziert wird. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET). Der Parameter `default_statistics_target` akzeptiert Werte zwischen 1 und 10.000, wobei der Standardwert 100 ist.
**Hungertod**
Wenn Netzwerkbandbreite oder CPU der Instance verbraucht werden, kann das `IO:DataFileRead`-Ereignis häufiger auftreten.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Überprüfen Sie Prädikatfilter auf Abfragen, die Wartezeiten generieren](#wait-event.iodatafileread.actions.filters)
+ [Minimieren Sie die Auswirkungen von Wartungsvorgängen](#wait-event.iodatafileread.actions.maintenance)
+ [Reagieren Sie auf eine hohe Anzahl von Verbindungen](#wait-event.iodatafileread.actions.connections)
### Überprüfen Sie Prädikatfilter auf Abfragen, die Wartezeiten generieren
Angenommen, Sie identifizieren bestimmte Abfragen, die `IO:DataFileRead`-Warteereignisse generieren. Sie können sie mit den folgenden Techniken identifizieren:
+ Performance Insights
+ Katalogansichten wie die der Erweiterung `pg_stat_statements`
+ Die Katalogansicht `pg_stat_all_tables`, wenn sie periodisch eine erhöhte Anzahl von physischen Lesevorgängen anzeigt
+ Die `pg_statio_all_tables`-Ansicht, wenn sie zeigt, dass `_read`-Zähler steigen
Wir empfehlen Ihnen, zu bestimmen, welche Filter im Prädikat (`WHERE`-Klausel) dieser Abfragen verwendet werden. Befolgen Sie diese Richtlinien:
+ Führen Sie den Befehl `EXPLAIN` aus. Geben Sie in der Ausgabe an, welche Arten von Scans verwendet werden. Ein sequentieller Scan weist nicht zwangsläufig ein Problem an. Abfragen, die sequenzielle Scans verwenden, erzeugen im Vergleich zu Abfragen, die Filter verwenden, natürlich mehr `IO:DataFileRead`-Ereignisse.
Finden Sie heraus, ob die in der `WHERE`-Klausel aufgeführte Spalte indiziert ist. Wenn nicht, erwägen Sie, einen Index für diese Spalte zu erstellen. Dieser Ansatz vermeidet die sequentiellen Scans und reduziert die `IO:DataFileRead`-Ereignisse. Wenn eine Abfrage restriktive Filter enthält und immer noch sequenzielle Scans erzeugt, bewerten Sie, ob die richtigen Indizes verwendet werden.
+ Finden Sie heraus, ob die Abfrage auf eine sehr große Tabelle zugreift. In einigen Fällen kann das Partitionieren einer Tabelle die Leistung verbessern, sodass die Abfrage nur notwendige Partitionen lesen kann.
+ Untersuchen Sie die Kardinalität (Gesamtzahl der Zeilen) Ihrer Join-Vorgänge. Beachten Sie, wie restriktiv die Werte sind, die Sie den Filtern für Ihre `WHERE`-Klausel übergeben. Wenn möglich, stimmen Sie Ihre Abfrage ein, um die Anzahl der Zeilen zu reduzieren, die in jedem Schritt des Plans übergeben werden.
### Minimieren Sie die Auswirkungen von Wartungsvorgängen
Wartungsvorgänge wie `VACUUM` und `ANALYZE` sind wichtig. Wir empfehlen, sie nicht zu deaktivieren, da Sie `IO:DataFileRead`-Warteereignisse im Zusammenhang mit diesen Wartungsvorgängen finden. Die folgenden Ansätze können die Auswirkungen dieser Vorgänge minimieren:
+ Führen Sie Wartungsvorgänge während außerhalb der Hauptverkehrszeiten manuell aus. Diese Technik verhindert, dass die Datenbank den Schwellenwert für automatische Vorgänge erreicht.
+ Erwägen Sie bei sehr großen Tabellen, die Tabelle zu partitionieren. Diese Technik reduziert den Overhead von Wartungsvorgängen. Die Datenbank greift nur auf die Partitionen zu, die gewartet werden müssen.
+ Wenn Sie große Datenmengen aufnehmen, sollten Sie die Funktion zur automatischen Analyse deaktivieren.
Die Auto-Vakuum-Funktion wird automatisch für eine Tabelle ausgelöst, wenn die folgende Formel zutrifft.
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
Die Ansicht `pg_stat_user_tables` und der Katalog `pg_class` haben mehrere Zeilen. Eine Zeile kann einer Zeile in Ihrer Tabelle entsprechen. Diese Formel geht davon aus, dass die `reltuples` für eine bestimmte Tabelle stehen. Die Parameter `autovacuum_vacuum_scale_factor` (standardmäßig 0.20) und `autovacuum_vacuum_threshold` (standardmäßig 50 Tupel) werden normalerweise global für die gesamte Instance gesetzt. Sie können jedoch verschiedene Werte für eine bestimmte Tabelle festlegen.
**Topics**
+ [Suchen nach Tabellen, die unnötigerweise Speicherplatz belegen](#wait-event.iodatafileread.actions.maintenance.tables)
+ [Suchen nach Indizes, die unnötigerweise Speicherplatz belegen](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [Finden Sie Tabellen, die für die automatische Vakuumierung berechtigt sind](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### Suchen nach Tabellen, die unnötigerweise Speicherplatz belegen
Um Tabellen zu finden, die unnötig Speicherplatz beanspruchen, können Sie Funktionen der `pgstattuple`-Erweiterung von PostgreSQL verwenden. Diese Erweiterung (Modul) ist standardmäßig auf allen DB-Instances von RDS für PostgreSQL verfügbar und kann mit dem folgenden Befehl auf der Instance instanziiert werden.
```
CREATE EXTENSION pgstattuple;
```
Weitere Informationen zu dieser Erweiterung finden Sie unter [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) in der PostgreSQL-Dokumentation.
Sie können in Ihrer Anwendung nach einer Überlastung von Tabellen und Indizes suchen. Weitere Informationen finden Sie unter [Diagnostizieren einer Überlastung von Tabellen und Indizes](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html).
#### Suchen nach Indizes, die unnötigerweise Speicherplatz belegen
Um aufgeblähte Indizes zu finden und abzuschätzen, wie viel Speicherplatz in den Tabellen, für die Sie Leserechte haben, unnötig beansprucht wird, können Sie die folgende Abfrage ausführen.
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### Finden Sie Tabellen, die für die automatische Vakuumierung berechtigt sind
Führen Sie die folgende Abfrage aus, um Tabellen zu finden, die für die automatische Vakuumierung berechtigt sind.
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### Reagieren Sie auf eine hohe Anzahl von Verbindungen
Wenn Sie Amazon überwachen CloudWatch, stellen Sie möglicherweise fest, dass die `DatabaseConnections` Metrik ansteigt. Dieser Anstieg deutet auf eine erhöhte Anzahl von Verbindungen zu Ihrer Datenbank hin. Wir empfehlen folgende Vorgehensweise:
+ Beschränken Sie die Anzahl der Verbindungen, die die Anwendung mit jeder Instance öffnen kann. Wenn Ihre Anwendung über eine eingebettete Verbindungspool-Funktion verfügt, legen Sie eine angemessene Anzahl von Verbindungen fest. Basieren Sie die Zahl darauf, was das v CPUs in Ihrer Instance effektiv parallelisieren kann.
Wenn Ihre Anwendung keine Verbindungspool-Funktion verwendet, sollten Sie den Amazon RDS Proxy oder eine Alternative in Betracht ziehen. Mit diesem Ansatz können Ihre Anwendung mehrere Verbindungen mit dem Load Balancer öffnen. Der Balancer kann dann eine begrenzte Anzahl von Verbindungen mit der Datenbank öffnen. Da weniger Verbindungen parallel laufen, führt Ihre DB-Instance weniger Kontextwechsel im Kernel durch. Abfragen sollten schneller voranschreiten und zu weniger Warteereignissen führen. Weitere Informationen finden Sie unter [Amazon RDS-Proxy ](rds-proxy.md).
+ Nutzen Sie nach Möglichkeit die Lesereplikate für RDS für PostgreSQL. Wenn Ihre Anwendung eine schreibgeschützten Operation ausführt, senden Sie diese Anfragen an das bzw. die Lesereplikate. Diese Technik reduziert den I/O Druck auf den primären Knoten (Writer).
+ Ziehen Sie, Ihre DB-Instance zu skalieren. Eine Instance-Klasse mit höherer Kapazität bietet mehr Speicher, was RDS für PostgreSQL einen größeren freigegebenen Pufferpool zum Speichern von Seiten gibt. Die größere Größe gibt der DB-Instance auch mehr V CPUs für die Verarbeitung von Verbindungen. Mehr v CPUs sind besonders hilfreich, wenn es sich bei den Vorgängen, die `IO:DataFileRead` Warte-Ereignisse erzeugen, um Schreibvorgänge handelt.
# IO:WALWrite
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.iowalwrite.context.supported)
+ [Kontext](#wait-event.iowalwrite.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.iowalwrite.causes)
+ [Aktionen](#wait-event.iowalwrite.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL 10 und höher unterstützt.
## Kontext
Die Aktivität in der Datenbank, die Write-Ahead-Protokolldaten generiert, füllt zuerst die WAL-Puffer und schreibt dann asynchron auf die Festplatte. Das Warteereignis `IO:WALWrite` wird generiert, wenn die SQL-Sitzung darauf wartet, dass die WAL-Daten das Schreiben auf die Festplatte abgeschlossen haben, damit sie den COMMIT-Aufruf der Transaktion freigeben kann.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Warteereignis häufig auftritt, sollten Sie Ihre Workload und die Art der Aktualisierungen, die Ihre Workload durchführt, sowie deren Häufigkeit überprüfen. Suchen Sie insbesondere nach folgender Art von Aktivität.
**Starke DML-Aktivität**
Das Ändern von Daten in Datenbanktabellen erfolgt nicht sofort. Beim Einfügen in eine Tabelle muss möglicherweise auf eine Einfügung oder Aktualisierung derselben Tabelle von einem anderen Client gewartet werden. Die Data Manipulation Language (DML)-Anweisungen zum Ändern von Datenwerten (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) können Konflikte verursachen, die dazu führen, dass die Write-Ahead-Protokolldatei darauf wartet, dass die Puffer geleert werden. Diese Situation wird in den folgenden Metriken für Erkenntnisse zur Amazon-RDS-Leistung erfasst, die auf eine starke DML-Aktivität hinweisen.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Weitere Informationen zu diesen Metriken finden Sie unter [Performance-Insights-Zähler für Amazon RDS für PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Häufige Checkpoint-Aktivitäten**
Häufige Checkpoints tragen zu einer höheren Anzahl von WAL-Dateien bei. In RDS für PostgreSQL sind Schreibvorgänge für vollständige Seiten immer aktiviert. Schreibvorgänge für vollständige Seiten schützen vor Datenverlust. Wenn Checkpoints jedoch zu häufig auftreten, kann es zu Leistungseinbußen des Systems kommen. Dies gilt insbesondere für Systeme mit starker DML-Aktivität. In einigen Fällen finden Sie möglicherweise Fehlermeldungen in Ihrem `postgresql.log`, dass „Checkpoints zu häufig vorkommen“.
Wir empfehlen, bei der Optimierung von Checkpoints die Leistung sorgfältig gegen den erwarteten Zeitbedarf für die Wiederherstellung im Falle eines abnormalen Shutdowns abzuwägen.
## Aktionen
Wir empfehlen die folgenden Aktionen, um die Vorkommen dieses Warteereignis zu reduzieren.
**Topics**
+ [Reduzieren Sie die Anzahl der Commits](#wait-event.iowalwrite.actions.problem)
+ [Überwachen Ihrer Checkpoints](#wait-event.iowalwrite.actions.monitor)
+ [Hochskalieren von I/O](#wait-event.iowalwrite.actions.scale-io)
+ [Dediziertes Protokoll-Volume (DLV)](#wait-event.iowalwrite.actions.dlv)
### Reduzieren Sie die Anzahl der Commits
Um die Anzahl der Commits zu reduzieren, können Sie Anweisungen in Transaktionsblöcke kombinieren. Verwenden Sie Erkenntnisse zur Amazon-RDS-Leistung, um die Art der ausgeführten Abfragen zu untersuchen. Sie können große Wartungsvorgänge auch auf Zeiten außerhalb der Spitzenzeiten verlegen. Erstellen Sie beispielsweise Indizes oder verwenden Sie `pg_repack`-Operationen außerhalb der Produktionszeiten.
### Überwachen Ihrer Checkpoints
Es gibt zwei Parameter, die Sie überwachen können, um zu sehen, wie oft Ihre DB-Instance von RDS für PostgreSQL wegen Checkpoints in die WAL-Datei schreibt.
+ `log_checkpoints` – Dieser Parameter ist standardmäßig aktiviert. Dadurch wird für jeden Checkpoint eine Nachricht an das PostgreSQL-Protokoll gesendet. Diese Protokollnachrichten enthalten die Anzahl der geschriebenen Puffer, die für das Schreiben aufgewendete Zeit und die Anzahl der für den angegebenen Checkpoint hinzugefügten, entfernten oder recycelten WAL-Dateien.
Weitere Informationen zu diesem Parameter finden Sie unter [Fehlerberichte und -protokollierung](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS) in der PostgreSQL-Dokumentation.
+ `checkpoint_warning` – Dieser Parameter legt einen Schwellenwert (in Sekunden) für die Checkpoint-Häufigkeit fest, bei dessen Überschreitung eine Warnung generiert wird. Standardmäßig ist dieser Parameter in RDS für PostgreSQL nicht festgelegt. Sie können den Wert dieses Parameters festlegen, um eine Warnung zu erhalten, wenn die Datenbankänderungen in Ihrer RDS-für-PostgreSQL-DB-Instance mit einer Geschwindigkeit geschrieben werden, für die die WAL-Dateien nicht dimensioniert sind. Angenommen, Sie haben diesen Parameter auf 30 festgelegt. Wenn Ihre RDS-für-PostgreSQL-Instance Änderungen öfter als alle 30 Sekunden schreiben muss, wird die Warnung bezüglich zu häufig vorkommender Checkpoints an das PostgreSQL-Protokoll gesendet. Dies kann darauf hindeuten, dass Ihr `max_wal_size`-Wert erhöht werden sollte.
Weitere Informationen finden Sie unter [Write-Ahead-Protokoll](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) in der PostgreSQL-Dokumentation.
### Hochskalieren von I/O
Diese Art von Input/Output-Warteereignis (I/O) kann behoben werden, indem die Eingabe-/Ausgabevorgänge pro Sekunde (IOPs) skaliert werden, um schnellere I/O bereitzustellen. Die Skalierung von I/O ist der Skalierung der CPU vorzuziehen, da die Skalierung der CPU zu noch mehr I/O-Konflikten führen kann. Der Grund hierfür ist, dass die erhöhte CPU mehr Arbeit bewältigen kann und somit den I/O-Engpass noch verschlimmert. Im Allgemeinen empfehlen wir, die Workload zu optimieren, bevor Sie Skalierungsvorgänge durchführen.
### Dediziertes Protokoll-Volume (DLV)
Sie können ein dediziertes Protokoll-Volume (DLV) für eine DB-Instance, die Provisioned IOPS (PIOPS)-Speicher verwendet, mithilfe der Amazon-RDS-Konsole, AWS CLI oder der Amazon-RDS-API verwenden. Ein DLV verschiebt PostgreSQL-Datenbank-Transaktionsprotokolle auf ein Speicher-Volume, das von dem Volume getrennt ist, das die Datenbanktabellen enthält. Weitere Informationen finden Sie unter [Dediziertes Protokoll-Volume (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).
# IPC:parallel-Warteereignisse
Die folgenden `IPC:parallel wait events` weisen darauf hin, dass eine Sitzung auf die Interprozesskommunikation in Bezug auf parallele Abfrageausführungen wartet.
+ `IPC:BgWorkerStartup` - Ein Prozess wartet darauf, dass ein paralleler Worker-Prozess seine Startsequenz abgeschlossen hat. Dies geschieht, wenn Worker für eine parallele Abfrageausführung initialisiert werden.
+ `IPC:BgWorkerShutdown` - Ein Prozess wartet darauf, dass ein paralleler Worker-Prozess seine Shutdown-Sequenz abgeschlossen hat. Dies geschieht während der Bereinigungsphase der parallelen Abfrageausführung.
+ `IPC:ExecuteGather` - Ein Prozess wartet darauf, während der Abfrageausführung Daten von parallelen Worker-Prozessen zu empfangen. Dies ist der Fall, wenn der Leader-Prozess Ergebnisse von seinen Workern erfassen muss.
+ `IPC:ParallelFinish` - Ein Prozess wartet darauf, dass parallele Worker ihre Ausführung beenden und ihre Endergebnisse melden. Dies geschieht während der Abschlussphase der parallelen Abfrageausführung.
**Topics**
+ [Unterstützte Engine-Versionen](#rpg-ipc-parallel-context-supported)
+ [Kontext](#rpg-ipc-parallel-context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#rpg-ipc-parallel-causes)
+ [Aktionen](#rpg-ipc-parallel-actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt.
## Kontext
Bei der parallelen Abfrageausführung in PostgreSQL arbeiten mehrere Prozesse zusammen, um eine einzelne Abfrage zu verarbeiten. Wenn festgestellt wird, dass eine Abfrage für die Parallelisierung geeignet ist, koordiniert ein Leader-Prozess die Arbeit mit einem oder mehreren parallelen Worker-Prozessen je nach `max_parallel_workers_per_gather`-Parametereinstellung. Der Leader-Prozess teilt die Arbeit auf die einzelnen Worker auf und jeder Worker verarbeitet unabhängig seinen Teil der Daten. Die Ergebnisse werden dann an den Leader-Prozess zurückgemeldet.
**Anmerkung**
Jeder parallele Worker fungiert als separater Prozess mit Ressourcenanforderungen, die einer vollständigen Benutzersitzung ähneln. Das bedeutet, dass eine parallel Abfrage mit 4 Workern bis zu fünfmal so viele Ressourcen (CPU, Arbeitsspeicher, I/O Bandbreite) verbrauchen kann wie eine nicht parallele Abfrage, da sowohl der Leader-Prozess als auch jeder Worker-Prozess ihre eigenen Ressourcenzuweisungen beibehalten. So werden beispielsweise Einstellungen wie `work_mem` individuell auf jeden Worker angewendet, wodurch sich die gesamte Speicherbelegung aller Prozesse vervielfachen kann.
Die Architektur einer parallelen Abfrage besteht aus drei Hauptkomponenten:
+ Leader-Prozess: Dies ist der Hauptprozess, der den Parallelbetrieb einleitet, den Workload aufteilt und die Abstimmung mit den Worker-Prozessen vornimmt.
+ Worker-Prozesse: Dies sind Hintergrundprozesse, die Teile der Abfrage parallel ausführen.
+ Gather/Gather merge: Dies sind Operationen, die Ergebnisse mehrerer Worker-Prozesse kombinieren und zurück an den Leader melden.
Während der parallelen Ausführung müssen Prozesse über Mechanismen der Interprozesskommunikation (IPC) miteinander kommunizieren. Diese IPC-Warteereignisse treten in verschiedenen Phasen auf:
+ Worker-Start: wenn parallele Worker initialisiert werden
+ Datenaustausch: wenn Worker Daten verarbeiten und Ergebnisse an den Leader senden
+ Worker-Shutdown: wenn die parallele Ausführung abgeschlossen ist und Worker beendet werden
+ Synchronisierungspunkte: wenn Prozesse koordiniert werden oder darauf warten müssen, dass andere Prozesse ihre Aufgaben abschließen
Das Kennen dieser Warteereignisse ist entscheidend für die Diagnose von Leistungsproblemen im Zusammenhang mit der parallelen Abfrageausführung, insbesondere in Umgebungen mit hoher Nichtsequentialität, in denen mehrere parallele Abfragen gleichzeitig ausgeführt werden.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Verschiedene Faktoren können zu einer Zunahme parallel-bezogener IPC-Warteereignisse beitragen:
**Hohe Nichtsequentialität paralleler Abfragen**
Wenn viele parallele Abfragen gleichzeitig ausgeführt werden, kann dies zu Ressourcenkonflikten und längeren Wartezeiten für IPC-Operationen führen. Dies ist besonders häufig bei Systemen mit hohem Transaktionsvolumen oder analytischen Workloads der Fall.
**Suboptimale Pläne für parallele Abfragen**
Wenn der Abfrageplaner ineffiziente Parallelisierungspläne auswählt, kann dies zu unnötiger Parallelisierung oder schlechter Arbeitsverteilung unter den Workern führen. Dies kann zu höheren IPC-Wartezeiten führen, insbesondere bei den Ereignissen `IPC:ExecuteGather` und `IPC:ParallelFinish`. Diese Planungsprobleme sind häufig auf veraltete Statistiken und table/index unübersichtliche Datenmengen zurückzuführen.
**Häufiges Starten und Herunterfahren paralleler Worker**
Kurzlebige Abfragen, die häufig parallele Worker initiieren und beenden, können zu einer Zunahme von `IPC:BgWorkerStartup`- und `IPC:BgWorkerShutdown`-Ereignissen führen. Dies kommt oftmals bei OLTP-Workloads mit vielen kleinen, parallelisierbaren Abfragen vor.
**Einschränkungen für Ressourcen**
Eine begrenzte CPU, ein begrenzter Arbeitsspeicher oder eine begrenzte I/O Kapazität können zu Engpässen bei der parallel Ausführung führen, was zu längeren Wartezeiten bei allen IPC-Ereignissen führt. Wenn beispielsweise die CPU ausgelastet ist, kann es länger dauern, bis Worker-Prozesse starten oder ihren Teil der Arbeit erledigen.
**Komplexe Abfragestrukturen**
Abfragen mit mehreren Parallelitätsebenen (z. B. parallele Joins, auf die parallele Aggregationen folgen) können zu komplexeren IPC-Mustern und potenziell längeren Wartezeiten führen, insbesondere bei `IPC:ExecuteGather`-Ereignissen.
**Große Ergebnismengen**
Abfragen, die große Ergebnismengen liefern, können zu längeren `IPC:ExecuteGather`-Wartezeiten führen, da der Leader-Prozess mehr Zeit damit verbringt, Ergebnisse von Worker-Prozessen zu erfassen und zu verarbeiten.
Das Kennen dieser Faktoren kann bei der Diagnose und Behebung von Leistungsproblemen im Zusammenhang mit der parallelen Abfrageausführung in Aurora PostgreSQL hilfreich sein.
## Aktionen
Wenn Sie Wartezeiten im Zusammenhang mit parallelen Abfragen bemerken, bedeutet dies in der Regel, dass ein Backend-Prozess parallele Worker-Prozesse koordiniert oder auf diese wartet. Diese Wartezeiten treten häufig bei der Ausführung von Parallelisierungsplänen auf. Sie können die Auswirkungen dieser Wartezeiten untersuchen und abmildern, indem Sie die Verwendung paralleler Worker überwachen, die Parametereinstellungen überprüfen und die Abfrageausführung und Ressourcenzuweisung optimieren.
**Topics**
+ [Analysieren von Abfrageplänen in Bezug auf ineffiziente Parallelität](#rpg-ipc-parallel-analyze-plans)
+ [Überwachen der Verwendung paralleler Abfragen](#rpg-ipc-parallel-monitor)
+ [Überprüfen und Anpassen von Einstellungen für parallele Abfragen](#rpg-ipc-parallel-adjust-settings)
+ [Optimieren der Ressourcenzuweisung](#rpg-ipc-parallel-optimize-resources)
+ [Untersuchen der Verbindungsverwaltung](#rpg-ipc-parallel-connection-management)
+ [Überprüfen und Optimieren von Wartungsvorgängen](#rpg-ipc-parallel-maintenance)
### Analysieren von Abfrageplänen in Bezug auf ineffiziente Parallelität
Die parallele Ausführung von Abfragen kann häufig zu Systeminstabilität, CPU-Spitzen und unvorhersehbaren Leistungsschwankungen bei Abfragen führen. Es ist wichtig, gründlich zu analysieren, ob eine Parallelität Ihrem spezifischen Workload tatsächlich zugutekommt. Verwenden Sie EXPLAIN ANALYZE, um Pläne für die parallele Ausführung von Abfragen zu überprüfen.
Deaktivieren Sie zur Ermittlung der Planeffizienz vorübergehend die Parallelität auf Sitzungsebene:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
Aktivieren Sie zwecks Vergleich wieder die Parallelität:
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
Wenn die Deaktivierung der Parallelität zu besseren oder konsistenteren Ergebnissen führt, sollten Sie erwägen, sie für bestimmte Abfragen auf Sitzungsebene mithilfe von SET-Befehlen zu deaktivieren. Um eine umfassendere Wirkung zu erzielen, können Sie die Parallelität auf Instance-Ebene deaktivieren, indem Sie die entsprechenden Parameter in Ihrer DB-Parametergruppe anpassen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Überwachen der Verwendung paralleler Abfragen
Verwenden Sie die folgenden Abfragen, um einen Einblick in die Aktivität und Kapazität paralleler Abfragen zu gewinnen:
Überprüfen Sie die aktiven, parallelen Worker-Prozesse:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Diese Abfrage zeigt die Anzahl der aktiven, parallelen Worker-Prozesse. Ein hoher Wert kann darauf hinweisen, dass Ihr „max\$1parallel\$1workers“ mit einem hohen Wert konfiguriert ist. Erwägen Sie, diesen zu verringern.
Überprüfen Sie gleichzeitige parallele Abfragen:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Diese Abfrage gibt die Anzahl der verschiedenen Leader-Prozesse zurück, durch die parallele Abfragen gestartet wurden. Eine hohe Zahl weist hier darauf hin, dass mehrere Sitzungen gleichzeitig parallele Abfragen ausführen, was die CPU- und Speicherauslastung erhöhen kann.
### Überprüfen und Anpassen von Einstellungen für parallele Abfragen
Überprüfen Sie die folgenden Parameter, um sicherzustellen, dass sie Ihrem Workload entsprechen:
+ `max_parallel_workers`: Gesamtzahl der parallelen Worker in allen Sitzungen
+ `max_parallel_workers_per_gather`: Max. Worker-Anzahl pro Abfrage
Bei OLAP-Workloads kann eine Erhöhung dieser Werte die Leistung verbessern. Für OLTP-Workloads werden im Allgemeinen niedrigere Werte bevorzugt.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimieren der Ressourcenzuweisung
Überwachen Sie die CPU-Auslastung und erwägen Sie, die Anzahl von v CPUs anzupassen, wenn sie konstant hoch ist und Ihre Anwendung von parallel Abfragen profitiert. Stellen Sie sicher, dass ausreichend Speicher für parallele Operationen verfügbar ist.
+ Ermitteln Sie anhand von Performance Insights, ob das System CPU-gebunden ist.
+ Jeder parallele Worker verwendet seinen eigenen `work_mem`. Stellen Sie sicher, dass die Gesamtspeichernutzung innerhalb der Instance-Grenzen liegt.
Parallele Abfragen können erheblich mehr Ressourcen verbrauchen als nicht parallele, da jeder Worker-Prozess ein vollständig separater Prozess ist, der ungefähr die gleichen Auswirkungen auf das System hat wie eine zusätzliche Benutzersitzung. Dies sollte bei der Auswahl eines Werts für diese Einstellung sowie bei der Konfiguration anderer Einstellungen zur Steuerung der Ressourcennutzung berücksichtigt werden, zum Beispiel `work_mem`. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Ressourcenbegrenzungen, wie `work_mem` werden individuell auf jeden Worker angewendet, das bedeutet, dass die Gesamtauslastung über alle Prozesse hinweg viel höher sein kann, als dies normalerweise für einen einzelnen Prozess der Fall wäre.
Erwägen Sie, v zu erhöhen CPUs oder die Speicherparameter zu optimieren, wenn Ihre Arbeitslast stark parallelisiert ist.
### Untersuchen der Verbindungsverwaltung
Wenn die Verbindung überlastet ist, prüfen Sie Strategien für ein Verbindungspooling der Anwendung. Erwägen Sie die Implementierung von Verbindungspooling auf Anwendungsebene, sofern es nicht bereits verwendet wird.
### Überprüfen und Optimieren von Wartungsvorgängen
Koordinieren Sie die Indexerstellung und andere Wartungsaufgaben, um Ressourcenkonflikte zu vermeiden. Erwägen Sie, diese Vorgänge für Zeiten außerhalb der Spitzenzeiten einzuplanen. Vermeiden Sie es, umfangreiche Wartungsvorgänge (z. B. parallele Indexerstellungen) für Zeiten mit hoher Benutzerabfragelast einzuplanen. Diese Operationen können parallele Worker beanspruchen und die Leistung bei regulären Abfragen negativ beeinträchtigen.
# IPC: ProcArrayGroupUpdate
Das `IPC:ProcArrayGroupUpdate` Ereignis tritt ein, wenn eine Sitzung darauf wartet, dass der Gruppenleiter den Transaktionsstatus am Ende des Vorgangs aktualisiert. Während PostgreSQL im Allgemeinen Warteereignisse vom Typ IPC mit parallel Abfrageoperationen verknüpft, ist dieses spezielle Wartungsereignis nicht spezifisch für parallel Abfragen.
**Topics**
+ [Unterstützte Engine-Versionen](#apg-rpg-ipcprocarraygroup.supported)
+ [Kontext](#apg-rpg-ipcprocarraygroup.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-rpg-ipcprocarraygroup.causes)
+ [Aktionen](#apg-rpg-ipcprocarraygroup.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
**Das Prozessarray verstehen** — Das Prozessarray (proc) ist eine gemeinsam genutzte Speicherstruktur in PostgreSQL. Es enthält Informationen über alle laufenden Prozesse, einschließlich Transaktionsdetails. Während des Abschlusses der Transaktion (`COMMIT`oder`ROLLBACK`) ProcArray muss die Datei aktualisiert werden, um die Änderung widerzuspiegeln und die TransactionID aus dem Array zu löschen. Die Sitzung, die versucht, ihre Transaktion abzuschließen, muss eine exklusive Sperre für erhalten. ProcArray Dadurch wird verhindert, dass andere Prozesse gemeinsame oder exklusive Sperren für die Datei erhalten.
**Mechanismus zur Gruppenaktualisierung** — Wenn ein Back-End-Prozess bei der Ausführung eines COMMIT- oder ROLLBACK-Vorgangs ProcArrayLock im exklusiven Modus keinen Wert abrufen kann, aktualisiert er ein spezielles Feld mit dem Namen. ProcArrayGroupMember Dadurch wird die Transaktion der Liste der Sitzungen hinzugefügt, die beendet werden sollen. Dieser Backend-Prozess schläft dann, und die Zeit, in der er sich befindet, wird als ProcArrayGroupUpdate Warteereignis instrumentiert. Der erste Prozess im ProcArray procArrayGroup With-Member, der als Leader-Prozess bezeichnet wird, erfolgt ProcArrayLock im exklusiven Modus. Anschließend wird die Liste der Prozesse gelöscht, die auf das Löschen der GruppentransactionID warten. Sobald dieser Vorgang abgeschlossen ist, gibt der Leader alle Prozesse in dieser Liste frei ProcArrayLock und aktiviert sie, sodass sie darüber informiert werden, dass ihre Transaktion abgeschlossen ist.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Je mehr Prozesse ausgeführt werden, desto länger hält ein Leader an einem procArrayLock im exklusiven Modus fest. Je mehr Schreibtransaktionen in einem Gruppenaktualisierungsszenario enden, was zu einer potenziellen Anhäufung von Prozessen führt, die auf das Warteereignis `ProcArrayGroupUpdate` warten. In der Top-SQL-Ansicht von Database Insights werden Sie sehen, dass COMMIT die Anweisung ist, bei der der Großteil dieses Warteereignisses auftritt. Dies ist zu erwarten, erfordert jedoch eine eingehendere Untersuchung der spezifischen Schreib-SQL, die gerade ausgeführt wird, um festzustellen, welche geeigneten Maßnahmen zu ergreifen sind.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Identifizieren Sie `IPC:ProcArrayGroupUpdate` Ereignisse mithilfe von Amazon RDS Performance Insights oder durch Abfragen der PostgreSQL-Systemansicht. `pg_stat_activity`
**Topics**
+ [Überwachung von Transaktions-, Commit- und Rollback-Vorgängen](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reduzierung der Parallelität](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementierung von Verbindungspooling](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [Schnelleren Speicher verwenden](#apg-rpg-ipcprocarraygroup.actions.storage)
### Überwachung von Transaktions-, Commit- und Rollback-Vorgängen
**Überwachen Sie Commits und Rollbacks** — Eine erhöhte Anzahl von Commits und Rollbacks kann zu einem erhöhten Druck auf die führen. ProcArray Wenn beispielsweise eine SQL-Anweisung aufgrund einer erhöhten Anzahl von Verletzungen doppelter Schlüssel zu scheitern beginnt, kann es zu einer Zunahme von Rollbacks kommen, was wiederum zu Konflikten und zu einer Überlastung der Tabellen führen kann. ProcArray
Amazon RDS Database Insights stellt die PostgreSQL-Metriken `xact_rollback` bereit `xact_commit` und berichtet über die Anzahl der Commits und Rollbacks pro Sekunde.
### Reduzierung der Parallelität
**Batch-Transaktionen** — Wenn möglich, sollten Operationen in Einzeltransaktionen gebündelt werden, um die Anzahl der Operationen zu reduzieren commit/rollback .
**Parallelität einschränken** — Reduzieren Sie die Anzahl der gleichzeitig aktiven Transaktionen, um Sperrkonflikte bei der zu vermeiden. ProcArray Es sind zwar einige Tests erforderlich, aber eine Reduzierung der Gesamtzahl gleichzeitiger Verbindungen kann Konflikte reduzieren und den Durchsatz aufrechterhalten.
### Implementierung von Verbindungspooling
**Verbindungspooling-Lösungen** — Verwenden Sie Verbindungspooling, um Datenbankverbindungen effizient zu verwalten und so die Gesamtzahl der Backends und damit die Arbeitslast auf dem zu reduzieren. ProcArray Es sind zwar einige Tests erforderlich, aber die Reduzierung der Gesamtzahl gleichzeitiger Verbindungen kann Konflikte reduzieren und den Durchsatz aufrechterhalten.
**Reduzieren Sie Verbindungsstürme** — In ähnlicher Weise führt ein Muster, bei dem häufig Verbindungen hergestellt und beendet werden, zu zusätzlichem Druck auf die. ProcArray Durch die Reduzierung dieses Musters werden Konflikte insgesamt reduziert.
### Schnelleren Speicher verwenden
**Dediziertes Protokollvolumen** — Wenn das `IPC:ProcArrayGroupUpdate` Warteereignis mit Ereignissen mit hoher `IO:WALWrite` Wartezeit einhergeht, kann durch die Einrichtung eines dedizierten Protokollvolumes der Engpass beim Schreiben in WAL reduziert werden. Dies wiederum verbessert die Leistung von Commits.
Weitere Informationen finden Sie unter [Dediziertes Protokollvolumen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).
# Lock:advisory
Das `Lock:advisory`-Ereignis tritt auf, wenn eine PostgreSQL-Anwendung eine Sperre verwendet, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren.
**Topics**
+ [Relevante Engine-Versionen](#wait-event.lockadvisory.context.supported)
+ [Kontext](#wait-event.lockadvisory.context)
+ [Ursachen](#wait-event.lockadvisory.causes)
+ [Aktionen](#wait-event.lockadvisory.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen sind für die RDS-für-PostgreSQL-Versionen 9.6 und höher relevant.
## Kontext
PostgreSQL-Beratungssperren sind Anwendungsebene, kooperative Sperren werden explizit durch den Anwendungscode des Benutzers gesperrt und freigeschaltet. Eine Anwendung kann PostgreSQL-Beratungssperren verwenden, um Aktivitäten über mehrere Sitzungen hinweg zu koordinieren. Im Gegensatz zu normalen Sperren auf Objekt- oder Zeilenebene hat die Anwendung die volle Kontrolle über die Lebensdauer des Schlosses. Weitere Informationen finden Sie unter [Empfohlene Sperren](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
Beratungssperren können vor dem Ende einer Transaktion freigegeben werden oder von einer Sitzung über Transaktionen hinweg gehalten werden. Dies gilt nicht für implizite, vom System erzwungene Sperren, wie z. B. eine zugriffsexklusive Sperre für eine Tabelle, die von einer `CREATE INDEX`-Anweisung abgerufen wird.
Eine Beschreibung der Funktionen zum Erlangen (Sperren) und Freigeben (Entsperren) von Advisory Locks finden Sie unter [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
Advisory Locks werden zusätzlich zum regulären PostgreSQL-Locking-System implementiert und sind in der `pg_locks`-Systemansicht sichtbar.
## Ursachen
Dieser Schlosstyp wird ausschließlich von einer Anwendung gesteuert, die ihn explizit verwendet. Beratungssperren, die für jede Zeile als Teil einer Abfrage erworben werden, können zu einem Anstieg der Sperren oder zu einem langfristigen Aufbau führen.
Diese Effekte treten auf, wenn die Abfrage so ausgeführt wird, dass Sperren für mehr Zeilen erwirbt, als von der Abfrage zurückgegeben werden. Die Anwendung muss schließlich jede Sperre freigeben, aber wenn Sperren für Zeilen erworben werden, die nicht zurückgegeben werden, kann die Anwendung nicht alle Sperren finden.
Das folgende Beispiel stammt aus [Empfohlene Sperren](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in der PostgreSQL-Dokumentation.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
In diesem Beispiel kann die `LIMIT`-Klausel die Ausgabe der Abfrage nur stoppen, nachdem die Zeilen bereits intern ausgewählt und ihre ID-Werte gesperrt wurden. Dies kann plötzlich passieren, wenn ein wachsendes Datenvolumen dazu führt, dass der Planer einen anderen Ausführungsplan auswählt, der während der Entwicklung nicht getestet wurde. Der Aufbau erfolgt in diesem Fall, weil die Anwendung `pg_advisory_unlock` explizit für jeden gesperrten ID-Wert aufruft. In diesem Fall kann es jedoch nicht die Sperren finden, die für Zeilen erworben wurden, die nicht zurückgegeben wurden. Da die Sperren auf Sitzungsebene erworben werden, werden sie am Ende der Transaktion nicht automatisch freigegeben.
Eine weitere mögliche Ursache für Spikes bei blockierten Sperrversuchen sind unbeabsichtigte Konflikte. In diesen Konflikten teilen sich nicht verwandte Teile der Anwendung versehentlich denselben Sperren-ID-Raum.
## Aktionen
Überprüfen Sie die Anwendungsnutzung von Beratungssperren und Details, wo und wann im Anwendungsablauf jede Art von Beratungssperre erworben und freigegeben wird.
Stellen Sie fest, ob eine Sitzung zu viele Sperren erwirbt oder eine lang andauernde Sitzung keine Sperren früh genug freigibt, was zu einem langsamen Aufbau von Sperren führt. Sie können einen langsamen Aufbau von Sperren auf Sitzungsebene korrigieren, indem Sie die Sitzung mit `pg_terminate_backend(pid)` beenden.
Ein Client, der auf eine Beratungssperre wartet, erscheint in `pg_stat_activity` mit `wait_event_type=Lock` und `wait_event=advisory`. Sie können bestimmte Sperrwerte erhalten, indem Sie die `pg_locks`-Systemansicht nach demselben `pid` abfragen und nach `locktype=advisory` und `granted=f` suchen.
Sie können dann die blockierende Sitzung identifizieren, indem Sie `pg_locks` nach derselben beratenden Sperre mit `granted=t` abfragen, wie im folgenden Beispiel gezeigt.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Alle API-Funktionen für beratende Sperren haben zwei Sätze von Argumenten, entweder ein `bigint`-Argument oder zwei `integer`-Argumente:
+ Bei den API-Funktionen mit einem `bigint`-Argument befinden sich die oberen 32 Bit in `pg_locks.classid` und die unteren 32 Bit in `pg_locks.objid`.
+ Bei den API-Funktionen mit zwei `integer`-Argumenten ist das erste Argument `pg_locks.classid` und das zweite Argument ist `pg_locks.objid`.
Der `pg_locks.objsubid`-Wert gibt an, welches API-Formular verwendet wurde: `1` bedeutet ein `bigint`-Argument; `2` bedeutet zwei `integer`-Argumente.
# Lock:extend
Das `Lock:extend`-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Beziehung zu sperren, um sie zu erweitern, während ein anderer Prozess diese Beziehung für denselben Zweck gesperrt hat.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lockextend.context.supported)
+ [Kontext](#wait-event.lockextend.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.lockextend.causes)
+ [Aktionen](#wait-event.lockextend.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:extend` zeigt an, dass ein Backend-Prozess darauf wartet, eine Beziehung zu erweitern, für die ein anderer Backend-Prozess eine Sperre hält, während er diese Beziehung erweitert. Da jeweils nur ein Prozess eine Beziehung erweitern kann, generiert das System ein `Lock:extend`-Warteereignis. `INSERT`-, `COPY`- und `UPDATE`-Vorgänge können dieses Ereignis erzeugen.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `Lock:extend`-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Anstieg der gleichzeitigen Einfügungen oder Aktualisierungen derselben Tabelle **
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die in dieselbe Tabelle einfügen oder aktualisieren.
**Unzureichende Netzwerkbandbreite**
Die Netzwerkbandbreite auf der DB-Instance reicht möglicherweise nicht aus, um die Speicherkommunikationsanforderungen der aktuellen Workload zu gewährleisten. Dies kann zu einer Speicherlatenz führen, die zu einem Anstieg der `Lock:extend`-Ereignisse führt.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung](#wait-event.lockextend.actions.action1)
+ [Erhöhung der Netzwerkbandbreite](#wait-event.lockextend.actions.increase-network-bandwidth)
### Reduzieren Sie gleichzeitige Einfügungen und Aktualisierungen auf dieselbe Beziehung
Stellen Sie zunächst fest, ob die `tup_inserted`- und `tup_updated`-Metriken und damit auch dieses Warteereignis gestiegen ist. Überprüfen Sie in diesem Fall, welche Beziehungen für Einfüge- und Aktualisierungsvorgänge in hohem Streit stehen. Um dies zu ermitteln, fragen Sie die `pg_stat_all_tables`-Ansicht nach den Werten in den `n_tup_ins`- und `n_tup_upd`-Feldern ab. Informationen zur Ansicht `pg_stat_all_tables` finden Sie unter [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) in der PostgreSQL-Dokumentation.
Um weitere Informationen über das Blockieren und blockierte Abfragen zu erhalten, fragen Sie `pg_stat_activity` wie im folgenden Beispiel ab:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Nachdem Sie Beziehungen identifiziert haben, die zur Erhöhung von `Lock:extend`-Ereignissen beitragen, verwenden Sie die folgenden Techniken, um die Konflikte zu reduzieren:
+ Finden Sie heraus, ob Sie Partitionierung verwenden können, um die Konflikte für dieselbe Tabelle zu reduzieren. Das Trennen eingefügter oder aktualisierter Tupel in verschiedene Partitionen kann die Konflikte verringern. Weitere Informationen zur Partitionierung finden Sie unter [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md).
+ Wenn das Warteereignis hauptsächlich auf Aktualisierungsaktivitäten zurückzuführen ist, sollten Sie erwägen, den Füllfaktor-Wert der Beziehung zu reduzieren. Dies kann Anfragen nach neuen Blöcken während des Updates reduzieren. Der Füllfaktor ist ein Speicherparameter für eine Tabelle, der den maximalen Speicherplatz zum Packen einer Tabellenseite bestimmt. Es wird als Prozentsatz des gesamten Speicherplatzes für eine Seite ausgedrückt. Weitere Informationen zum Parameter fillfactor finden Sie unter [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) in der PostgreSQL-Dokumentation.
**Wichtig**
Wir empfehlen dringend, Ihr System zu testen, wenn Sie den Füllfaktor ändern, da sich die Änderung dieses Wertes je nach Workload negativ auf die Leistung auswirken kann.
### Erhöhung der Netzwerkbandbreite
Um zu sehen, ob die Schreiblatenz zunimmt, überprüfen Sie die `WriteLatency`-Metrik in CloudWatch. Wenn dies der Fall ist, verwenden Sie die Amazon-CloudWatch-Metriken `WriteThroughput` und `ReadThroughput`, um den speicherbezogenen Datenverkehr auf der DB-Instance zu überwachen. Diese Metriken können Ihnen helfen festzustellen, ob die Netzwerkbandbreite für die Speicheraktivität Ihrer Workload ausreicht.
Wenn Ihre Netzwerkbandbreite nicht ausreicht, erhöhen Sie sie. Wenn Ihre DB-Instance die Grenzen der Netzwerkbandbreite erreicht, besteht die einzige Möglichkeit, die Bandbreite zu erhöhen, darin, die Größe Ihrer DB-Instance zu erhöhen.
Weitere Informationen zu CloudWatch-Metriken finden Sie unter [Metriken CloudWatch auf Amazon-Instanzebene für Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). Informationen zur Netzwerkleistung für jede DB-Instance-Klasse finden Sie unter [Metriken CloudWatch auf Amazon-Instanzebene für Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
# Lock:Relation
Das `Lock:Relation`-Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Sicht (Relation) zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lockrelation.context.supported)
+ [Kontext](#wait-event.lockrelation.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.lockrelation.causes)
+ [Aktionen](#wait-event.lockrelation.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Die meisten PostgreSQL-Befehle verwenden implizit Sperren, um den gleichzeitigen Zugriff auf Daten in Tabellen zu steuern. Sie können diese Sperren auch explizit mit dem `LOCK`-Befehl in Ihrem Anwendungscode verwenden. Viele Sperrmodi sind nicht miteinander kompatibel und können Transaktionen blockieren, wenn sie versuchen, auf dasselbe Objekt zuzugreifen. In diesem Fall generiert RDS für PostgreSQL ein `Lock:Relation`-Ereignis. Einige gängige Beispiele sind die folgenden:
+ Exklusive Sperren wie `ACCESS EXCLUSIVE` können alle gleichzeitigen Zugriffe blockieren. Vorgänge in der Datendefinitionssprache (DDL) wie `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` und `CLUSTER` erwerben implizit `ACCESS EXCLUSIVE`-Sperren. `ACCESS EXCLUSIVE` ist auch der Standardsperrmodus für `LOCK TABLE`-Anweisungen, die keinen Modus explizit angeben.
+ Die Verwendung von `CREATE INDEX (without CONCURRENT)` für eine Tabelle steht in Konflikt mit den DML-Anweisungen `UPDATE`, `DELETE` und `INSERT`, die `ROW EXCLUSIVE`-Sperren anfordern.
Weitere Informationen zu Sperren auf Tabellenebene und widersprüchlichen Sperrmodi finden Sie unter [Explizite Sperren](https://www.postgresql.org/docs/13/explicit-locking.html) in der PostgreSQL-Dokumentation.
Blockieren von Abfragen und Transaktionen entsperren in der Regel auf eine der folgenden Arten:
+ Blockierende Abfrage — Die Anwendung kann die Abfrage abbrechen oder der Benutzer kann den Prozess beenden. Die Engine kann die Abfrage auch aufgrund des Statement-Timeouts einer Sitzung oder eines Deadlock-Erkennungsmechanismus zum Ende zwingen.
+ Blockieren einer Transaktion – Eine Transaktion stoppt die Blockierung, wenn sie eine `ROLLBACK`- oder `COMMIT`-Anweisung ausführt. Rollbacks erfolgen auch automatisch, wenn Sitzungen von einem Client oder durch Netzwerkprobleme getrennt oder beendet werden. Sitzungen können beendet werden, wenn das Datenbank-Engine heruntergefahren wird, wenn das System keinen Arbeitsspeicher mehr hat usw.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `Lock:Relation`-Ereignis häufiger als normal auftritt, kann dies auf ein Leistungsproblem hinweisen. Zu den typischen Ursachen zählen auch die Folgenden:
**Gleichzeitige Sitzungen mit widersprüchlichen Tabellensperren erhöht**
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die dieselbe Tabelle mit widersprüchlichen Sperrmodi sperren.
**Wartungsvorgänge**
Zustandswartungsvorgänge wie `VACUUM` und `ANALYZE` können die Anzahl widersprüchlicher Sperren erheblich erhöhen. `VACUUM FULL` erhält eine `ACCESS EXCLUSIVE`-Sperre und `ANALYSE` erhält eine `SHARE UPDATE EXCLUSIVE`-Sperre. Beide Arten von Sperren können ein `Lock:Relation`-Wait-Ereignis verursachen. Wartungsvorgänge für Anwendungsdaten wie das Aktualisieren einer materialisierten Ansicht können auch blockierte Abfragen und Transaktionen erhöhen.
**Sperrt bei Reader-In**
Es könnte ein Konflikt zwischen den Beziehungssperren bestehen, die vom Writer und den Readern gehalten werden. Derzeit werden nur `ACCESS EXCLUSIVE`-Beziehungssperren auf Reader-Instances repliziert. Allerdings gerät die `ACCESS EXCLUSIVE`-Beziehungssperre in Konflikt mit jeder `ACCESS SHARE`-Beziehungssperre, die vom Reader gehalten wird. Dies kann zu einer Erhöhung der Warteereignisse für die Sperrbeziehung des Readers führen.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen](#wait-event.lockrelation.actions.reduce-blocks)
+ [Minimieren Sie die Auswirkungen von Wartungsvorgängen](#wait-event.lockrelation.actions.maintenance)
### Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen
Um die Auswirkungen des Blockierens von SQL-Anweisungen zu reduzieren, ändern Sie Ihren Anwendungscode nach Möglichkeit. Es folgen zwei gängige Techniken zum Reduzieren von Blöcken:
+ Verwenden Sie die Option `NOWAIT` – Einige SQL-Befehle, wie z. B. `SELECT`- und `LOCK`-Anweisungen, unterstützen diese Option. Die `NOWAIT`-Direktive bricht die Sperre anfordernde Abfrage ab, wenn die Sperre nicht sofort erworben werden kann. Diese Technik kann dazu beitragen, zu verhindern, dass eine Blockiersitzung eine Anhäufung blockierter Sitzungen dahinter verursacht.
Beispiel: Angenommen, Transaktion A wartet auf eine Sperre, die von Transaktion B gehalten wird. Wenn B nun eine Sperre für eine Tabelle anfordert, die durch Transaktion C gesperrt ist, könnte Transaktion A blockiert werden, bis die Transaktion C abgeschlossen ist. Wenn Transaktion B jedoch ein `NOWAIT` verwendet, wenn sie die Sperre für C anfordert, kann sie schnell fehlschlagen und sicherstellen, dass Transaktion A nicht unbegrenzt warten muss.
+ Verwenden Sie `SET lock_timeout` – Legen Sie einen `lock_timeout`-Wert fest, um die Zeit zu begrenzen, die eine SQL-Anweisung wartet, um eine Sperre für eine Beziehung zu erhalten. Wenn die Sperre nicht innerhalb des angegebenen Timeouts erworben wird, wird die Transaktion, die die Sperre anfordert, abgebrochen. Stellen Sie diesen Wert auf Sitzungsebene ein.
### Minimieren Sie die Auswirkungen von Wartungsvorgängen
Wartungsvorgänge wie `VACUUM` und `ANALYZE` sind wichtig. Wir empfehlen, sie nicht zu deaktivieren, da Sie `Lock:Relation`-Warteereignisse im Zusammenhang mit diesen Wartungsvorgängen finden. Die folgenden Ansätze können die Auswirkungen dieser Vorgänge minimieren:
+ Führen Sie Wartungsvorgänge während außerhalb der Hauptverkehrszeiten manuell aus.
+ Um `Lock:Relation`-Wartezeiten zu reduzieren, die durch Autovacuum-Aufgaben verursacht werden, führen Sie alle erforderlichen Autovacuum-Optimierungen durch. Informationen zum Optimieren von Autovacuum finden Sie unter [Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) im *Amazon-RDS-Benutzerhandbuch*.
# Lock:transactionid
Das `Lock:transactionid`-Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.locktransactionid.context.supported)
+ [Kontext](#wait-event.locktransactionid.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.locktransactionid.causes)
+ [Aktionen](#wait-event.locktransactionid.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:transactionid` tritt ein, wenn eine Transaktion versucht, eine Sperre auf Zeilenebene zu erlangen, die bereits einer gleichzeitig laufenden Transaktion gewährt wurde. Die Sitzung, die das `Lock:transactionid`-Wait-Ereignis anzeigt, ist aufgrund dieser Sperre blockiert. Nachdem die blockierende Transaktion entweder in einer `COMMIT`- oder `ROLLBACK`-Anweisung endet, kann die blockierte Transaktion fortgesetzt werden.
Die Semantik der Multiversions-Parallelität von RDS für PostgreSQL garantiert, dass Leser keine Autoren blockieren und Autoren Leser nicht blockieren. Damit Konflikte auf Zeilenebene auftreten können, müssen blockierende und blockierte Transaktionen widersprüchliche Anweisungen der folgenden Typen ausgeben:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
Die Anweisung `SELECT … FOR KEY SHARE` ist ein Sonderfall. Die Datenbank verwendet die Klausel `FOR KEY SHARE`, um die Leistung der referenziellen Integrität zu optimieren. Eine Sperre auf Zeilenebene für eine Zeile kann `INSERT`-, `UPDATE`- und `DELETE`-Befehle für andere Tabellen blockieren, die auf die Zeile verweisen.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Ereignis mehr als normal auftritt, sind die Ursache normalerweise `UPDATE`-, `SELECT … FOR UPDATE`-, `SELECT … FOR KEY SHARE`-Anweisungen in Kombination mit den folgenden Bedingungen.
**Topics**
+ [Hohe Gleichzeitigkeit](#wait-event.locktransactionid.concurrency)
+ [Leerlauf in Transaktion](#wait-event.locktransactionid.idle)
+ [Lang laufende Transaktionen](#wait-event.locktransactionid.long-running)
### Hohe Gleichzeitigkeit
RDS für PostgreSQL kann eine körnige Sperrsemantik auf Zeilenebene verwenden. Die Wahrscheinlichkeit von Konflikten auf Zeilenebene steigt, wenn die folgenden Bedingungen erfüllt sind:
+ Eine sehr gleichzeitige Workload beansprucht dieselben Zeilen.
+ Parallelbetrieb steigt.
### Leerlauf in Transaktion
Manchmal zeigt die Spalte `pg_stat_activity.state` den Wert `idle in transaction` an. Dieser Wert wird für Sitzungen angezeigt, die eine Transaktion gestartet, aber noch kein `COMMIT` oder `ROLLBACK` ausgegeben haben. Wenn der `pg_stat_activity.state`-Wert nicht `active` ist, ist die in `pg_stat_activity` angezeigte Abfrage die letzte, die ausgeführt wurde. Die blockierende Sitzung verarbeitet eine Abfrage nicht aktiv, da eine offene Transaktion eine Sperre hält.
Wenn eine Leerlauf-Transaktion eine Sperre auf Zeilenebene erworben hat, kann dies verhindern, dass andere Sitzungen sie erwerben. Diese Bedingung führt zu einem häufigen Auftreten des Warteereignisses `Lock:transactionid`. Um das Problem zu diagnostizieren, überprüfen Sie die Ausgabe von `pg_stat_activity` und `pg_locks`.
### Lang laufende Transaktionen
Transaktionen, die lange laufen, erhalten lange Zeit Sperren. Diese langjährigen Sperren können die Ausführung anderer Transaktionen verhindern.
## Aktionen
Zeilensperre ist ein Konflikt zwischen `UPDATE`-, `SELECT … FOR UPDATE`- oder `SELECT … FOR KEY SHARE`-Anweisungen. Bevor Sie eine Lösung versuchen, sollten Sie herausfinden, wann diese Anweisungen in derselben Zeile ausgeführt werden. Wählen Sie mit diesen Informationen eine in den folgenden Abschnitten beschriebene Strategie aus.
**Topics**
+ [Reagieren auf hohe Parallelbetrieb](#wait-event.locktransactionid.actions.problem)
+ [Reagieren Sie auf ungenutzte Transaktionen](#wait-event.locktransactionid.actions.find-blocker)
+ [Reagieren Sie auf lang andauernde Transaktionen](#wait-event.locktransactionid.actions.concurrency)
### Reagieren auf hohe Parallelbetrieb
Wenn Parallelität das Problem darstellt, versuchen Sie eine der folgenden Techniken:
+ Senken Sie die Parallelität in der Anwendung. Verringern Sie beispielsweise die Anzahl der aktiven Sitzungen.
+ Implementieren Sie einen Verbindungspool. Informationen zum Poolen von Verbindungen mit RDS-Proxy finden Sie unter [Amazon RDS-Proxy ](rds-proxy.md).
+ Entwerfen Sie die Anwendung oder das Datenmodell, um konkurrierende `UPDATE`- und `SELECT … FOR UPDATE`-Anweisungen zu vermeiden. Sie können auch die Anzahl der Fremdschlüssel verringern, auf die von `SELECT … FOR KEY SHARE`-Anweisungen zugegriffen wird.
### Reagieren Sie auf ungenutzte Transaktionen
Wenn `pg_stat_activity.state` `idle in transaction` anzeigt, verwenden Sie die folgenden Strategien:
+ Schalten Sie nach Möglichkeit Autocommit ein. Dieser Ansatz verhindert, dass Transaktionen andere Transaktionen blockieren, während sie auf ein `COMMIT` oder `ROLLBACK` warten.
+ Suchen Sie nach Codepfaden, denen `COMMIT`, `ROLLBACK` oder `END` fehlt.
+ Stellen Sie sicher, dass die Ausnahmebehandlungslogik in Ihrer Anwendung immer einen Pfad zu einem gültigen `end of transaction` hat.
+ Stellen Sie sicher, dass Ihre Anwendung Abfrageergebnisse verarbeitet, nachdem die Transaktion mit `COMMIT` oder `ROLLBACK` beendet wurde.
### Reagieren Sie auf lang andauernde Transaktionen
Wenn Transaktionen mit langer Laufzeit das häufige Auftreten von `Lock:transactionid` verursachen, versuchen Sie die folgenden Strategien:
+ Halten Sie Zeilensperren von lang andauernden Transaktionen fern.
+ Beschränken Sie die Länge von Abfragen, indem Sie nach Möglichkeit Autocommit implementieren.
# Lock:tuple
Das `Lock:tuple`-Ereignis tritt ein, wenn ein Backend-Prozess darauf wartet, eine Sperre für ein Tupel zu erlangen.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.locktuple.context.supported)
+ [Kontext](#wait-event.locktuple.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.locktuple.causes)
+ [Aktionen](#wait-event.locktuple.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Das Ereignis `Lock:tuple` zeigt an, dass ein Back-End darauf wartet, eine Sperre für ein Tupel zu erlangen, während ein anderes Back-End eine widersprüchliche Sperre für dasselbe Tupel hält. Die folgende Tabelle veranschaulicht ein Szenario, in dem Sitzungen das `Lock:tuple`-Ereignis generieren.
| Zeit | 1. Sitzung | 2. Sitzung | 3. Sitzung |
| --- | --- | --- | --- |
| t1 | Startet eine Transaktion. | | |
| t2 | Aktualisiert Zeile 1. | | |
| t3 | | Aktualisiert Zeile 1. Die Sitzung erwirbt eine exklusive Sperre für das Tupel und wartet dann darauf, dass Sitzung 1 die Sperre durch Commit oder Rollback freigibt. | |
| t4 | | | Aktualisiert Zeile 1. Die Sitzung wartet darauf, dass Sitzung 2 die exklusive Sperre für das Tupel freigibt. |
Oder Sie können dieses Warteereignis simulieren, indem Sie das Benchmarking-Tool `pgbench` verwenden. Konfigurieren Sie eine hohe Anzahl gleichzeitiger Sitzungen, um dieselbe Zeile in einer Tabelle mit einer benutzerdefinierten SQL-Datei zu aktualisieren.
Weitere Informationen zu widersprüchlichen Sperrmodi finden Sie unter [Explizite Sperren](https://www.postgresql.org/docs/current/explicit-locking.html) in der PostgreSQL-Dokumentation. Weitere Informationen zu `pgbench` finden Sie unter [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in der PostgreSQL-Dokumentation.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn dieses Ereignis mehr als normal auftritt und möglicherweise auf ein Leistungsproblem hinweist, sind typische Ursachen:
+ Eine große Anzahl gleichzeitiger Sitzungen versucht, eine widersprüchliche Sperre für dasselbe Tupel zu erlangen, indem sie `UPDATE`- oder `DELETE`-Anweisungen ausführen.
+ In hochgradig gleichzeitigen Sitzungen wird eine `SELECT`-Anweisung ausgeführt, die den `FOR UPDATE`- oder `FOR NO KEY UPDATE`-Sperrmodus verwendet.
+ Verschiedene Faktoren veranlassen Anwendungs- oder Verbindungspools dazu, weitere Sitzungen zu öffnen, um dieselben Vorgänge auszuführen. Wenn neue Sitzungen versuchen, dieselben Zeilen zu ändern, kann die DB-Last stark ansteigen und `Lock:tuple` kann erscheinen.
Weitere Informationen finden Sie unter [Sperren auf Zeilenebene](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) in der PostgreSQL-Dokumentation.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Untersuchen Sie Ihre Anwendungslogik](#wait-event.locktuple.actions.problem)
+ [Finde die Blocker-Sitzung](#wait-event.locktuple.actions.find-blocker)
+ [Reduzieren Sie Parallelität, wenn es hoch ist](#wait-event.locktuple.actions.concurrency)
+ [Beheben von Engpässen](#wait-event.locktuple.actions.bottlenecks)
### Untersuchen Sie Ihre Anwendungslogik
Finden Sie heraus, ob sich eine Blocker-Sitzung schon lange im `idle in transaction`-Zustand befindet. Wenn ja, erwägen Sie, die Blocker-Sitzung als kurzfristige Lösung zu beenden. Sie können die Funktion `pg_terminate_backend` verwenden. Weitere Informationen zu dieser Funktion finden Sie unter [Server-Signalisierungsfunktionen](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) in der PostgreSQL-Dokumentation.
Gehen Sie für eine langfristige Lösung wie folgt vor:
+ Passen Sie die Anwendungslogik an.
+ Verwenden Sie den Parameter `idle_in_transaction_session_timeout`. Dieser Parameter beendet jede Sitzung mit einer offenen Transaktion, die länger als die angegebene Zeitspanne im Leerlauf ist. Weitere Informationen finden Sie unter [Standardeinstellungen für Clientverbindungen](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) in der PostgreSQL-Dokumentation.
+ Verwenden Sie Autocommit so weit wie möglich. Weitere Informationen finden Sie unter [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) in der PostgreSQL-Dokumentation.
### Finde die Blocker-Sitzung
Identifizieren Sie während des `Lock:tuple`-Wait-Ereignisses den Blocker und die blockierte Sitzung, indem Sie herausfinden, welche Sperren voneinander abhängen. Weitere Informationen finden Sie unter [Informationen zur Sperrabhängigkeit](https://wiki.postgresql.org/wiki/Lock_dependency_information) im PostgreSQL-Wiki.
Im folgenden Beispiel werden alle Sitzungen abgefragt, nach `tuple` gefiltert und nach `wait_time` sortiert.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### Reduzieren Sie Parallelität, wenn es hoch ist
Das `Lock:tuple`-Ereignis kann ständig auftreten, insbesondere in einer arbeitsreichen Zeit. Erwägen Sie in dieser Situation, die hohe Parallelität für sehr belegte Reihen zu reduzieren. Oft steuern nur wenige Zeilen eine Warteschlange oder die boolesche Logik, was diese Zeilen sehr ausgelastet macht.
Sie können die Parallelität reduzieren, indem Sie verschiedene Ansätze verwenden, die auf der Geschäftsanforderung, der Anwendungslogik und dem Workload-Typ basieren. Sie können z. B. Folgendes tun:
+ Gestalten Sie Ihre Tabellen- und Datenlogik neu, um hohe Parallelität zu reduzieren.
+ Ändern Sie die Anwendungslogik, um die hohe Parallelität auf Zeilenebene zu reduzieren.
+ Nutzen und gestalten Sie Abfragen mit Sperren auf Zeilenebene.
+ Verwenden Sie die `NOWAIT`-Klausel mit Wiederholungsvorgänge.
+ Erwägen Sie, optimistische und hybridsperrende Logik-Parallelitätssteuerung zu nutzen.
+ Überlegen Sie, die Isolationsstufe der Datenbank zu ändern.
### Beheben von Engpässen
Das `Lock:tuple` kann bei Engpässen wie CPU-Aushungerungen oder maximaler Nutzung der Amazon EBS-Bandbreite auftreten. Um Engpässe zu verringern, sollten Sie die folgenden Ansätze berücksichtigen:
+ Skalieren Sie Ihren Instance-Klassentyp hoch.
+ Optimieren Sie ressourcenintensive Abfragen.
+ Ändern Sie die Anwendungslogik.
+ Archivieren Sie Daten, die selten zugegriffen wird.
# LWLock: BufferMapping (:buffer\$1mapping) LWLock
Dieses Ereignis tritt ein, wenn eine Sitzung darauf wartet, einen Datenblock einem Puffer im gemeinsam genutzten Pufferpool zuzuordnen.
**Anmerkung**
Dieses Ereignis trägt in RDS für PostgreSQL Version 13 und höheren Versionen den Namen `LWLock:BufferMapping`. In PostgreSQL Version 12 und älteren Versionen lautet die Bezeichnung dieses Ereignisses `LWLock:buffer_mapping`.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lwl-buffer-mapping.context.supported)
+ [Kontext](#wait-event.lwl-buffer-mapping.context)
+ [Ursachen](#wait-event.lwl-buffer-mapping.causes)
+ [Aktionen](#wait-event.lwl-buffer-mapping.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen sind für RDS für PostgreSQL Version 9.6 und höher relevant.
## Kontext
Der *freigegebene Pufferpool* ist ein PostgreSQL-Speicherbereich, der alle Seiten enthält, die von Prozessen verwendet werden oder wurden. Wenn ein Prozess eine Seite benötigt, liest er die Seite in den freigegebenen Pufferpool. Der Parameter `shared_buffers` legt die Größe des gemeinsam genutzten Puffers fest und reserviert einen Speicherbereich zum Speichern der Tabellen- und Indexseiten. Wenn Sie diesen Parameter ändern, stellen Sie sicher, dass Sie die Datenbank neu starten.
Das `LWLock:buffer_mapping`-Wait-Ereignis tritt in den folgenden Szenarien auf:
+ Ein Prozess durchsucht die Puffertabelle nach einer Seite und erwirbt eine freigegebene Puffer-Mapping-Sperre.
+ Ein Prozess lädt eine Seite in den Pufferpool und erwirbt eine exklusive Puffer-Mapping-Sperre.
+ Ein Prozess entfernt eine Seite aus dem Pool und erwirbt eine exklusive Puffer-Mapping-Sperre.
## Ursachen
Wenn dieses Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, greift die Datenbank in und aus dem freigegebenen Pufferpool aus. Zu den typischen Ursachen zählen auch die Folgenden:
+ Große Abfragen
+ Aufgeblähte Indizes und Tabellen
+ Vollständige Tabellenscans
+ Eine gemeinsame Poolgröße, die kleiner als der Arbeitssatz ist
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
**Topics**
+ [Überwachen Sie pufferbezogene Metriken](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [Bewerten Sie Ihre Indexierungsstrategie](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [Reduzieren Sie die Anzahl der Puffer, die schnell zugewiesen werden müssen](#wait-event.lwl-buffer-mapping.actions.buffers)
### Überwachen Sie pufferbezogene Metriken
Wenn `LWLock:buffer_mapping` auf Spitze wartet, untersuchen Sie die Puffertrefferquote. Sie können diese Metriken verwenden, um ein besseres Verständnis dafür zu erhalten, was im Puffer-Cache passiert. Untersuchen Sie die folgenden Metriken:
`blks_hit`
Diese Zählermetrik für Performance Insights gibt die Anzahl der Blöcke an, die aus dem freigegebenen Pufferpool abgerufen wurden. Nachdem das Wait-Ereignis `LWLock:buffer_mapping` aufgetreten ist, können Sie eine Spitze in `blks_hit` beobachten.
`blks_read`
Diese Performance Insights Insights-Zählermetrik gibt die Anzahl der Blöcke I/O an, die in den gemeinsam genutzten Pufferpool eingelesen werden mussten. Sie können im Vorfeld des `LWLock:buffer_mapping`-Warteereignisses eine Spitze in `blks_read` beobachten.
### Bewerten Sie Ihre Indexierungsstrategie
Überprüfen Sie Folgendes, um zu bestätigen, dass Ihre Indexierungsstrategie die Leistung nicht beeinträchtigt:
Indexblähung
Stellen Sie sicher, dass Index und Tabellenaufblähungen nicht dazu führen, dass unnötige Seiten in den freigegebenen Puffer gelesen werden. Wenn Ihre Tabellen nicht verwendete Zeilen enthalten, sollten Sie die Daten archivieren und die Zeilen aus den Tabellen entfernen. Sie können dann die Indizes für die skalierten Tabellen neu erstellen.
Indizes für häufig verwendete Abfragen
Um festzustellen, ob Sie über die optimalen Indizes verfügen, überwachen Sie die Metriken der DB-Engine in Performance Insights. Die `tup_returned`-Metrik zeigt die Anzahl der gelesenen Zeilen an. Die `tup_fetched`-Metrik zeigt die Anzahl der an den Client zurückgegebenen Zeilen. Wenn `tup_returned` deutlich größer als `tup_fetched` ist, werden die Daten möglicherweise nicht richtig indiziert. Außerdem sind Ihre Tabellenstatistiken möglicherweise nicht aktuell.
### Reduzieren Sie die Anzahl der Puffer, die schnell zugewiesen werden müssen
Um die `LWLock:buffer_mapping`-Warteereignisse zu reduzieren, versuchen Sie, die Anzahl der Puffer zu reduzieren, die schnell zugewiesen werden müssen. Eine Strategie besteht darin, kleinere Batch-Vorgänge durchzuführen. Möglicherweise können Sie kleinere Batches erreichen, indem Sie Ihre Tabellen partitionieren.
# LWLock:BufferIO (IPC:BufferIO)
Das `LWLock:BufferIO`-Ereignis tritt auf, wenn RDS für PostgreSQL darauf wartet, dass andere Prozesse ihre Eingabe-/Ausgabe-(I/O)-Vorgänge beenden, wenn sie gleichzeitig versuchen, auf eine Seite zuzugreifen. Sein Zweck besteht darin, dass dieselbe Seite in den freigegebenen Puffer eingelesen wird.
**Topics**
+ [Relevante Engine-Versionen](#wait-event.lwlockbufferio.context.supported)
+ [Kontext](#wait-event.lwlockbufferio.context)
+ [Ursachen](#wait-event.lwlockbufferio.causes)
+ [Aktionen](#wait-event.lwlockbufferio.actions)
## Relevante Engine-Versionen
Diese Warteereignisinformationen sind für alle Versionen von RDS für PostgreSQL relevant. Für Aurora PostgreSQL 12 und frühere Versionen wird dieses Warteereignis als lwlock:buffer\$1io bezeichnet, während es in der Version RDS für PostgreSQL 13 den Namen lwlock:bufferio trägt. Aus der Version RDS für PostgreSQL 14 wurde das BufferIO-Warteereignis von `LWLock` zum Warteereignistyp `IPC` (IPC:BufferIO) verschoben.
## Kontext
Jeder gemeinsam genutzte Puffer hat eine I/O-Sperre, die mit dem `LWLock:BufferIO`-Warteereignis verbunden ist, jedes Mal, wenn ein Block (oder eine Seite) außerhalb des gemeinsam genutzten Pufferpools abgerufen werden muss.
Diese Sperre wird verwendet, um mehrere Sitzungen zu behandeln, die alle Zugriff auf denselben Block benötigen. Dieser Block muss von außerhalb des gemeinsam genutzten Pufferpools gelesen werden, der durch den `shared_buffers`-Parameter definiert wird.
Sobald die Seite innerhalb des Shared Buffer Pool gelesen wird, wird die `LWLock:BufferIO`-Sperre freigegeben.
**Anmerkung**
Das `LWLock:BufferIO`-Wait-Ereignis geht dem [IO: DataFileRead](wait-event.iodatafileread.md)-Warteereignis voraus. Das `IO:DataFileRead`-Wait-Ereignis tritt auf, während Daten aus dem Speicher gelesen werden.
Weitere Informationen zu leichten Sperren finden Sie unter [Übersicht über Sperren](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Ursachen
Häufige Gründe dafür, dass das `LWLock:BufferIO`-Ereignis in den Top-Wartezeiten angezeigt wird, sind die folgenden:
+ Mehrere Backends oder Verbindungen, die versuchen, auf dieselbe Seite zuzugreifen, für die auch ein I/O-Vorgang aussteht
+ Das Verhältnis zwischen der Größe des gemeinsam genutzten Pufferpools (definiert durch den `shared_buffers`-Parameter) und der Anzahl der Puffer, die von der aktuellen Workload benötigt werden
+ Die Größe des freigegebenen Pufferpools ist nicht gut mit der Anzahl der Seiten, die durch andere Vorgänge geräumt werden
+ Große oder aufgeblähte Indizes, bei denen die Engine mehr Seiten als nötig in den freigegebenen Pufferpool lesen muss
+ Mangel an Indizes, die die DB-Engine dazu zwingen, mehr Seiten aus den Tabellen als nötig zu lesen
+ Checkpoints, die zu häufig auftreten oder zu viele geänderte Seiten leeren müssen
+ Plötzliche Spitzen für Datenbankverbindungen, die versuchen, Vorgänge auf derselben Seite auszuführen
## Aktionen
Abhängig von den Ursachen Ihres Wait-Ereignisses empfehlen wir verschiedene Aktionen:
+ Stimmen Sie `max_wal_size` und `checkpoint_timeout` basierend auf der Spitzenzeit Ihrer Workload ab, wenn Sie sehen, dass `LWLock:BufferIO` mit Einbrüchen der Metrik `BufferCacheHitRatio` zusammenfällt. Identifizieren Sie dann, welche Abfrage sie möglicherweise verursachen könnte.
+ Überprüfen Sie, ob Sie nicht verwendete Indizes haben, und entfernen Sie sie dann.
+ Verwenden Sie partitionierte Tabellen (die auch partitionierte Indizes haben). Dies hilft, die Neuordnung des Index niedrig zu halten und ihre Auswirkungen zu reduzieren.
+ Vermeiden Sie, Spalten unnötig zu indizieren.
+ Verhindern Sie plötzliche Spitzen der Datenbankverbindung, indem Sie einen Verbindungspool verwenden.
+ Beschränken Sie die maximale Anzahl von Verbindungen zur Datenbank als bewährte Methode
# LWLock:buffer\$1content (BufferContent)
Das Ereignis `LWLock:buffer_content` tritt ein, wenn eine Sitzung darauf wartet, eine Datenseite im Speicher zu lesen oder zu schreiben, während eine andere Sitzung diese Seite zum Schreiben gesperrt hat. In RDS für PostgreSQL 13 und höher heißt dieses Warteereignis `BufferContent`.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lwlockbuffercontent.context.supported)
+ [Kontext](#wait-event.lwlockbuffercontent.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.lwlockbuffercontent.causes)
+ [Aktionen](#wait-event.lwlockbuffercontent.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
Um Daten zu lesen oder zu manipulieren, greift PostgreSQL über Shared Memory Puffer darauf zu. Um aus dem Puffer zu lesen, erhält ein Prozess eine leichte Sperre (LWLock) für den Pufferinhalt im freigegebenen Modus. Um in den Puffer zu schreiben, wird diese Sperre im exklusiven Modus angezeigt. Gemeinsame Sperren ermöglichen es anderen Prozessen, gleichzeitig gemeinsame Sperren für diesen Inhalt zu erwerben. Exklusive Sperren verhindern, dass andere Prozesse irgendeine Art von Sperre erhalten.
Die`LWLock:buffer_content`(`BufferContent`)-Ereignis zeigt an, dass mehrere Prozesse versuchen, den Inhalt eines bestimmten Puffers zu sperren.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `LWLock:buffer_content`(`BufferContent`)-Ereignis mehr als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die folgenden typischen Ursachen:
**Die gleichzeitigen Aktualisierungen der gleichen Daten wurden erhöht**
Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die denselben Pufferinhalt aktualisieren. Diese Behauptung kann bei Tabellen mit vielen Indizes ausgeprägter sein.
**Workload-Daten befinden sich nicht im Speicher**
Wenn sich Daten, die die aktive Workload verarbeitet, nicht im Speicher befinden, können diese Warteereignisse zunehmen. Dieser Effekt liegt daran, dass Prozesse, die Sperren halten, sie länger halten können, während sie Festplatten-I/O-Vorgänge ausführen.
**Übermäßiger Einsatz von Fremdschlüsselbeschränkungen**
Fremdschlüsseleinschränkungen können die Zeit erhöhen, die ein Prozess an einer Pufferinhaltssperre hält. Dieser Effekt liegt daran, dass Lesevorgänge eine gemeinsame Pufferinhaltssperre für den referenzierten Schlüssel erfordern, während dieser Schlüssel aktualisiert wird.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können `LWLock:buffer_content`(`BufferContent`)-Ereignisse identifizieren, indem Sie Amazon RDS Performance Insights verwenden oder die Ansicht `pg_stat_activity` abfragen.
**Topics**
+ [Verbessern Sie die Effizienz im Speicher](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [Entferne nicht verwendete Indizes](#wait-event.lwlockbuffercontent.actions.indexes)
+ [Erhöhen der Cachegröße bei Verwendung von Sequenzen](#wait-event.lwlockbuffercontent.actions.sequences)
### Verbessern Sie die Effizienz im Speicher
Um die Wahrscheinlichkeit zu erhöhen, dass sich aktive Workload-Daten im Speicher befinden, partitionieren Sie Tabellen oder skalieren Sie Ihre Instance-Klasse hoch. Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md).
### Reduzieren Sie die Verwendung von Fremdschlüsselbeschränkungen
Untersuchen Sie Workloads, bei denen eine hohe Anzahl von `LWLock:buffer_content`(`BufferContent`)-Wait-Ereignissen auf die Verwendung von Fremdschlüsseleinschränkungen auftritt. Entfernen Sie unnötige Fremdschlüsselbeschränkungen.
### Entferne nicht verwendete Indizes
Identifizieren Sie bei Workloads mit einer hohen Anzahl von `LWLock:buffer_content`(`BufferContent`)-Wait-Ereignissen nicht verwendete Indizes und entfernen Sie sie.
### Erhöhen der Cachegröße bei Verwendung von Sequenzen
Wenn Ihre Tabellen Sequenzen verwenden, erhöhen Sie die Cachegröße, um Konflikte auf Sequenzseiten und Indexseiten zu vermeiden. Jede Sequenz ist eine einzelne Seite im gemeinsam genutzten Arbeitsspeicher. Der vordefinierte Cache gilt pro Verbindung. Dies reicht möglicherweise nicht aus, um die Workload zu bewältigen, wenn viele gleichzeitige Sitzungen einen Sequenzwert erhalten.
# LWLock:lock\$1manager (:lockmanager) LWLock
Dieses Ereignis tritt auf, wenn die Engine von RDS für PostgreSQL den Speicherbereich der gemeinsam genutzten Sperre verwaltet, um eine Sperre zuzuweisen, zu überprüfen und aufzuheben, wenn eine Fast-Path-Sperre nicht möglich ist.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lw-lock-manager.context.supported)
+ [Kontext](#wait-event.lw-lock-manager.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.lw-lock-manager.causes)
+ [Aktionen](#wait-event.lw-lock-manager.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen sind für RDS für PostgreSQL Version 9.6 und höher relevant. Für ältere Version von RDS für PostgreSQL als Version 13 lautet der Name dieses Warteereignisses `LWLock:lock_manager`. Für RDS für PostgreSQL Version 13 und höher lautet der Name dieses Warteereignisses `LWLock:lockmanager`.
## Kontext
Wenn Sie eine SQL-Anweisung ausgeben, zeichnet RDS für PostgreSQL Sperren auf, um die Struktur, Daten und Integrität Ihrer Datenbank während gleichzeitiger Vorgänge zu schützen. Der Motor kann dieses Ziel mit einer schnellen Pfadsperre oder einer nicht schnellen Pfadsperre erreichen. Eine Pfadsperre, die nicht schnell ist, ist teurer und erzeugt mehr Overhead als eine schnelle Pfadsperre.
### Schnelle Pfadsperre
Um den Overhead von Sperren zu reduzieren, die häufig genommen und freigegeben werden, aber selten in Konflikt geraten, können Backend-Prozesse eine schnelle Pfadsperrung verwenden. Die Datenbank verwendet diesen Mechanismus für Sperren, die die folgenden Kriterien erfüllen:
+ Sie verwenden die STANDARD–Sperrmethode.
+ Sie stellen eine Sperre für eine Datenbankbeziehung statt einer gemeinsamen Beziehung dar.
+ Sie sind schwache Sperren, die wahrscheinlich nicht in Konflikt stehen.
+ Die Engine kann schnell überprüfen, dass keine widersprüchlichen Sperren existieren können.
Die Engine kann keine schnelle Pfadsperre verwenden, wenn eine der folgenden Bedingungen erfüllt ist:
+ Die Sperre erfüllt nicht die vorhergehenden Kriterien.
+ Für den Backend-Prozess sind keine Slots mehr verfügbar.
Wenn Sie Ihre Abfragen für die Fast-Path-Sperrung optimieren möchten, können Sie die folgende Abfrage verwenden.
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
Die folgende Abfrage zeigt nur die Gesamtsumme in der gesamten Datenbank.
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
Weitere Informationen zum Sperren von Fast Path finden Sie unter [Fast Path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) in der README-Datei des PostgreSQL-Sperrmanagers und unter [pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195) in der PostgreSQL-Dokumentation.
### Beispiel für ein Skalierungsproblem für den Sperrmanager
In diesem Beispiel speichert eine Tabelle mit dem Namen `purchases` Daten aus fünf Jahren, aufgeteilt nach Tagen. Jede Partition hat zwei Indizes. Die folgende Abfolge von Ereignissen tritt auf:
1. Sie fragen Daten für viele Tage ab, wodurch die Datenbank viele Partitionen lesen muss.
1. Die Datenbank erstellt einen Sperreintrag für jede Partition. Wenn Partitionsindizes Teil des Optimizer-Zugriffspfads sind, erstellt die Datenbank auch für sie einen Sperreintrag.
1. Wenn die Anzahl der angeforderten Sperreneinträge für denselben Backend-Prozess höher als 16 ist, was dem Wert von `FP_LOCK_SLOTS_PER_BACKEND` entspricht, verwendet der Sperrenmanager die Sperrmethode ohne Fast Path.
Moderne Anwendungen haben möglicherweise Hunderte von Sitzungen. Wenn gleichzeitige Sitzungen das übergeordnete Element ohne ordnungsgemäßen Schnitt von Partitionen abfragen, erstellt die Datenbank möglicherweise Hunderte oder sogar Tausende von nicht schnellen Pfadsperren. Wenn diese Parallelität höher als die Anzahl von v ist, tritt normalerweise das Ereignis wait auf. CPUs `LWLock:lock_manager`
**Anmerkung**
Das Wait-Ereignis `LWLock:lock_manager` hat nichts mit der Anzahl der Partitionen oder Indizes in einem Datenbankschema zu tun. Stattdessen hängt es mit der Anzahl der nicht schnellen Pfadsperren zusammen, die die Datenbank steuern muss.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Wenn das `LWLock:lock_manager` häufiger als normal auftritt, was möglicherweise auf ein Leistungsproblem hinweist, sind die wahrscheinlichsten Ursachen für plötzliche Spitzen wie folgt:
+ Gleichzeitige aktive Sitzungen führen Abfragen aus, die keine schnellen Pfadsperren verwenden. Diese Sitzungen überschreiten auch die maximale vCPU.
+ Eine große Anzahl gleichzeitiger aktiver Sitzungen greift auf eine stark partitionierte Tabelle zu. Jede Partition hat mehrere Indizes.
+ Die Datenbank erlebt einen Verbindungssturm. Standardmäßig erzeugen einige Anwendungen und Connection Pool-Software mehr Verbindungen, wenn die Datenbank langsam ist. Diese Praxis verschlimmert das Problem. Optimieren Sie Ihre Connection Pool-Software so, dass keine Verbindungsstürme auftreten.
+ Eine große Anzahl von Sitzungen fragt eine übergeordnete Tabelle ab, ohne Partitionen zu beschneiden.
+ Eine Datendefinitionssprache (DDL), Datenmanipulationssprache (DML) oder ein Wartungsbefehl sperrt ausschließlich eine Beleg-Beziehung oder Tupel, auf die häufig zugegriffen oder geändert werden.
## Aktionen
Wenn das `CPU`-Wait-Ereignis auftritt, weist dies nicht unbedingt auf ein Leistungsproblem hin. Reagieren Sie auf dieses Ereignis nur, wenn sich die Leistung verschlechtert und dieses Wait-Ereignis die DB-Last dominiert.
**Topics**
+ [Verwenden Sie das Beschneiden von Partitionen](#wait-event.lw-lock-manager.actions.pruning)
+ [Entfernen unnötiger Indizes](#wait-event.lw-lock-manager.actions.indexes)
+ [Optimieren Sie Ihre Abfragen für schnelles Pfadsperren](#wait-event.lw-lock-manager.actions.tuning)
+ [Tune auf andere Warteereignisse](#wait-event.lw-lock-manager.actions.other-waits)
+ [Reduzieren von Hardware-Engpässen](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [Verwenden eines Verbindungs-Poolers](#wait-event.lw-lock-manager.actions.pooler)
+ [Durchführen eines Upgrades Ihrer Version von RDS für PostgreSQL](#wait-event.lw-lock-manager.actions.pg-version)
### Verwenden Sie das Beschneiden von Partitionen
Die *Partitionsbereinigung* ist eine Strategie zur Abfrageoptimierung für deklarativ partitionierte Tabellen, die nicht benötigte Partitionen von Tabellenscans ausschließt und dadurch die Leistung verbessert. Das Beschneiden der Partition ist standardmäßig aktiviert. Wenn es ausgeschaltet ist, schalten Sie es wie folgt ein.
```
SET enable_partition_pruning = on;
```
Abfragen können die Partitionsbereinigung nutzen, wenn ihre `WHERE`-Klausel die für die Partitionierung verwendete Spalte enthält. Weitere Informationen finden Sie unter [Partitionsbereinigung](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) in der PostgreSQL-Dokumentation.
### Entfernen unnötiger Indizes
Ihre Datenbank enthält möglicherweise nicht verwendete oder selten verwendete Indizes. Wenn ja, erwägen Sie, sie zu löschen. Führen Sie eine der folgenden Aufgaben aus:
+ Erfahren Sie, wie Sie unnötige Indizes finden, indem Sie [Ungenutzte Indizes](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) im PostgreSQL-Wiki lesen.
+ Führen Sie PG Collector aus. Dieses SQL-Skript sammelt Datenbankinformationen und präsentiert sie in einem konsolidierten HTML-Bericht. Überprüfen Sie den Abschnitt „Unbenutzte Indizes“. Weitere Informationen finden Sie unter [pg-collector im Labs-Repository](https://github.com/awslabs/pg-collector). AWS GitHub
### Optimieren Sie Ihre Abfragen für schnelles Pfadsperren
Um herauszufinden, ob Ihre Abfragen Fast Path Locking verwenden, fragen Sie die `fastpath`-Spalte in der `pg_locks`-Tabelle ab. Wenn Ihre Abfragen keine schnelle Pfadsperre verwenden, versuchen Sie, die Anzahl der Beziehungen pro Abfrage auf weniger als 16 zu reduzieren.
### Tune auf andere Warteereignisse
Wenn `LWLock:lock_manager` in der Liste der Top-Waits an erster oder zweiter Stelle steht, überprüfen Sie, ob die folgenden Wait-Ereignisse auch in der Liste erscheinen:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Wenn die vorhergehenden Ereignisse in der Liste hoch erscheinen, sollten Sie zuerst diese Warteereignisse optimieren. Diese Ereignisse können ein Treiber für `LWLock:lock_manager`.
### Reduzieren von Hardware-Engpässen
Möglicherweise haben Sie einen Hardware-Engpass wie CPU-Hunger oder maximale Auslastung Ihrer Amazon EBS-Bandbreite. Ziehen Sie in diesen Fällen die Verringerung der Hardware-Engpässe in Betracht. Berücksichtigen Sie die folgenden Aktionen:
+ Skalieren Sie Ihre Instance-Klasse hoch.
+ Optimieren Sie Abfragen, die große Mengen an CPU und Speicher verbrauchen.
+ Ändern Sie Ihre Anwendungslogik.
+ Archiviere deine Daten.
Weitere Informationen zu CPU, Arbeitsspeicher und EBS-Netzwerkbandbreite finden Sie unter [Amazon-RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/).
### Verwenden eines Verbindungs-Poolers
Wenn Ihre Gesamtzahl aktiver Verbindungen die maximale vCPU überschreitet, benötigen mehr Betriebssystemprozesse CPU, als Ihr Instance-Typ unterstützen kann. Ziehen Sie in diesem Fall die Verwendung oder Abstimmung eines Verbindungspool in Betracht. Weitere Informationen über das v CPUs für Ihren Instance-Typ finden Sie unter [Amazon RDS-Instance-Typen](https://aws.amazon.com/rds/instance-types/).
Weitere Informationen zum Verbindungspooling finden Sie in den folgenden Ressourcen:
+ [Amazon RDS-Proxy ](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Verbindungspools und Datenquellen](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) in der *PostgreSQL-Dokumentation*
### Durchführen eines Upgrades Ihrer Version von RDS für PostgreSQL
Wenn Ihre aktuelle Version von RDS für PostgreSQL niedriger als 12 ist, aktualisieren Sie auf Version 12 oder höher. Die PostgreSQL-Versionen 12 und höher haben einen verbesserten Partitionsmechanismus. Weitere Informationen zu Version 12 finden Sie in den [Versionshinweisen zu PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Weitere Informationen zum Aktualisieren von RDS für PostgreSQL finden Sie unter [Upgrades der DB-Engine von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
# LWLock:pg\$1stat\$1statements
Das LWLock Warteereignis:PG\$1STAT\$1STATEMENTS tritt ein, wenn die Erweiterung die Hashtabelle, die SQL-Anweisungen verfolgt, exklusiv sperrt. `pg_stat_statements` Dies passiert in folgenden Szenarien:
+ Wenn die Anzahl der nachverfolgten Anweisungen den konfigurierten `pg_stat_statements.max`-Parameterwert erreicht und Platz für weitere Einträge geschaffen werden muss, sortiert die Erweiterung die Anzahl der Aufrufe, entfernt die 5 % der am wenigsten ausgeführten Anweisungen und füllt den Hash mit den verbleibenden Einträgen neu auf.
+ Wenn `pg_stat_statements` eine `garbage collection`-Operation für die `pgss_query_texts.stat`-Datei auf der Festplatte durchführt und die Datei neu schreibt
**Topics**
+ [Unterstützte Engine-Versionen](#apg-rpg-lwlockpgstat.supported)
+ [Kontext](#apg-rpg-lwlockpgstat.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-rpg-lwlockpgstat.causes)
+ [Aktionen](#apg-rpg-lwlockpgstat.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
**Grundlagen der pg\$1stat\$1statements-Erweiterung** – Die pg\$1stat\$1statements-Erweiterung verfolgt Statistiken zur Ausführung von SQL-Anweisungen in einer Hash-Tabelle nach. Die Erweiterung verfolgt SQL-Anweisungen bis zu dem durch den `pg_stat_statements.max`-Parameter definierten Grenzwert nach. Dieser Parameter bestimmt die maximale Anzahl von Anweisungen, die nachverfolgt werden können, was der maximalen Anzahl von Zeilen in der pg\$1stat\$1statements-Ansicht entspricht.
**Persistenz von Anweisungsstatistiken** – Die Erweiterung behält die Anweisungsstatistiken über Instance-Neustarts hinweg bei, indem sie Folgendes durchführt:
+ Schreiben von Daten in eine Datei mit dem Namen pg\$1stat\$1statements.stat
+ Steuern des Persistenzverhaltens mit dem pg\$1stat\$1statements.save-Parameter
Wenn pg\$1stat\$1statements.save auf Folgendes gesetzt ist:
+ on (Standard): Statistiken werden beim Herunterfahren gespeichert und beim Serverstart neu geladen
+ off: Statistiken werden weder beim Herunterfahren gespeichert noch beim Serverstart neu geladen
**Abfragetextspeicher** – Die Erweiterung speichert den Text nachverfolgter Abfragen in einer Datei mit dem Namen `pgss_query_texts.stat`. Diese Datei kann auf das Doppelte der durchschnittlichen Größe aller nachverfolgten SQL-Anweisungen anwachsen, ehe eine Garbage Collection erfolgt. Die Erweiterung erfordert eine exklusive Hash-Tabellen-Sperre während der Bereinigungsvorgänge und beim Neuschreiben der `pgss_query_texts.stat`-Datei.
**Prozess der Freigabe von Anweisungen** – Wenn die Anzahl der nachverfolgten Anweisungen den `pg_stat_statements.max`-Grenzwert erreicht und neue Anweisungen nachverfolgt werden müssen, führt die Erweiterung Folgendes durch:
+ Erhält eine exklusive Sperre (LWLock:pg\$1stat\$1statements) für die Hashtabelle.
+ Sie lädt vorhandene Daten in den lokalen Speicher.
+ Sie führt eine Schnellsortierung auf der Grundlage der Anzahl der Aufrufe durch.
+ Sie entfernt die am wenigsten aufgerufenen Anweisungen (unterste 5 %).
+ Sie füllt die Hash-Tabelle mit den verbleibenden Einträgen neu auf.
**Überwachung der Anweisungsfreigabe** – In PostgreSQL 14 und höher können Sie die Freigabe von Anweisungen mit der pg\$1stat\$1statements\$1info-Ansicht überwachen. Diese Ansicht enthält eine Freigabe-Spalte, in der angezeigt wird, wie oft Anweisungen freigegeben wurden, um Platz für neue Anweisungen zu schaffen.
Wenn die Freigabe von Anweisungen häufig erfolgt, führt dies zu einer häufigeren Garbage Collection bei der `pgss_query_texts.stat`-Datei auf der Festplatte.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Zu den typischen Ursachen für eine Zunahme bei den `LWLock:pg_stat_statements`-Wartezeiten gehören:
+ eine Zunahme bei der Anzahl eindeutiger Abfragen, die von der Anwendung verwendet werden
+ ein `pg_stat_statements.max`-Parameterwert, der im Vergleich zur Anzahl der verwendeten eindeutigen Abfragen klein ist
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Sie können `LWLock:pg_stat_statements`-Ereignisse identifizieren, indem Sie Erkenntnisse zur Amazon-RDS-Leistung verwenden oder die `pg_stat_activity`-Ansicht abfragen.
Passen Sie die folgenden `pg_stat_statements` Parameter an, um das Tracking-Verhalten zu steuern und die Warteereignisse von pg\$1stat\$1-Anweisungen zu reduzieren. LWLock
**Topics**
+ [Deaktivieren des pg\$1stat\$1statements.track-Parameters](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Erhöhen des pg\$1stat\$1statements.max-Parameters](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Deaktivieren des pg\$1stat\$1statements.track\$1utility-Parameters](#apg-rpg-lwlockpgstat.actions.disableutility)
### Deaktivieren des pg\$1stat\$1statements.track-Parameters
Wenn sich das LWLock Warteereignis:pg\$1stat\$1statements negativ auf die Datenbankleistung auswirkt und eine schnelle Lösung erforderlich ist, bevor die Ansicht weiter analysiert wird, um die Ursache `pg_stat_statements` zu ermitteln, kann der Parameter deaktiviert werden, indem er auf gesetzt wird. `pg_stat_statements.track` `none` Dadurch wird die Erfassung von Anweisungsstatistiken deaktiviert.
### Erhöhen des pg\$1stat\$1statements.max-Parameters
Erhöhen Sie den Wert des `pg_stat_statements.max`-Parameters, um die Freigabe zu reduzieren und die Garbage Collection für die `pgss_query_texts.stat`-Datei auf der Festplatte zu minimeren. Der Standardwert ist `5,000`.
**Anmerkung**
Der `pg_stat_statements.max`-Parameter ist statisch. Sie müssen Ihre DB-Instance neu starten, um Änderungen an diesem Parameter zu übernehmen.
### Deaktivieren des pg\$1stat\$1statements.track\$1utility-Parameters
Sie können die pg\$1stat\$1statements-Ansicht analysieren, um festzustellen, welche Dienstprogrammbefehle die meisten Ressourcen verbrauchen, die von `pg_stat_statements` nachverfolgt werden.
Der `pg_stat_statements.track_utility`-Parameter steuert, ob das Modul Dienstprogrammbefehle nachverfolgt, zu denen alle Befehle außer SELECT, INSERT, UPDATE, DELETE und MERGE gehören. Dieser Parameter ist standardmäßig auf `on` festgelegt.
Wenn Ihre Anwendung beispielsweise viele Savepoint-Abfragen verwendet, die von Natur aus eindeutig sind, kann dies die Freigabe von Anweisungen erhöhen. Als Abhilfemaßnahme können Sie den `pg_stat_statements.track_utility`-Parameter deaktivieren, sodass Savepoint-Abfragen nicht mehr von `pg_stat_statements` nachverfolgt werden.
**Anmerkung**
Der `pg_stat_statements.track_utility`-Parameter ist ein dynamischer Parameter. Sie können dessen Wert ändern, ohne Ihre Datenbank-Instance neu starten zu müssen.
**Example Beispiel für eindeutige Savepoint-Abfragen in pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 führt mehrere Verbesserungen für die Nachverfolgung von Dienstprogrammbefehlen ein:
+ Savepoint-Namen werden jetzt als Konstanten angezeigt.
+ Die globale Transaktion IDs (GIDs) von zweiphasigen Commit-Befehlen wird jetzt als Konstanten angezeigt.
+ Die Namen von DEALLOCATE-Anweisungen werden als Konstanten angezeigt.
+ CALL-Parameter werden jetzt als Konstanten angezeigt.
# LWLock:subtransSLRU (:) LWLock SubtransControlLock
Die Ereignisse `LWLock:SubtransSLRU` und `LWLock:SubtransBuffer` wait weisen darauf hin, dass eine Sitzung darauf wartet, auf den SLRU-Cache (Simple Least Recently Used) für Subtransaktionsinformationen zuzugreifen. Dies tritt auf, wenn die Sichtbarkeit von Transaktionen und die Beziehungen zwischen übergeordneten und untergeordneten Objekten bestimmt werden.
+ `LWLock:SubtransSLRU`: Ein Prozess wartet darauf, auf den einfachen SLRU-Cache (Least-Recently Used) für eine Subtransaktion zuzugreifen. In RDS für PostgreSQL vor Version 13 wird dieses Warteereignis aufgerufen. `SubtransControlLock`
+ `LWLock:SubtransBuffer`: Ein Prozess wartet I/O auf einen einfachen Puffer, der zuletzt zuletzt verwendet wurde (SLRU) für eine Subtransaktion. In RDS für PostgreSQL vor Version 13 wird dieses Warteereignis aufgerufen. `subtrans`
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.lwlocksubtransslru.supported)
+ [Kontext](#wait-event.lwlocksubtransslru.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.lwlocksubtransslru.causes)
+ [Aktionen](#wait-event.lwlocksubtransslru.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
**Subtransaktionen verstehen** — Eine Subtransaktion ist eine Transaktion innerhalb einer Transaktion in PostgreSQL. Sie wird auch als verschachtelte Transaktion bezeichnet.
Untertransaktionen werden normalerweise erstellt, wenn Sie Folgendes verwenden:
+ `SAVEPOINT`-Befehle
+ Ausnahmeblöcke () `BEGIN/EXCEPTION/END`
Mit Untertransaktionen können Sie Teile einer Transaktion rückgängig machen, ohne dass sich dies auf die gesamte Transaktion auswirkt. Auf diese Weise haben Sie eine detaillierte Kontrolle über das Transaktionsmanagement.
**Implementierungsdetails** — PostgreSQL implementiert Subtransaktionen als verschachtelte Strukturen innerhalb von Haupttransaktionen. Jede Subtransaktion erhält ihre eigene Transaktions-ID.
Wichtigste Aspekte der Implementierung:
+ Transaktionen IDs werden nachverfolgt `pg_xact`
+ Beziehungen zwischen Eltern und Kindern werden im `pg_subtrans` Unterverzeichnis unter gespeichert `PGDATA`
+ Jede Datenbanksitzung kann bis zu aktive Untertransaktionen verwalten `64`
+ Eine Überschreitung dieses Limits führt zu einem Überlauf der Subtransaktionen, was den Zugriff auf den SLRU-Cache (Simple Least-Recently Used) für Subtransaktionsinformationen erfordert
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Zu den häufigsten Ursachen für Konflikte mit der Subtransaktion SLRU gehören:
+ **Übermäßiger Einsatz von SAVEPOINT- und EXCEPTION-Behandlung — PL/pgSQL Prozeduren mit `EXCEPTION` Handlern erstellen automatisch implizite Savepoints, unabhängig davon, ob Ausnahmen** auftreten. Jede initiiert eine neue Subtransaktion. `SAVEPOINT` Wenn eine einzelne Transaktion mehr als 64 Subtransaktionen ansammelt, löst sie einen SLRU-Überlauf für die Subtransaktion aus.
+ **Treiber- und ORM-Konfigurationen** — Die `SAVEPOINT` Verwendung kann explizit im Anwendungscode oder implizit durch Treiberkonfigurationen erfolgen. Viele häufig verwendete ORM-Tools und Anwendungsframeworks unterstützen verschachtelte Transaktionen nativ. Hier sind einige gängige Beispiele:
+ Wenn der JDBC-Treiberparameter `autosave` auf `always` oder gesetzt ist`conservative`, generiert er vor jeder Abfrage Savepoints.
+ Spring Framework-Transaktionsdefinitionen, wenn auf gesetzt. `propagation_nested`
+ Rails, wenn gesetzt `requires_new: true` ist.
+ SQLAlchemy wann `session.begin_nested` wird verwendet.
+ Django, wenn verschachtelte `atomic()` Blöcke verwendet werden.
+ GORM wann `Savepoint` wird verwendet.
+ psqlODBC, wenn die Einstellung der Rollback-Stufe auf Rollback auf Anweisungsebene gesetzt ist (z. B.). `PROTOCOL=7.4-2`
+ **Hohe gleichzeitige Workloads mit lang andauernden Transaktionen und Subtransaktionen — Wenn bei hohen gleichzeitigen Workloads und lang andauernden Transaktionen** und Subtransaktionen ein SLRU-Überlauf der Subtransaktion auftritt, kommt es bei PostgreSQL zu erhöhten Konflikten. Dies äußert `LWLock:SubtransBuffer` sich `LWLock:SubtransSLRU` in erhöhten Wartezeiten und Sperren.
## Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. Einige Maßnahmen bieten sofortige Abhilfe, während andere Untersuchungen und langfristige Korrekturen erfordern.
**Topics**
+ [Überwachung der Nutzung von Subtransaktionen](#wait-event.lwlocksubtransslru.actions.monitor)
+ [Konfiguration von Speicherparametern](#wait-event.lwlocksubtransslru.actions.memory)
+ [Langfristige Maßnahmen](#wait-event.lwlocksubtransslru.actions.longterm)
### Überwachung der Nutzung von Subtransaktionen
Verwenden Sie für PostgreSQL-Versionen 16.1 und höher die folgende Abfrage, um die Anzahl der Subtransaktionen und den Überlaufstatus pro Backend zu überwachen. Diese Abfrage verknüpft Backend-Statistiken mit Aktivitätsinformationen, um zu zeigen, welche Prozesse Subtransaktionen verwenden:
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
Überwachen Sie bei PostgreSQL-Versionen 13.3 und höher die `pg_stat_slru` Ansicht auf den Druck des Subtransaktions-Caches. Die folgende SQL-Abfrage ruft SLRU-Cachestatistiken für die Subtrans-Komponente ab:
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
Ein konstant steigender `blks_read` Wert weist auf häufigen Festplattenzugriff für nicht zwischengespeicherte Untertransaktionen hin, was auf eine potenzielle Belastung des SLRU-Caches hindeutet.
### Konfiguration von Speicherparametern
Für PostgreSQL 17.1 und höher können Sie die Größe des SLRU-Caches der Subtransaktion mithilfe des Parameters konfigurieren. `subtransaction_buffers` Das folgende Konfigurationsbeispiel zeigt, wie der Parameter für den Subtransaktionspuffer festgelegt wird:
```
subtransaction_buffers = 128
```
Dieser Parameter gibt die Menge an gemeinsam genutztem Speicher an, die zum Zwischenspeichern von Subtransaktionsinhalten () `pg_subtrans` verwendet wird. Wenn der Wert ohne Einheiten angegeben wird, steht er für `BLCKSZ` Byteblöcke, in der Regel jeweils 8 KB. Wenn Sie den Wert beispielsweise auf 128 setzen, wird 1 MB (128 \$1 8 KB) Speicher für den Subtransaktions-Cache zugewiesen.
**Anmerkung**
Sie können diesen Parameter auf Clusterebene festlegen, sodass alle Instanzen konsistent bleiben. Testen Sie den Wert und passen Sie ihn an Ihre spezifischen Workload-Anforderungen und Ihre Instance-Klasse an. Sie müssen die Writer-Instanz neu starten, damit die Parameteränderungen wirksam werden.
### Langfristige Maßnahmen
+ **Überprüfen Sie den Anwendungscode und die Konfigurationen** — Überprüfen Sie Ihren Anwendungscode und Ihre Datenbanktreiberkonfigurationen auf explizite und implizite Verwendung sowie auf die `SAVEPOINT` Verwendung von Untertransaktionen im Allgemeinen. Identifizieren Sie Transaktionen, die potenziell über 64 Untertransaktionen generieren.
+ **Reduzieren Sie die Nutzung von Savepoints** — Minimieren Sie die Verwendung von Savepoints in Ihren Transaktionen:
+ Überprüfen Sie PL/pgSQL Verfahren und Funktionen mit EXCEPTION-Blöcken. EXCEPTION-Blöcke erstellen automatisch implizite Savepoints, die zu einem Überlauf von Subtransaktionen beitragen können. Jede EXCEPTION-Klausel erstellt eine Untertransaktion, unabhängig davon, ob während der Ausführung tatsächlich eine Ausnahme auftritt.
**Example**
Beispiel 1: Problematische Verwendung von EXCEPTION-Blocks
Das folgende Codebeispiel zeigt die problematische Verwendung von EXCEPTION-Blocks, die mehrere Untertransaktionen erzeugt:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
Das folgende verbesserte Codebeispiel reduziert die Nutzung von Subtransaktionen, indem UPSERT anstelle der Ausnahmebehandlung verwendet wird:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
Beispiel 2: STRICT-Ausnahmebehandler
Das folgende Codebeispiel zeigt die problematische EXCEPTION-Behandlung mit NO\$1DATA\$1FOUND:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
Das folgende verbesserte Codebeispiel vermeidet Untertransaktionen, indem IF NOT FOUND anstelle der Ausnahmebehandlung verwendet wird:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ JDBC-Treiber — Wenn der `autosave` Parameter auf `always` oder gesetzt ist`conservative`, generiert er vor jeder Abfrage Savepoints. Prüfen Sie, ob die `never` Einstellung für Ihre Anwendung akzeptabel wäre.
+ PostgreSQL ODBC-Treiber (psqlODBC) — Die Rollback-Level-Einstellung (für Rollback auf Anweisungsebene) erstellt implizite Savepoints, um die Rollback-Funktionalität für Anweisungen zu aktivieren. Prüfen Sie, ob ein Rollback auf Transaktionsebene oder kein Rollback für Ihre Anwendung akzeptabel wäre.
+ Untersuchen Sie ORM-Transaktionskonfigur
+ Erwägen Sie alternative Strategien zur Fehlerbehandlung, für die keine Savepoints erforderlich sind
+ **Optimieren Sie das Transaktionsdesign** — Strukturieren Sie Transaktionen neu, um übermäßige Verschachtelungen zu vermeiden und die Wahrscheinlichkeit eines Überlaufs von Subtransaktionen zu verringern.
+ **Reduzierung lang andauernder Transaktionen — Langfristige Transaktionen** können Probleme mit Subtransaktionen verschärfen, da sie die Informationen zu Subtransaktionen länger speichern. Überwachen Sie Performance Insights Insights-Metriken und konfigurieren Sie den `idle_in_transaction_session_timeout` Parameter so, dass inaktive Transaktionen automatisch beendet werden.
+ Performance Insights Insights-Metriken überwachen — Verfolgen Sie Metriken wie `idle_in_transaction_count` (Anzahl der inaktiven Sitzungen im Transaktionsstatus) und `idle_in_transaction_max_time` (Dauer der am längsten laufenden inaktiven Transaktion), um Transaktionen mit langer Laufzeit zu erkennen.
+ Konfigurieren `idle_in_transaction_session_timeout` — Stellen Sie diesen Parameter in Ihrer Parametergruppe so ein, dass inaktive Transaktionen nach einer bestimmten Dauer automatisch beendet werden.
+ Proaktive Überwachung — Überwachen Sie häufig auftretende Ereignisse `LWLock:SubtransBuffer` und `LWLock:SubtransSLRU` warten Sie, bis Konflikte im Zusammenhang mit Untertransaktionen erkannt werden, bevor sie kritisch werden.
# Timeout:PgSleep
Das `Timeout:PgSleep`-Ereignis tritt ein, wenn ein Serverprozess die `pg_sleep`-Funktion aufgerufen hat und auf das Ablaufen des Sleep-Timeouts wartet.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.timeoutpgsleep.context.supported)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.timeoutpgsleep.causes)
+ [Aktionen](#wait-event.timeoutpgsleep.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Dieses Wait-Ereignis tritt auf, wenn eine Anwendung, eine gespeicherte Funktion oder ein Benutzer eine SQL-Anweisung ausgibt, die eine der folgenden Funktionen aufruft:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Die vorhergehenden Funktionen verzögern die Ausführung, bis die angegebene Anzahl von Sekunden verstrichen ist. Beispielsweise pausiert `SELECT pg_sleep(1)` für 1 Sekunde. Weitere Informationen finden Sie unter [Ausführung verzögern](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) in der PostgreSQL-Dokumentation.
## Aktionen
Identifizieren Sie die Anweisung, die die `pg_sleep`-Funktion ausgeführt hat. Überprüfen Sie, ob die Verwendung der Funktion angemessen ist.
# Timeout:VacuumDelay
Das `Timeout:VacuumDelay`-Ereignis weist darauf hin, dass das Kostenlimit für Bereinigungs-I/O überschritten wurde und dass der Bereinigungsprozess in den Ruhezustand versetzt wurde. Bereinigungsoperationen werden für die im jeweiligen Kostenverzögerungsparameter angegebene Dauer unterbrochen und setzen ihren Betrieb danach fort. Für den manuellen Bereinigungsbefehl ist die Verzögerung im `vacuum_cost_delay`-Parameter angegeben. Für den Selbstbereinigungs-Daemon ist die Verzögerung im Parameter `autovacuum_vacuum_cost_delay parameter.` festgelegt.
**Topics**
+ [Unterstützte Engine-Versionen](#wait-event.timeoutvacuumdelay.context.supported)
+ [Kontext](#wait-event.timeoutvacuumdelay.context)
+ [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#wait-event.timeoutvacuumdelay.causes)
+ [Aktionen](#wait-event.timeoutvacuumdelay.actions)
## Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
## Kontext
PostgreSQL verfügt sowohl über einen Selbstbereinigungs-Daemon als auch über einen manuellen Bereinigungsbefehl. Der Selbstbereinigungsprozess ist für DB-Instances von RDS für PostgreSQL standardmäßig aktiviert. Der manuelle Bereinigungsbefehl wird je nach Bedarf verwendet, um beispielsweise Tabellen von toten Tupeln zu bereinigen oder neue Statistiken zu generieren.
Während des Bereinigungsvorgangs verwendet PostgreSQL einen internen Zähler, um die geschätzten Kosten zu verfolgen, während das System verschiedene I/O-Operationen durchführt. Wenn der Zähler den im Kostenlimitparameter angegebenen Wert erreicht, hält der Prozess, der den Vorgang ausführt, für die kurze Dauer an, die im Kostenverzögerungsparameter angegeben ist. Dann setzt er den Zähler zurück und den Betrieb fort.
Der Bereinigungsprozess verfügt über Parameter, mit denen der Ressourcenverbrauch reguliert werden kann. Die Selbstbereinigung und der manuelle Bereinigungsbefehl haben jeweils eigene Parameter zur Einstellung des Kostenlimits. Sie haben auch jeweils eigene Parameter, um eine Kostenverzögerung festzulegen, d. h. eine Zeitspanne, in der die Bereinigung in den Ruhezustand versetzt wird, wenn das Limit erreicht ist. Auf diese Weise fungiert der Kostenverzögerungsparameter als Drosselungsmechanismus für den Ressourcenverbrauch. Die Beschreibung dieser Parameter finden Sie in den folgenden Listen.
**Parameter, die die Drosselung des Selbstbereinigungs-Daemons beeinflussen**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)` – Gibt den Kostenlimitwert an, der bei Selbstbereinigungsoperationen verwendet werden soll. Wenn Sie die Einstellung für diesen Parameter erhöhen, kann der Bereinigungsprozess mehr Ressourcen verbrauchen und das `Timeout:VacuumDelay`-Warteereignis wird verringert.
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)` – Gibt den Kostenverzögerungswert an, der bei Selbstbereinigungsoperationen verwendet werden soll. Der Standardwert ist 2 Millisekunden. Wenn Sie den Verzögerungsparameter auf 0 festlegen, wird der Drosselungsmechanismus deaktiviert, sodass das `Timeout:VacuumDelay`-Warteereignis nicht angezeigt wird.
Weitere Informationen finden Sie unter [Selbstbereinigung](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY) in der PostgreSQL-Dokumentation.
**Parameter, die die Drosselung des manuellen Bereinigungsprozesses beeinflussen**
+ `vacuum_cost_limit` – Die Schwelle, bei der der Bereinigungsvorgang in den Ruhezustand versetzt wird. In der Standardeinstellung ist das Limit 200. Diese Zahl steht für die kumulierten Kostenschätzungen für zusätzliche I/O, die von verschiedenen Ressourcen benötigt werden. Wenn Sie diesen Wert erhöhen, verringert sich die Anzahl der `Timeout:VacuumDelay`-Warteereignisse.
+ `vacuum_cost_delay` – Die Zeitspanne, die der Bereinigungsprozess ruht, wenn das Bereinigungskostenlimit erreicht ist. Die Standardeinstellung ist 0, was bedeutet, dass diese Funktion deaktiviert ist. Sie können diese Einstellung auf einen ganzzahligen Wert festlegen, um die Anzahl der Millisekunden anzugeben und damit diese Funktion zu aktivieren. Wir empfehlen jedoch, die Standardeinstellung beizubehalten.
Weitere Informationen zum `vacuum_cost_delay`-Parameter finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST) in der PostgreSQL-Dokumentation.
Weitere Informationen zur Konfiguration und Verwendung der Selbstbereinigung mit RDS für PostgreSQL finden Sie unter [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
## Wahrscheinliche Ursachen für erhöhte Wartezeiten
Die `Timeout:VacuumDelay` wird durch das Gleichgewicht zwischen Kostenlimitparametern (`vacuum_cost_limit`, `autovacuum_vacuum_cost_limit`) und Kostenverzögerungsparametern (`vacuum_cost_delay`, `autovacuum_vacuum_cost_delay`) beeinflusst, die die Dauer des Ruhezustands des Bereinigungsprozesses steuern. Durch die Erhöhung eines Parameterwerts für das Kostenlimit können mehr Ressourcen vom Bereinigungsprozess verbraucht werden, bevor er in den Ruhezustand versetzt wird. Das führt zu weniger `Timeout:VacuumDelay`-Warteereignissen. Wenn Sie einen der Verzögerungsparameter erhöhen, tritt das `Timeout:VacuumDelay`-Warteereignis häufiger und für längere Zeiträume auf.
Die `autovacuum_max_workers`-Parametereinstellung kann auch die Anzahl der `Timeout:VacuumDelay` erhöhen. Jeder zusätzliche Selbstbereinigungs-Worker-Prozess trägt zum internen Zählermechanismus bei, sodass das Limit schneller erreicht werden kann als mit einem einzelnen Selbstbereinigungs-Worker-Prozess. Da das Kostenlimit schneller erreicht wird, tritt die Kostenverzögerung häufiger in Kraft, was zu mehr`Timeout:VacuumDelay`-Warteereignissen führt. Weitere Informationen finden Sie unter [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS) in der PostgreSQL-Dokumentation.
Große Objekte, z. B. 500 GB oder mehr, lösen dieses Warteereignis ebenfalls aus, da es einige Zeit dauern kann, bis der Bereinigungsprozess die Verarbeitung großer Objekte abgeschlossen hat.
## Aktionen
Wenn die Bereinigungsoperationen wie erwartet abgeschlossen werden, ist keine Abhilfe erforderlich. Mit anderen Worten, dieses Warteereignis weist nicht zwingend auf ein Problem hin. Es gibt an, dass der Bereinigungsprozess für den im Verzögerungsparameter angegebenen Zeitraum in den Ruhezustand versetzt wird, sodass Ressourcen für andere Prozesse verwendet werden können, die abgeschlossen werden müssen.
Wenn Sie möchten, dass Bereinigungsoperationen schneller abgeschlossen werden, können Sie die Verzögerungsparameter niedriger ansetzen. Dadurch wird die Ruhezeit des Bereinigungsprozesses verkürzt.
# Optimierung von RDS für PostgreSQL mit proaktiven Erkenntnissen von Amazon Guru DevOps
DevOpsGuru Proactive Insights erkennt Bedingungen auf Ihren RDS für PostgreSQL-DB-Instances , die Probleme verursachen können, und informiert Sie darüber, bevor sie auftreten. Proaktive Einblicke können Sie auf eine seit langem inaktive Transaktionsverbindung aufmerksam machen. Weitere Informationen zur Fehlerbehebung von seit langem inaktiven Transaktionsverbindungen finden Sie unter [Die Datenbank läuft seit langem inaktiv in Transaktionsverbindung](#proactive-insights.idle-txn).
DevOpsGuru kann Folgendes tun:
+ Vermeiden vieler häufig auftretender Datenbankprobleme durch Abgleich der Datenbankkonfiguration mit den allgemein empfohlenen Einstellungen.
+ Warnen vor kritischen Problemen in der Flotte, die, wenn sie nicht überprüft werden, später zu größeren Problemen führen können.
+ Benachrichtigung bei neu erkannten Problemen.
Jeder proaktive Einblick beinhaltet eine Analyse der Problemursache und Empfehlungen für Korrekturmaßnahmen.
Weitere Informationen zu Amazon DevOps Guru für Amazon RDS finden Sie unter[Analysieren von Leistungsanomalien mit Amazon DevOps Guru für Amazon RDS](devops-guru-for-rds.md).
## Die Datenbank läuft seit langem inaktiv in Transaktionsverbindung
Eine Verbindung zur Datenbank befindet sich sein mehr als 1800 Sekunden im Status `idle in transaction`.
**Topics**
+ [Unterstützte Engine-Versionen](#proactive-insights.idle-txn.context.supported)
+ [Kontext](#proactive-insights.idle-txn.context)
+ [Mögliche Ursachen für dieses Problem](#proactive-insights.idle-txn.causes)
+ [Aktionen](#proactive-insights.idle-txn.actions)
+ [Relevante Metriken](#proactive-insights.idle-txn.metrics)
### Unterstützte Engine-Versionen
Diese Einblick-Informationen werden für alle Versionen von RDS für PostgreSQL unterstützt.
### Kontext
Eine Transaktion im Status `idle in transaction` kann Sperren enthalten, die andere Abfragen blockieren. Sie kann auch verhindern, dass `VACUUM` (einschließlich Autovacuum) tote Zeilen bereinigt, was zu einer Überlastung von Index oder Tabellen oder zu einem Wraparound der Transaktions-ID führt.
### Mögliche Ursachen für dieses Problem
Eine Transaktion, die in einer interaktiven Sitzung mit BEGIN oder START TRANSACTION initiiert wurde, wurde nicht mit einem COMMIT-, ROLLBACK- oder END-Befehl beendet. Dadurch wird die Transaktion in den Status `idle in transaction` versetzt.
### Aktionen
Sie können ungenutzte Transaktionen finden, indem Sie `pg_stat_activity` abfragen.
Führen Sie in Ihrem SQL-Client die folgende Abfrage aus, um alle Verbindungen im Status `idle in transaction` aufzulisten und sie nach Dauer zu sortieren:
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Abhängig von den Ursachen Ihres Einblicks empfehlen wir verschiedene Aktionen.
**Topics**
+ [Transaktion beenden](#proactive-insights.idle-txn.actions.end-txn)
+ [Die Verbindung beenden](#proactive-insights.idle-txn.actions.end-connection)
+ [Konfigurieren Sie den Parameter idle\$1in\$1transaction\$1session\$1timeout](#proactive-insights.idle-txn.actions.parameter)
+ [Überprüfen Sie den AUTOCOMMIT-Status](#proactive-insights.idle-txn.actions.autocommit)
+ [Überprüfen Sie die Transaktionslogik in Ihrem Anwendungscode](#proactive-insights.idle-txn.actions.app-logic)
#### Transaktion beenden
Wenn Sie eine Transaktion in einer interaktiven Sitzung mit BEGIN oder START TRANSACTION initiieren, wechselt sie in den Status `idle in transaction`. Sie verbleibt in diesem Status, bis Sie die Transaktion beenden, indem Sie einen COMMIT-, ROLLBACK-, END-Befehl ausführen oder die Verbindung vollständig trennen, um die Transaktion rückgängig zu machen.
#### Die Verbindung beenden
Beenden Sie die Verbindung mit einer inaktiven Transaktion mit der folgenden Abfrage:
```
SELECT pg_terminate_backend(pid);
```
pid ist die Prozess-ID der Verbindung.
#### Konfigurieren Sie den Parameter idle\$1in\$1transaction\$1session\$1timeout
Stellen Sie den Parameter `idle_in_transaction_session_timeout` in der Parametergruppe ein. Der Vorteil der Konfiguration dieses Parameters besteht darin, dass kein manueller Eingriff erforderlich ist, um die lang dauernde inaktive Transaktion zu beenden. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/runtime-config-client.html).
Die folgende Meldung wird in der PostgreSQL-Protokolldatei angezeigt, nachdem die Verbindung beendet wurde, wenn sich eine Transaktion länger als die angegebene Zeit im Status „idle\$1in\$1transaction“ befindet.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Überprüfen Sie den AUTOCOMMIT-Status
AUTOCOMMIT ist standardmäßig aktiviert. Wenn dies jedoch versehentlich im Client deaktiviert wurde, stellen Sie sicher, dass Sie es wieder aktivieren.
+ Führen Sie in Ihrem psql-Client den folgenden Befehl aus:
```
postgres=> \set AUTOCOMMIT on
```
+ Schalten Sie dies in pgadmin ein, indem Sie die Option AUTOCOMMIT über den Abwärtspfeil wählen.
![\[Wählen Sie in pgadmin AUTOCOMMIT, um es zu aktivieren.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Überprüfen Sie die Transaktionslogik in Ihrem Anwendungscode
Untersuchen Sie Ihre Anwendungslogik auf mögliche Probleme. Berücksichtigen Sie die folgenden Aktionen:
+ Prüfen Sie, ob das JDBC-Autocommit in Ihrer Anwendung auf „true“ gesetzt ist. Erwägen Sie auch, explizite `COMMIT`-Befehle in Ihrem Code zu verwenden.
+ Überprüfen Sie Ihre Fehlerbehandlungslogik, um festzustellen, ob eine Transaktion nach einem Fehler geschlossen wird.
+ Prüfen Sie, ob Ihre Anwendung lange braucht, um die von einer Abfrage zurückgegebenen Zeilen zu verarbeiten, während die Transaktion geöffnet ist. Wenn dies der Fall ist, erwägen Sie, die Anwendung so zu codieren, dass die Transaktion geschlossen wird, bevor die Zeilen verarbeitet werden.
+ Prüfen Sie, ob eine Transaktion viele lang laufende Operationen enthält. Wenn dies der Fall ist, teilen Sie eine einzelne Transaktion in mehrere Transaktionen auf.
### Relevante Metriken
Die folgenden PI-Metriken beziehen sich auf diesen Einblick:
+ idle\$1in\$1transaction\$1count – Anzahl der Sitzungen im Status `idle in transaction`.
+ idle\$1in\$1transaction\$1max\$1time – Die Dauer der am längsten laufenden Transaktion im Status `idle in transaction`.
# Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL
Sie können die Funktionalität von PostgreSQL erweitern, indem Sie eine Vielzahl von Erweiterungen und Modulen installieren. Um beispielsweise mit Geodaten zu arbeiten, können Sie die PostGIS-Erweiterung installieren und verwenden. Weitere Informationen finden Sie unter [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md). Wenn Sie als anderes Beispiel die Dateneingabe für sehr große Tabellen verbessern möchten, können Sie die Partitionierung Ihrer Daten in Betracht ziehen, indem Sie die `pg_partman`-Erweiterung verwenden. Weitere Informationen hierzu finden Sie unter [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md).
**Anmerkung**
RDS für PostgreSQL unterstützt Trusted Language Extensions für PostgreSQL über die `pg_tle`-Erweiterung, die Sie Ihrer DB-Instance hinzufügen können. Mithilfe dieser Erweiterung können Entwickler ihre eigenen PostgreSQL-Erweiterungen in einer sicheren Umgebung erstellen, was die Setup- und Konfigurationsanforderungen vereinfacht. Weitere Informationen zu den Versionen von RDS für PostgreSQL, die `pg_tle`-Erweiterungen unterstützen, und weitere Informationen finden Sie unter. [Arbeiten mit Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension.md)
In einigen Fällen bietet es sich an, anstatt eine Erweiterung zu installieren, ein bestimmtes Modul zur Liste der `shared_preload_libraries` in der benutzerdefinierten DB-Parametergruppe Ihrer DB-Instance von RDS für PostgreSQL hinzufügen. In der Regel lädt die standardmäßige DB-Cluster-Parametergruppe nur die `pg_stat_statements`. Es stehen jedoch weitere Module zur Verfügung, die der Liste hinzugefügt werden können. Sie können beispielsweise Planungsfunktionen hinzufügen, indem Sie das `pg_cron`-Modul hinzufügen, wie unter [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md) beschrieben. Als weiteres Beispiel können Sie Abfrageausführungspläne protokollieren, indem Sie das `auto_explain`-Modul laden. Weitere Informationen finden Sie im AWS Knowledge Center unter [Ausführungspläne von Abfragen protokollieren](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#).
Abhängig von Ihrer Version von RDS für PostgreSQL erfordert die Installation einer Erweiterung möglicherweise `rds_superuser`-Berechtigungen wie folgt:
+ Für RDS für PostgreSQL Versionen 12 und frühere Versionen erfordert das Installieren von Erweiterungen `rds_superuser`-Berechtigungen.
+ Für RDS für PostgreSQL Version 13 und höher können Benutzer (Rollen) mit Erstellungsberechtigungen für eine bestimmte Datenbank-Instance *vertrauenswürdige Erweiterungen* installieren und verwenden. Eine Liste mit vertrauenswürdigen Erweiterungen finden Sie unter [Vertrauenswürdige Erweiterungen für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
Sie können auch genau angeben, welche Erweiterungen auf Ihrer DB-Instance von RDS für PostgreSQL installiert werden können, indem Sie sie im Parameter `rds.allowed_extensions` aufführen. Weitere Informationen finden Sie unter [Beschränkung der Installation von PostgreSQL-Erweiterungen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Weitere Informationen über die `rds_superuser`-Rolle finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [Verwenden der Funktionen aus der orafce-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [Verwenden der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL](RDS_delegated_ext.md)
+ [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md)
+ [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md)
+ [Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [Verwenden von „pgactive“ zur Unterstützung der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [Erweiterung aktualisieren und verwenden PLV8](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [Verwenden PL/Rust , um PostgreSQL-Funktionen in der Sprache Rust zu schreiben](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Verwenden der Funktionen aus der orafce-Erweiterung
Die Orafce-Erweiterung bietet Funktionen und Operatoren, die eine Teilmenge von Funktionen und Paketen aus einer Oracle-Datenbank emulieren. Die orafce-Erweiterung erleichtert Ihnen das Portieren einer Oracle-Anwendung nach PostgreSQL. RDS for PostgreSQL Version 9.6.6 und höher unterstützt diese Erweiterung. Weitere Informationen zu Oracle finden Sie unter [orafce](https://github.com/orafce/orafce) on. GitHub
**Anmerkung**
RDS for PostgreSQL unterstützt das Paket `utl_file` nicht, das Teil der Erweiterung orafce ist. Dies liegt daran, dass die `utl_file`-Schema-Funktionen Lese- und Schreiboperationen für Betriebssystem-Textdateien ermöglichen, wofür ein Superuser-Zugriff auf den zugrundeliegenden Host erforderlich ist. Als verwalteter Service bietet RDS for PostgreSQL keinen Hostzugriff.
**So verwenden Sie die orafce-Erweiterung**
1. Stellen Sie unter Verwendung des Hauptbenutzernamens, der für die Erstellung der DB-Instance verwendet wurde, eine Verbindung mit der DB-Instance her.
Wenn Sie orafce für eine andere Datenbank in derselben DB-Instance aktivieren möchten, verwenden Sie den Befehl `/c dbname`-psql. Mit diesem Befehl wechseln Sie nach dem Einleiten der Verbindung aus der primären Datenbank.
1. Aktivieren Sie die orafce-Erweiterung mit der Anweisung `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Übertragen Sie den Besitz der oracle-Schemas mit der Anweisung `ALTER SCHEMA` auf die rds\$1superuser-Rolle.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Mit dem psql-Befehl `\dn` zeigen Sie die Liste der Eigentümer für das oracle-Schema an.
# Verwenden der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
Mithilfe der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL können Sie die Erweiterungsverwaltung an einen Benutzer delegieren, der kein `rds_superuser` sein muss. Mit dieser Unterstützung für delegierte Erweiterungen wird die neue Rolle `rds_extension` erstellt und Sie müssen diese einem Benutzer zuweisen, um andere Erweiterungen zu verwalten. Mit dieser Rolle können Erweiterungen erstellt, aktualisiert und gelöscht werden.
Sie können auch genau angeben, welche Erweiterungen auf Ihrer RDS-DB-Instance installiert werden können, indem Sie sie im Parameter `rds.allowed_extensions` aufführen. Weitere Informationen finden Sie unter [Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
Mit dem Parameter `rds.allowed_delegated_extensions` können Sie die Liste der Erweiterungen einschränken, die vom Benutzer mit der `rds_extension`-Rolle verwaltet werden kann.
Die Unterstützung für delegierte Erweiterungen ist in den folgenden Versionen verfügbar:
+ Alle höheren Versionen
+ 16.4 und höhere 16-Versionen
+ 15.8 und höhere 15-Versionen
+ 14.13 und höhere 14-Versionen
+ 13.16 und höhere 13 Versionen
+ 12.20 und höhere 12 Versionen
**Topics**
+ [Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer](#RDSPostgreSQL.delegated_ext_mgmt)
+ [Konfiguration, die bei der Unterstützung für delegierte Erweiterungen von RDS für PostgreSQL verwendet wird](#RDSPostgreSQL.delegated_ext_config)
+ [Deaktivieren der Unterstützung für die delegierte Erweiterung](#RDSPostgreSQL.delegated_ext_disable)
+ [Vorteile der Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS](#RDSPostgreSQL.delegated_ext_benefits)
+ [Einschränkung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL](#RDSPostgreSQL.delegated_ext_limit)
+ [Für bestimmte Erweiterungen erforderliche Berechtigungen](#RDSPostgreSQL.delegated_ext_perm)
+ [Sicherheitsüberlegungen](#RDSPostgreSQL.delegated_ext_sec)
+ [Drop extension cascade ist deaktiviert](#RDSPostgreSQL.delegated_ext_drop)
+ [Beispielerweiterungen, die mithilfe der Unterstützung für delegierte Erweiterungen hinzugefügt werden können](#RDSPostgreSQL.delegated_ext_support)
## Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer
Sie müssen die folgenden Schritte ausführen, um die Unterstützung für delegierte Erweiterungen für einen Benutzer zu aktivieren:
1. **Einem Benutzer die `rds_extension`-Rolle erteilen** – Stellen Sie als `rds_superuser` eine Verbindung zur Datenbank her und führen Sie den folgenden Befehl aus:
```
Postgres => grant rds_extension to user_name;
```
1. **Die Liste der Erweiterungen festlegen, die von delegierten Benutzern verwaltet werden können** – Mit `rds.allowed_delegated_extensions` können Sie unter Verwendung von `rds.allowed_extensions` im DB-Cluster-Parameter eine Teilmenge der verfügbaren Erweiterungen angeben. Sie können dies auf einer der folgenden Ebenen durchführen:
+ Im Cluster oder in der Instance-Parametergruppe, über die AWS-Managementkonsole oder API. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**Anmerkung**
Sie müssen die Datenbank nicht neu starten, nachdem Sie den dynamischen Parameter `rds.allowed_delegated_extensions` geändert haben.
1. **Dem delegierten Benutzer Zugriff auf Objekte gewähren, die während dem Prozess der Erweiterungserstellung erstellt wurden** – Bestimmte Erweiterungen erstellen Objekte, für die zusätzliche Berechtigungen erteilt werden müssen, bevor der Benutzer mit der `rds_extension`-Rolle auf sie zugreifen kann. Der `rds_superuser` muss dem delegierten Benutzer Zugriff auf diese Objekte gewähren. Eine der Optionen besteht darin, einen Ereignisauslöser zu verwenden, um dem delegierten Benutzer automatisch die Berechtigung zu erteilen.
**Beispiel für einen Event-Trigger**
Wenn Sie einem delegierten Benutzer mit `rds_extension` die Verwendung von Erweiterungen ermöglichen möchten, für die Berechtigungen für seine bei der Erstellung der Erweiterung erstellten Objekte erforderlich sind, können Sie das folgende Beispiel für einen Ereignisauslöser anpassen und nur die Erweiterungen hinzufügen, für die die delegierten Benutzer Zugriff auf die gesamte Funktionalität haben sollen. Dieser Ereignisauslöser kann auf template1 (der Standardvorlage) erstellt werden, sodass alle mit template1 erstellten Datenbanken über diesen Ereignisauslöser verfügen. Wenn ein delegierter Benutzer die Erweiterung installiert, gewährt dieser Trigger automatisch die Eigentümerschaft an den von der Erweiterung erstellten Objekten.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Konfiguration, die bei der Unterstützung für delegierte Erweiterungen von RDS für PostgreSQL verwendet wird
| Konfigurationsname | Description | Standardwert | Hinweise | Wer Berechtigungen ändern oder erteilen kann |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Dieser Parameter schränkt die Erweiterungen ein, die eine rds\$1extension-Rolle in einer Datenbank verwalten kann. Es muss sich um eine Teilmenge von rds.allowed\$1extensions handeln. | leere Zeichenfolge | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Weitere Informationen zum Einrichten dieses Parameters finden Sie unter [Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer](#RDSPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Mit diesem Parameter kann der Kunde die Erweiterungen einschränken, die in der RDS-DB-Instance installiert werden können. Weitere Informationen finden Sie unter [Einschränken der Installation von PostgreSQL-Erweiterungen](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | Standardmäßig ist dieser Parameter auf „\$1“ gesetzt, was bedeutet, dass alle von RDS für PostgreSQL und Aurora PostgreSQL unterstützten Erweiterungen von Benutzern mit den erforderlichen Berechtigungen erstellt werden dürfen. Leer bedeutet, dass keine Erweiterungen in der RDS-DB-Instance installiert werden können. | Administrator |
| `rds-delegated_extension_allow_drop_cascade` | Dieser Parameter steuert, ob Benutzer mit `rds_extension` die Erweiterung mithilfe der Option cascade löschen können. | aus | `rds-delegated_extension_allow_drop_cascade` ist standardmäßig auf `off` festgelegt. Dies bedeutet, dass Benutzer mit `rds_extension` eine Erweiterung mithilfe der Option cascade nicht löschen dürfen. Zur Erteilung dieser Fähigkeit sollte der Parameter `rds.delegated_extension_allow_drop_cascade` auf `on` gesetzt werden. | rds\$1superuser |
## Deaktivieren der Unterstützung für die delegierte Erweiterung
**Teilweises Deaktivieren**
Die delegierten Benutzer können keine neuen Erweiterungen erstellen, aber trotzdem bestehende Erweiterungen aktualisieren.
+ Setzen Sie `rds.allowed_delegated_extensions` in der DB-Cluster-Parametergruppe auf den Standardwert zurück.
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Vollständiges Deaktivieren**
Wenn Sie einem Benutzer die `rds_extension`-Rolle entziehen, erhält der Benutzer wieder die Standardberechtigungen. Der Benutzer kann keine Erweiterungen mehr erstellen, aktualisieren oder löschen.
```
postgres => revoke rds_extension from user_name;
```
## Vorteile der Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS
Durch die Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL delegieren Sie die Erweiterungsverwaltung sicher an Benutzer, die nicht über die `rds_superuser`-Rolle verfügen. Diese Funktion bietet die folgenden Vorteile:
+ Sie können die Erweiterungsverwaltung ganz einfach an Benutzer Ihrer Wahl delegieren.
+ Dafür ist keine `rds_superuser`-Rolle erforderlich.
+ Bietet die Möglichkeit, verschiedene Gruppen von Erweiterungen für unterschiedliche Datenbanken im selben DB-Cluster zu unterstützen
## Einschränkung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
+ Objekte, die während der Erweiterungserstellung erstellt wurden, benötigen möglicherweise zusätzliche Berechtigungen, damit die Erweiterung ordnungsgemäß funktioniert.
+ Einige Erweiterungen können standardmäßig nicht vom Benutzer der delegierten Erweiterung verwaltet werden, darunter die folgenden: `log_fdw`, `pg_cron`, `pg_tle`, `pgactive`, `pglogical`, `postgis_raster`, `postgis_tiger_geocoder`, `postgis_topology`.
## Für bestimmte Erweiterungen erforderliche Berechtigungen
Um die folgenden Erweiterungen zu erstellen, zu verwenden oder zu aktualisieren, sollte der delegierte Benutzer über die erforderlichen Berechtigungen für die folgenden Funktionen, Tabellen und Schemas verfügen.
| Erweiterungen, für die eine Eigentümerschaft oder Berechtigungen erforderlich sind | Funktion | Tabellen | Schema | Wörterbuch für die Textsuche | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | Keine | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | Keine | Keine | Keine |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | Keine | Keine | Keine | Keine |
| dict\$1int | Keine | Keine | Keine | intdict | Keine |
| pg\$1partman | Keine | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | Keine | Keine | Keine |
| pg\$1stat\$1statements | Keine | Keine | Keine | Keine | Keine |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | Keine | Keine | Keine |
| postgis\$1raster | Keine | Keine | Keine | Keine | Keine |
| postgis\$1topology | Keine | topology, layer | topology | Keine | Der delegierte Benutzer muss der Datenbankbesitzer sein. |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | Keine | Keine | Keine | Keine |
| rds\$1tools | role\$1password\$1encryption\$1type | Keine | Keine | Keine | Keine |
| postgis\$1tiger\$1geocoder | Keine | geocode\$1settings\$1default, geocode\$1settings | tiger | Keine | Keine |
| pg\$1freespacemap | pg\$1freespace | Keine | Keine | Keine | Keine |
| pg\$1visibility | pg\$1visibility | Keine | Keine | Keine | Keine |
## Sicherheitsüberlegungen
Denken Sie daran, dass ein Benutzer mit der `rds_extension`-Rolle Erweiterungen für alle Datenbanken verwalten kann, für die er die Connect-Berechtigung hat. Wenn beabsichtigt ist, dass ein delegierter Benutzer die Erweiterung für eine einzelne Datenbank verwaltet, empfiehlt es sich, alle öffentlichen Berechtigungen für jede Datenbank zu entziehen und dann dem delegierten Benutzer explizit die Connect-Berechtigung für diese spezifische Datenbank zu gewähren.
Es gibt mehrere Erweiterungen, mit denen ein Benutzer auf Informationen aus mehreren Datenbanken zugreifen kann. Stellen Sie sicher, dass die Benutzer, denen Sie `rds_extension` gewähren, über datenbankübergreifende Funktionen verfügen, bevor Sie diese Erweiterungen zu `rds.allowed_delegated_extensions` hinzufügen. `postgres_fdw` und `dblink` stellen beispielsweise Funktionen für datenbankübergreifende Abfragen auf derselben Instance oder auf Remote-Instances bereit. `log_fdw` liest die Protokolldateien der Postgres-Engine, die für alle Datenbanken in der Instance gelten und möglicherweise langsame Abfragen oder Fehlermeldungen von mehreren Datenbanken enthalten. `pg_cron` ermöglicht die Ausführung von geplanten Hintergrundaufträgen auf der DB-Instance und kann Aufträge so konfigurieren, dass sie in einer anderen Datenbank ausgeführt werden.
## Drop extension cascade ist deaktiviert
Die Möglichkeit, die Erweiterung mit der Option cascade durch einen Benutzer mit der `rds_extension`-Rolle zu löschen, wird durch den Parameter `rds.delegated_extension_allow_drop_cascade` gesteuert. `rds-delegated_extension_allow_drop_cascade` ist standardmäßig auf `off` festgelegt. Das bedeutet, dass Benutzer mit der Rolle `rds_extension` keine Erweiterung mithilfe der Option cascade löschen dürfen, wie in der untenstehenden Abfrage gezeigt.
```
DROP EXTENSION CASCADE;
```
Da dadurch automatisch Objekte gelöscht werden, die von der Erweiterung abhängen – und in der Folge auch alle Objekte, die wiederum von diesen Objekten abhängig sind. Der Versuch, die Option cascade zu verwenden, führt zu einem Fehler.
Zur Erteilung dieser Fähigkeit sollte der Parameter `rds.delegated_extension_allow_drop_cascade` auf `on` gesetzt werden.
Das Ändern des dynamischen Parameters `rds.delegated_extension_allow_drop_cascade` erfordert keinen Neustart der Datenbank. Sie können dies auf einer der folgenden Ebenen tun:
+ Im Cluster oder in der Instanzparametergruppe, über die API AWS-Managementkonsole oder.
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Beispielerweiterungen, die mithilfe der Unterstützung für delegierte Erweiterungen hinzugefügt werden können
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman
Die PostgreSQL-Tabellenpartitionierung bietet ein Framework für den leistungsstarken Umgang mit Dateneingaben und Berichten. Verwenden Sie die Partitionierung für Datenbanken, die eine sehr schnelle Eingabe großer Datenmengen erfordern. Die Partitionierung ermöglicht auch schnellere Abfragen großer Tabellen. Die Partitionierung hilft bei der Verwaltung von Daten, ohne die Datenbank-Instance zu beeinträchtigen, da sie weniger I/O-Ressourcen benötigt.
Durch die Partitionierung können Sie Daten zur Verarbeitung in benutzerdefinierte Blöcke aufteilen. Sie können beispielsweise Zeitreihendaten für Bereiche wie stündlich, täglich, wöchentlich, monatlich, vierteljährlich, jährlich, benutzerdefiniert oder eine beliebige Kombination davon partitionieren. Wenn Sie für ein Beispiel für Zeitreihendaten die Tabelle nach Stunden partitionieren, enthält jede Partition die Daten einer Stunde. Wenn Sie die Zeitreihentabelle nach Tag partitionieren, enthalten die Partitionen die Daten eines Tages und so weiter. Der Partitionsschlüssel steuert die Größe einer Partition.
Wenn Sie den SQL-Befehl `INSERT` oder `UPDATE` für eine partitionierte Tabelle verwenden, leitet die Datenbank-Engine die Daten an die entsprechende Partition weiter. PostgreSQL-Tabellenpartitionen, die die Daten speichern, sind untergeordnete Tabellen der Haupttabelle.
Während der Lesevorgänge der Datenbankabfrage untersucht der PostgreSQL-Optimierer die `WHERE`-Klausel der Abfrage und leitet den Datenbank-Scan nach Möglichkeit nur an die relevanten Partitionen weiter.
Beginnend mit Version 10 verwendet PostgreSQL deklarative Partitionierung, um die Tabellenpartitionierung zu implementieren. Dies wird auch als native PostgreSQL-Partitionierung bezeichnet. Vor PostgreSQL Version 10 wurden Auslöser verwendet, um Partitionen zu implementieren.
Die PostgreSQL-Tabellenpartitionierung bietet die folgenden Funktionen:
+ Erstellung neuer Partitionen zu jeder Zeit.
+ Variable Partitionsbereiche.
+ Entfernbare und wiederverwendbare Partitionen mit DDL-Anweisungen (Data Definition Language).
Zum Beispiel sind entfernbare Partitionen nützlich, um Verlaufsdaten aus der Hauptpartition zu entfernen, aber Verlaufsdaten für die Analyse zu behalten.
+ Neue Partitionen erben die Eigenschaften der übergeordneten Datenbanktabelle, einschließlich folgender Eigenschaften:
+ Indizes
+ Primärschlüssel, die die Partitionsschlüsselspalte enthalten müssen
+ Fremdschlüssel
+ Einschränkungen prüfen
+ Referenzen
+ Erstellen von Indizes für die vollständige Tabelle oder jede spezifische Partition.
Sie können das Schema für eine einzelne Partition nicht ändern. Sie können jedoch die übergeordnete Tabelle ändern (z. B. das Hinzufügen einer neuen Spalte), die auf Partitionen übertragen wird.
**Topics**
+ [Übersicht über die PostgreSQL-Erweiterung pg\$1partman](#PostgreSQL_Partitions.pg_partman)
+ [Aktivieren der Erweiterung pg\$1partman](#PostgreSQL_Partitions.enable)
+ [Konfigurieren von Partitionen mit der create\$1parent-Funktion](#PostgreSQL_Partitions.create_parent)
+ [Konfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion](#PostgreSQL_Partitions.run_maintenance_proc)
## Übersicht über die PostgreSQL-Erweiterung pg\$1partman
Sie können die PostgreSQL-Erweiterung `pg_partman` verwenden, um die Erstellung und Pflege von Tabellenpartitionen zu automatisieren. Weitere allgemeine Informationen finden Sie unter [PG-Partitions-Manager](https://github.com/pgpartman/pg_partman) in der `pg_partman`-Dokumentation.
**Anmerkung**
Die Erweiterung `pg_partman` wird auf den RDS-for-PostgreSQL-Versionen 12.5 und höher unterstützt.
Anstatt jede Partition manuell erstellen zu müssen, konfigurieren Sie `pg_partman` mit den folgenden Einstellungen:
+ Zu partitionierende Tabelle
+ Partitionstyp
+ Partitionsschlüssel
+ Granularität der Partition
+ Optionen für die Erstellung und Verwaltung von Partitionen
Nachdem Sie eine partitionierte PostgreSQL-Tabelle erstellt haben, registrieren Sie diese mit `pg_partman`, indem Sie die Funktion `create_parent` aufrufen. Dadurch werden die erforderlichen Partitionen basierend auf den Parametern erstellt, die Sie an die Funktion übergeben.
Die Erweiterung `pg_partman` bietet auch die Funktion `run_maintenance_proc`, die Sie planmäßig aufrufen können, um Partitionen automatisch zu verwalten. Planen Sie, dass diese Funktion regelmäßig (z. B. stündlich) ausgeführt wird, um sicherzustellen, dass die richtigen Partitionen nach Bedarf erstellt werden. Sie können auch sicherstellen, dass Partitionen automatisch gelöscht werden.
## Aktivieren der Erweiterung pg\$1partman
Wenn Sie mehrere Datenbanken innerhalb derselben PostgreSQL-DB-Instance haben, für die Sie Partitionen verwalten möchten, aktivieren Sie die Erweiterung `pg_partman` für jede Datenbank separat. Um die Erweiterung `pg_partman` für eine bestimmte Datenbank zu aktivieren, erstellen Sie das Partitionswartungsschema und dann die Erweiterung `pg_partman` wie folgt:
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**Anmerkung**
Um die Erweiterung `pg_partman` zu erstellen, müssen Sie sicherstellen, dass Sie über `rds_superuser`-Berechtigungen verfügen.
Wenn Sie einen Fehler wie den folgenden erhalten, erteilen Sie dem Konto die Berechtigungen `rds_superuser` oder verwenden Sie Ihr Superuser-Konto.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Um die Berechtigungen `rds_superuser` zu erteilen, verbinden Sie sich mit Ihrem Superuser-Konto und führen Sie den folgenden Befehl aus.
```
GRANT rds_superuser TO user-or-role;
```
Für die Beispiele, die die Verwendung der Erweiterung pg\$1partman zeigen, verwenden wir die folgende Beispieldatenbanktabelle und Partition. Diese Datenbank verwendet eine partitionierte Tabelle basierend auf einem Zeitstempel. Ein `data_mart`-Schema enthält eine Tabelle mit dem Namen `events` mit einer Spalte namens `created_at`. Die folgenden Einstellungen sind in der `events`-Tabelle enthalten:
+ Primärschlüssel `event_id` und `created_at`, die die Spalte zur Führung der Partition verwenden müssen.
+ Eine CHECK-Beschränkung `ck_valid_operation` zum Durchsetzen von Werten für eine `operation`-Tabellenspalte.
+ Zwei Fremdschlüssel, wobei einer `fk_orga_membership)` auf die externe Tabelle `organization` verweist und der andere (`fk_parent_event_id`) ein selbst referenzierter Fremdschlüssel ist.
+ Zwei Indizes, wobei einer (`idx_org_id`) für den Fremdschlüssel und der andere (`idx_event_type`) für den Ereignistyp steht.
Die folgenden DDL-Anweisungen erstellen diese Objekte, die automatisch auf jeder Partition enthalten sind.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Konfigurieren von Partitionen mit der create\$1parent-Funktion
Nachdem Sie die Erweiterung `pg_partman` aktiviert haben, verwenden Sie die `create_parent`-Funktion, um Partitionen innerhalb des Partitionswartungsschemas zu konfigurieren. Im folgenden Beispiel wird das `events`-Tabellenbeispiel verwendet, das in [Aktivieren der Erweiterung pg\$1partmanKonfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion](#PostgreSQL_Partitions.enable) erstellt wurde. Rufen Sie die `create_parent`-Funktion wie folgt auf.
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Dabei werden die folgenden Parameter verwendet:
+ `p_parent_table` – Die übergeordnete partitionierte Tabelle. Diese Tabelle muss bereits existieren und einschließlich des Schemas vollständig qualifiziert sein.
+ `p_control` – Die Spalte, auf der die Partitionierung basieren soll. Der Datentyp muss ganzzahlig oder zeitbasiert sein.
+ `p_type` – Der Typ ist entweder `'range'` oder `'list'`.
+ `p_interval` – Das Zeitintervall oder der Ganzzahlbereich für jede Partition. Beispielwerte sind `1 day`, `1 hour` usw.
+ `p_premake` – Die Anzahl der Partitionen, die im Voraus erstellt werden müssen, um neue Inserts zu unterstützen.
Eine vollständige Beschreibung der Funktion `create_parent` finden Sie in der `pg_partman`-Dokumentation unter [Creation Functions (Erstellungsfunktionen)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions).
## Konfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion
Sie können Partitionswartungsvorgänge ausführen, um automatisch neue Partitionen zu erstellen, Partitionen zu trennen oder alte Partitionen zu entfernen. Die Partitionspflege beruht auf der Funktion `run_maintenance_proc` von der `pg_partman`-Erweiterung und der Erweiterung `pg_cron`, die einen internen Scheduler initiiert. Der `pg_cron`-Scheduler führt automatisch SQL-Anweisungen, -Funktionen und -Prozesse aus, die in Ihren Datenbanken definiert sind.
Im folgenden Beispiel wird das `events`-Tabellenbeispiel verwendet, das in [Aktivieren der Erweiterung pg\$1partmanKonfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion](#PostgreSQL_Partitions.enable) erstellt wurde, um die automatische Ausführung der Partitionswartung festzulegen. Fügen Sie als Voraussetzung `pg_cron` zum Parameter `shared_preload_libraries` in der Parametergruppe der DB-Instance hinzu.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
Im Folgenden finden Sie eine step-by-step Erläuterung des vorangegangenen Beispiels:
1. Ändern Sie die mit Ihrer DB-Instance verknüpfte Parametergruppe und fügen Sie `pg_cron` dem `shared_preload_libraries`-Parameterwert hinzu. Diese Änderung erfordert einen Neustart der DB-Instance, damit sie wirksam wird. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Führen Sie den Befehl `CREATE EXTENSION pg_cron;` mit einem Konto aus, das die `rds_superuser`-Berechtigungen besitzt. Dadurch wird die Erweiterung `pg_cron` aktiviert. Weitere Informationen finden Sie unter [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md).
1. Führen Sie den Befehl `UPDATE partman.part_config` aus, um die `pg_partman`-Einstellungen für die Tabelle `data_mart.events` anzupassen.
1. Führen Sie den Befehl aus `SET` . . . um die `data_mart.events`-Tabelle mit den folgenden Klauseln zu konfigurieren:
1. `infinite_time_partitions = true,` – Konfiguriert die Tabelle so, dass automatisch neue Partitionen ohne Begrenzung erstellt werden können.
1. `retention = '3 months',` – Konfiguriert die Tabelle so, dass sie eine maximale Beibehaltung von drei Monaten hat.
1. `retention_keep_table=true `– Konfiguriert die Tabelle so, dass die Tabelle bei Fälligkeit der Aufbewahrungsfrist nicht automatisch gelöscht wird. Stattdessen werden Partitionen, die älter als die Aufbewahrungsfrist sind, nur von der übergeordneten Tabelle getrennt.
1. Führen Sie den Befehl aus `SELECT cron.schedule` . . . um einen `pg_cron`-Funktionsaufruf zu machen. Dieser Aufruf definiert, wie oft der Scheduler das `pg_partman`-Wartungsverfahren `partman.run_maintenance_proc` ausführt. In diesem Beispiel wird der Prozess stündlich ausgeführt.
Eine vollständige Beschreibung der `run_maintenance_proc`-Funktion finden Sie in der `pg_partman`-Dokumentation unter [Maintenance Functions (Wartungsfunktionen)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions).
# Verwenden von pgAudit zur Protokollierung der Datenbankaktivität
Finanzinstitute, Behörden und viele Branchen müssen *Audit-Protokolle* aufbewahren, um die gesetzlichen Bestimmungen zu erfüllen. Durch die Verwendung der PostgreSQL-Audit-Erweiterung (pgAudit) mit Ihrer DB-Instance von RDS für PostgreSQL können Sie die detaillierten Datensätze erfassen, die normalerweise von Prüfern oder zur Erfüllung gesetzlicher Bestimmungen benötigt werden. Sie können beispielsweise die pgAudit-Erweiterung einrichten, um Änderungen an bestimmten Datenbanken und Tabellen nachzuverfolgen, den Benutzer zu erfassen, der die Änderung vorgenommen hat, und viele andere Details.
Die pgAudit-Erweiterung baut auf der Funktionalität der nativen PostgreSQL-Protokollierungsinfrastruktur auf, indem sie die Protokollmeldungen um Details erweitert. Mit anderen Worten, Sie verwenden für die Anzeige Ihres Audit-Protokolls den gleichen Ansatz wie für die Anzeige von Protokollmeldungen. Weitere Informationen zur PostgreSQL-Protokollierung finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
Die pgAudit-Erweiterung redigiert sensible Daten wie Klartext-Passwörter aus den Protokollen. Wenn Ihre DB-Instance von RDS für PostgreSQL so konfiguriert ist, dass Data Manipulation Language (DML)-Anweisungen protokolliert werden, wie in [Aktivieren der Abfrageprotokollierung für Ihren ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) beschrieben, können Sie das Klartext-Passwortproblem mithilfe der PostgreSQL-Audit-Erweiterung vermeiden.
Sie können das Auditing für Ihre Datenbank-Instances mit einem hohen Grad an Spezifität konfigurieren. Sie können alle Datenbanken und alle Benutzer überprüfen. Sie können auch festlegen, dass nur bestimmte Datenbanken, Benutzer und andere Objekte überprüft werden. Bestimmte Benutzer und Datenbanken können Sie auch explizit von der Prüfung ausschließen. Weitere Informationen finden Sie unter [Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Angesichts der Menge an Details, die erfasst werden können, empfehlen wir, dass Sie bei Verwendung von pgAudit Ihren Speicherverbrauch überwachen.
Die pgAudit-Erweiterung wird von allen verfügbaren Versionen von RDS für PostgreSQL Eine Liste der pgAudit-Versionen, die von verfügbaren Aurora-PostgreSQL-Versionen unterstützt werden, finden Sie unter [Versionen der Erweiterungen für Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) in den *Versionshinweisen für Amazon RDS für PostgreSQL*.
**Topics**
+ [Einrichten der pgAudit-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [Überprüfen von Datenbankobjekten](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [Referenz für die pgAudit-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Einrichten der pgAudit-Erweiterung
Wenn Sie die pgAudit-Erweiterung auf Ihrer DB-Instance von RDS für PostgreSQLIhrem DB-Cluster von Aurora PostgreSQL einrichten möchten, fügen Sie zunächst pgAudit zu den gemeinsam genutzten Bibliotheken in der benutzerdefinierten DB-Parametergruppe für Ihre DB-Instance von RDS für PostgreSQL, hinzu. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Als Nächstes installieren Sie die pgAudit-Erweiterung. Abschließend geben Sie die Datenbanken und Objekte an, die Sie überprüfen möchten. Die Schritte in diesem Abschnitt veranschaulichen die Vorgehensweise. Sie können die AWS-Managementkonsole oder die AWS CLI verwenden.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um alle diese Aufgaben ausführen zu können.
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance von RDS für PostgreSQL einer benutzerdefinierten DB-Parametergruppe zugeordnet ist.
## Konsole
**So richten Sie die pgAudit-Erweiterung ein**
1. Melden Sie sich bei der AWS-Managementkonsole an und ö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 Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre DB-Instance von RDS für PostgreSQL Suchen Sie in den Instance-Details den Link **Parameter group** (Parametergruppe).
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Instance von RDS für PostgreSQL
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den `shared_preload_libraries`-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie `pgaudit` der Liste im Feld **Values** (Werte) hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
![\[Bild des shared_preload_libaries-Parameters mit hinzugefügter pgAudit-Erweiterung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Starten Sie die DB-Instance von RDS für PostgreSQL neu, damit Ihre Änderung des `shared_preload_libraries`-Parameters wirksam wird.
1. Wenn die Instance verfügbar ist, stellen Sie sicher, dass pgAudit initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Wenn pgAudit initialisiert ist, können Sie jetzt die Erweiterung erstellen. Sie müssen die Erweiterung nach dem Initialisieren der Bibliothek erstellen, da die `pgaudit`-Erweiterung Ereignisauslöser für die Überwachung von Data Definition Language (DDL)-Anweisungen installiert.
```
CREATE EXTENSION pgaudit;
```
1. Schließen Sie die `psql`-Sitzung.
```
labdb=> \q
```
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Suchen Sie den `pgaudit.log`-Parameter in der Liste und legen Sie den entsprechenden Wert für Ihren Anwendungsfall fest. Wenn Sie beispielsweise den `pgaudit.log`-Parameter auf `write` festlegen, wie in der folgenden Abbildung gezeigt, werden Einfügungen, Aktualisierungen, Löschungen und einige andere Typänderungen im Protokoll erfasst.
![\[Bild des pgaudit.log-Parameters mit Einstellung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
Sie können auch einen der folgenden Werte für den `pgaudit.log`-Parameter auswählen.
+ „none“: Dies ist der Standardwert. Es werden keine Datenbankänderungen protokolliert.
+ „all“: Es wird alles protokolliert (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes).
+ „ddl“: Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind.
+ „function“: Protokolliert Funktionsaufrufe und `DO`-Blöcke.
+ „misc“: Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`.
+ „read“: Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist.
+ „role“: Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`.
+ „write“: Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist.
1. Wählen Sie **Änderungen speichern ** aus.
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie Ihre DB-Instance von RDS für PostgreSQL aus der Datenbankliste aus.
## AWS CLI
**So richten Sie pgAudit ein**
Wenn Sie pgAudit mit der AWS CLI einrichten möchten, rufen Sie die Operation [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) auf, um die Audit-Protokollparameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie in den folgenden Schritten gezeigt.
1. Verwenden Sie den folgenden AWS CLI-Befehl, um dem `shared_preload_libraries`-Parameter `pgaudit` hinzuzufügen.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgendenAWS CLI Befehl, um die DB-Instance von RDS für PostgreSQL neu zu starten, sodass die pgaudit-Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, können Sie überprüfen, ob `pgaudit` initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Wenn pgAudit initialisiert ist, können Sie jetzt die Erweiterung erstellen.
```
CREATE EXTENSION pgaudit;
```
1. Schließen Sie die `psql`-Sitzung, damit Sie die AWS CLI verwenden können.
```
labdb=> \q
```
1. Verwenden Sie den folgenden AWS CLI-Befehl, um die Anweisungsklassen anzugeben, die von der Sitzungsüberwachungsprotokollierung erfasst werden sollen. Im Beispiel wird der `pgaudit.log`-Parameter auf `write` festgelegt, wodurch Einfügungen, Aktualisierungen und Löschungen im Protokoll erfasst werden.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
Sie können auch einen der folgenden Werte für den `pgaudit.log`-Parameter auswählen.
+ „none“: Dies ist der Standardwert. Es werden keine Datenbankänderungen protokolliert.
+ „all“: Es wird alles protokolliert (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes).
+ „ddl“: Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind.
+ „function“: Protokolliert Funktionsaufrufe und `DO`-Blöcke.
+ „misc“: Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`.
+ „read“: Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist.
+ „role“: Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`.
+ „write“: Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist.
Starten Sie die DB-Instance von RDS für PostgreSQL mit dem folgenden AWS CLI-Befehl neu.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Überprüfen von Datenbankobjekten
Wenn pgAudit auf Ihrer DB-Instance von RDS für PostgreSQL eingerichtet und für Ihre Anforderungen konfiguriert ist, werden detailliertere Informationen im PostgreSQL-Protokoll erfasst. Während die PostgreSQL-Standardprotokollierungskonfiguration beispielsweise das Datum und die Uhrzeit angibt, zu der eine Änderung in einer Datenbanktabelle vorgenommen wurde, kann der Protokolleintrag mit der pgAudit-Erweiterung das Schema, den Benutzer, der die Änderung vorgenommen hat, und andere Details enthalten, je nachdem, wie die Erweiterungsparameter konfiguriert sind. Sie können das Auditing einrichten, um Änderungen wie folgt zu verfolgen.
+ Für jede Sitzung, nach Benutzer. Auf der Sitzungsebene können Sie den vollständig qualifizierten Befehlstext erfassen.
+ Für jedes Objekt, nach Benutzer und nach Datenbank.
Die Objektüberwachungsfunktion wird aktiviert, wenn Sie die `rds_pgaudit`-Rolle in Ihrem System erstellen und diese Rolle dann dem `pgaudit.role`-Parameter in Ihrer benutzerdefinierten Parametergruppe hinzufügen. Standardmäßig ist der `pgaudit.role`-Parameter nicht festgelegt und der einzig zulässige Wert ist `rds_pgaudit`. Bei den folgenden Schritten wird davon ausgegangen, dass `pgaudit` initialisiert wurde und Sie die `pgaudit`-Erweiterung gemäß den Schritten unter [Einrichten der pgAudit-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md) erstellt haben.
![\[Bild der PostgreSQL-Protokolldatei nach dem Einrichten von pgAudit.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Wie in diesem Beispiel gezeigt, enthält die Zeile „LOG: AUDIT: SESSION“ unter anderem Informationen über die Tabelle und deren Schema.
**So richten Sie die Objektüberwachung ein**
1. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Erstellen Sie mithilfe des folgenden Befehls eine Datenbankrolle mit dem Namen `rds_pgaudit`.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Schließen Sie die `psql`-Sitzung.
```
labdb=> \q
```
Verwenden Sie in den nächsten Schritten die AWS CLI, um die Audit-Protokollparameter in Ihrer benutzerdefinierten Parametergruppe zu ändern.
1. Verwenden Sie den folgenden AWS CLI-Befehl, um den `pgaudit.role`-Parameter auf `rds_pgaudit` festzulegen. Standardmäßig ist dieser Parameter leer und der einzig zulässige Wert ist `rds_pgaudit`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Starten Sie die DB-Instance von RDS für PostgreSQL mit dem folgenden AWS CLI-Befehl neu, damit Ihre Änderungen der Parameter wirksam werden.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Führen Sie den folgenden Befehl aus, um zu bestätigen, dass `pgaudit.role` auf `rds_pgaudit` festgelegt ist.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Um die pgAudit-Protokollierung zu testen, können Sie mehrere Beispielbefehle ausführen, die Sie überprüfen möchten. Sie könnten beispielsweise die folgenden Befehle ausführen.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Die Datenbankprotokolle sollten dann einen Eintrag ähnlich dem folgenden enthalten.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Weitere Informationen zur Anzeige der Protokolle finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
Weitere Informationen zur pgAudit-Erweiterung finden Sie unter [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) auf GitHub.
# Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen
Wie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md) beschrieben, verbrauchen PostgreSQL-Protokolle Speicherplatz. Die Verwendung der pgAudit-Erweiterung erhöht die in Ihren Protokollen gesammelte Datenmenge je nach den von Ihnen verfolgten Änderungen in unterschiedlichem Maße. Möglicherweise müssen Sie nicht jeden Benutzer oder jede Datenbank in Ihrem überwachen. DB-Instance von RDS für PostgreSQL
Sie können Benutzer und Datenbanken von der Prüfung ausschließen, um die Auswirkungen auf Ihren Speicher zu minimieren und die unnötige Erfassung von Audit-Datensätzen zu vermeiden. Sie können die Protokollierung auch innerhalb einer bestimmten Sitzung ändern. In den nachstehenden Beispielen wird die Vorgehensweise dazu veranschaulicht.
**Anmerkung**
Parametereinstellungen auf Sitzungsebene haben Vorrang vor den Einstellungen in der benutzerdefinierten DB-Parametergruppe der DB-Instance von RDS für PostgreSQL. Wenn Sie nicht möchten, dass Datenbankbenutzer Ihre Konfigurationseinstellungen für die Audit-Protokollierung umgehen, müssen Sie ihre Berechtigungen ändern.
Angenommen, Ihre DB-Instance von RDS für PostgreSQL ist so konfiguriert, dass derselbe Aktivitätsgrad für alle Benutzer und Datenbanken überprüft wird. Sie entscheiden dann, dass Sie den Benutzer `myuser` nicht überprüfen möchten. Sie können das Auditing für `myuser` mit dem folgenden SQL-Befehl deaktivieren.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Anschließend können Sie die folgende Abfrage verwenden, um die Spalte `user_specific_settings` auf `pgaudit.log` zu überprüfen und zu bestätigen, dass der Parameter auf `NONE` festgelegt ist.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Die Ausgabe sollte folgendermaßen aussehen.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Sie können die Protokollierung für einen bestimmten Benutzer während seiner Datenbanksitzung mit dem folgenden Befehl deaktivieren.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Verwenden Sie die folgende Abfrage, um die Einstellungsspalte für eine bestimmte Benutzer- und Datenbankkombination auf pgaudit.log zu überprüfen.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Die Ausgabe entspricht weitgehend der folgenden.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Nachdem Sie das Auditing für `myuser` deaktiviert haben, entscheiden Sie, dass Sie Änderungen an `mydatabase` nicht verfolgen möchten. Sie können das Auditing für diese spezifische Datenbank mit dem folgenden Befehl deaktivieren.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Verwenden Sie dann die folgende Abfrage, um die Spalte database\$1specific\$1settings zu überprüfen und zu bestätigen, dass pgaudit.log auf NONE festgelegt ist.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Die Ausgabe sollte folgendermaßen aussehen.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Verwenden Sie den folgenden Befehl, um die Einstellungen wieder auf die Standardeinstellung für myuser festzulegen:
```
ALTER USER myuser RESET pgaudit.log;
```
Verwenden Sie den folgenden Befehl, um die Einstellungen wieder auf die Standardeinstellung für eine Datenbank festzulegen.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Verwenden Sie den folgenden Befehl, um Benutzer und Datenbank wieder auf die Standardeinstellung festzulegen.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
Sie können auch bestimmte Ereignisse im Protokoll erfassen, indem Sie `pgaudit.log` auf einen der anderen zulässigen Werte für den `pgaudit.log`-Parameter festlegen. Weitere Informationen finden Sie unter [Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referenz für die pgAudit-Erweiterung
Sie können den gewünschten Detaillierungsgrad für Ihr Audit-Protokoll angeben, indem Sie einen oder mehrere der in diesem Abschnitt aufgeführten Parameter ändern.
## Steuern des pgAudit-Verhaltens
Sie können die Audit-Protokollierung steuern, indem Sie einen oder mehrere der in der folgenden Tabelle aufgeführten Parameter ändern.
| Parameter | Description |
| --- | --- |
| `pgaudit.log` | Gibt die Anweisungsklassen an, die durch die Sitzungs-Audit-Protokollierung erfasst werden. Zulässige Werte sind „ddl“, „function“, „misc“, „read“, „role“, „write“, „none“, „all“. Weitere Informationen finden Sie unter [Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Wenn diese Option aktiviert ist (auf 1 festgelegt), werden Anweisungen zum Audit-Trail hinzugefügt, wenn sich alle Beziehungen in einer Anweisung in pg\$1catalog befinden. |
| `pgaudit.log_level` | Gibt die Protokollstufe an, die für Protokolleinträge verwendet werden soll. Zulässige Werte: „debug5“, „debug4“, „debug3“, „debug2“, „debug1“, „info“, „notice“, „warning“, „log“ |
| `pgaudit.log_parameter` | Wenn diese Option aktiviert ist (auf 1 festgelegt), werden die mit der Anweisung übergebenen Parameter im Audit-Protokoll erfasst. |
| `pgaudit.log_relation` | Wenn diese Option aktiviert ist (auf 1 festgelegt), erstellt das Audit-Protokoll für die Sitzung einen separaten Protokolleintrag für jede Beziehung (TABLE, VIEW usw.), auf die in einer SELECT- oder DML-Anweisung verwiesen wird. |
| `pgaudit.log_statement_once` | Gibt an, ob die Protokollierung den Anweisungstext und die Parameter mit dem ersten Protokolleintrag für eine statement/substatement Kombination oder mit jedem Eintrag enthält. |
| `pgaudit.role` | Gibt die Hauptrolle an, die für die Objektüberwachungsprotokollierung verwendet werden soll. Der einzig zulässige Eintrag ist `rds_pgaudit`. |
## Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter
| Wert | Description |
| --- | --- |
| none | Dies ist die Standardeinstellung. Es werden keine Datenbankänderungen protokolliert. |
| all | Protokolliert alles (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes). |
| ddl | Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind. |
| function | Protokolliert Funktionsaufrufe und `DO`-Blöcke. |
| misc | Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`. |
| read | Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist. |
| role | Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`. |
| Schreib- | Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist. |
Um mehrere Ereignistypen mit der Sitzungsüberwachung zu protokollieren, verwenden Sie eine kommagetrennte Liste. Um alle Ereignistypen zu protokollieren, legen Sie `pgaudit.log` auf `ALL` fest. Starten Sie Ihre DB-Instance neu, um die Änderungen zu übernehmen.
Mit der Objektüberwachung können Sie die Überwachungsprotokollierung verfeinern, um mit bestimmten Beziehungen zu arbeiten. Sie können z. B. angeben, dass Sie eine Audit-Protokollierung für `READ`-Vorgänge in einer oder mehreren Tabellen wünschen.
# Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron
Sie können die PostgreSQL-Erweiterung `pg_cron` verwenden, um Wartungsbefehle innerhalb einer PostgreSQL-Datenbank zu planen. Weitere Informationen zu der Erweiterung finden Sie unter [Was ist pg\$1cron?](https://github.com/citusdata/pg_cron) in der pg\$1cron-Dokumentation.
Die Erweiterung `pg_cron` wird von RDS-PostgreSQL-Engine-Versionen 12.5 und höher unterstützt.
Weitere Informationen zur Verwendung von `pg_cron` finden Sie unter [Planen von Aufträgen mit pg\$1cron auf RDS für PostgreSQL oder Ihren Datenbanken der mit Aurora PostgreSQL kompatiblen Edition](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/).
**Anmerkung**
Die `pg_cron`-Erweiterungsversion wird in der Ansicht „pg\$1available\$1extensions“ als zweistellige Version angezeigt, beispielsweise 1.6. In einigen Kontexten werden möglicherweise dreistellige Versionen aufgeführt, z. B. 1.6.4 oder 1.6.5, Sie müssen jedoch die zweistellige Version angeben, wenn Sie ein Upgrade der Erweiterung durchführen.
**Topics**
+ [Einrichten der pg\$1con-Erweiterung](#PostgreSQL_pg_cron.enable)
+ [Gewähren von Berechtigungen zur Verwendung von pg\$1cron für Datenbankbenutzer](#PostgreSQL_pg_cron.permissions)
+ [Planen von pg\$1cron-Aufträgen](#PostgreSQL_pg_cron.examples)
+ [Referenz für die pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.reference)
## Einrichten der pg\$1con-Erweiterung
Richten Sie die Erweiterung `pg_cron` wie folgt ein:
1. Ändern Sie die benutzerdefinierte Parametergruppe, die mit Ihrer PostgreSQL-DB-Instance verknüpft ist, indem Sie `pg_cron` dem Parameterwert `shared_preload_libraries` hinzufügen.
+ Wenn Ihre DB-Instance von RDS für PostgreSQL den Parameter `rds.allowed_extensions` verwendet, um Erweiterungen, die installiert werden können, explizit aufzulisten, müssen Sie die Erweiterung `pg_cron` in die Liste aufnehmen. Nur bestimmte Versionen von RDS für PostgreSQL unterstützen den Parameter `rds.allowed_extensions`. Standardmäßig sind alle verfügbaren Erweiterungen zulässig. Weitere Informationen finden Sie unter [Beschränkung der Installation von PostgreSQL-Erweiterungen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Starten Sie die PostgreSQL-DB-Instance neu, damit die Änderungen an der Parametergruppe in Kraft treten. Weitere Informationen zum Arbeiten mit Parametergruppen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Nachdem die PostgreSQL-DB-Instance neu gestartet wurde, führen Sie den folgenden Befehl mit einem Konto aus, das über `rds_superuser`-Berechtigungen verfügt. Wenn Sie beispielsweise beim Erstellen Ihrer RDS-for-PostgreSQL-DB-Instance die Standardeinstellungen verwendet haben, verbinden Sie sich als Benutzer `postgres` und erstellen Sie die Erweiterung.
```
CREATE EXTENSION pg_cron;
```
Der Scheduler `pg_cron` ist in der standardmäßigen PostgreSQL-Datenbank mit dem Namen `postgres` festgelegt. Die Objekte `pg_cron` werden in dieser `postgres`-Datenbank erstellt und alle Planungsaktionen werden in dieser Datenbank ausgeführt.
1. Sie können die Standardeinstellungen verwenden oder Aufgaben für die Ausführung in anderen Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance planen. Informationen zum Planen von Aufgaben für andere Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance finden Sie im Beispiel unter [Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank](#PostgreSQL_pg_cron.otherDB).
## Gewähren von Berechtigungen zur Verwendung von pg\$1cron für Datenbankbenutzer
Zum Installieren der Erweiterung `pg_cron` sind `rds_superuser`-Berechtigungen erforderlich. Berechtigungen zur Verwendung von `pg_cron` können anderen Datenbankbenutzern (von einem Mitglied der Gruppe/Rolle `rds_superuser`) gewährt werden, damit diese ihre eigenen Aufträge planen können. Wir empfehlen Ihnen, dem `cron`-Schema Berechtigungen nur nach Bedarf, wenn es die Abläufe in Ihrer Produktionsumgebung verbessert, zu gewähren.
Führen Sie den folgenden Befehl aus, um einem Datenbankbenutzer Berechtigungen im `cron`-Schema zu erteilen:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Dies gibt die *db-user* Erlaubnis, auf das `cron` Schema zuzugreifen, um Cron-Jobs für die Objekte zu planen, für die sie Zugriffsberechtigungen haben. Wenn der Datenbankbenutzer keine Berechtigungen hat, schlägt der Auftrag fehl, nachdem die Fehlermeldung in der `postgresql.log`-Datei angezeigt wurde, wie nachfolgend dargestellt:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
Mit anderen Worten, stellen Sie sicher, dass Datenbankbenutzer, denen Berechtigungen für das `cron`-Schemas gewährt werden, auch über Berechtigungen für die Objekte (Tabellen, Schemas usw.) verfügen, die sie planen wollen.
Die Details des cron-Auftrags und dessen Erfolg oder Misserfolg werden ebenfalls in der Tabelle `cron.job_run_details` erfasst. Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
## Planen von pg\$1cron-Aufträgen
Die folgenden Abschnitte zeigen, wie Sie verschiedene Verwaltungsaufgaben mit `pg_cron`-Aufträgen planen können.
**Anmerkung**
Wenn Sie `pg_cron`-Aufträge erstellen, überprüfen Sie, dass die Einstellung `max_worker_processes` größer ist als die Anzahl von `cron.max_running_jobs`. Ein `pg_cron`-Auftrag schlägt fehl, wenn keine Hintergrund-Workerprozesse ausgeführt werden. Die Standardanzahl von `pg_cron`-Aufträgen ist `5`. Weitere Informationen finden Sie unter [Parameter für die Verwaltung der pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [Bereinigen von Tabellen](#PostgreSQL_pg_cron.vacuum)
+ [Löschen der Verlaufstabelle pg\$1cron](#PostgreSQL_pg_cron.job_run_details)
+ [Protokollieren von Fehlern nur in der Datei postgresql.log](#PostgreSQL_pg_cron.log_run)
+ [Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank](#PostgreSQL_pg_cron.otherDB)
### Bereinigen von Tabellen
Autovacuum übernimmt die Entfernung für die meisten Fälle Möglicherweise möchten Sie jedoch eine Bereinigung für eine bestimmte Tabelle zu einem Zeitpunkt Ihrer Wahl planen.
Weitere Informationen finden Sie auch unter, [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
Es folgt ein Beispiel für die Verwendung der Funktion `cron.schedule` zum Einrichten eines Auftrags, der jeden Tag um 22:00 Uhr (GMT) `VACUUM FREEZE` auf eine bestimmte Tabelle anwenden soll.
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Nachdem das vorangehende Beispiel ausgeführt wurde, können Sie den Verlauf in der `cron.job_run_details`-Tabelle wie folgt überprüfen.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
Nachfolgend finden Sie eine Abfrage der Tabelle `cron.job_run_details`, um fehlgeschlagene Aufträge anzuzeigen.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
### Löschen der Verlaufstabelle pg\$1cron
Die `cron.job_run_details`-Tabelle enthält einen Verlauf von Cron-Aufgaben, die im Laufe der Zeit sehr groß werden können. Wir empfehlen Ihnen, eine Aufgabe zu planen, die diese Tabelle bereinigt. Beispielsweise kann es für die Fehlerbehebung ausreichen, die Eingaben einer Woche beizubehalten.
Im folgenden Beispiel wird die [cron.schedule](#PostgreSQL_pg_cron.schedule)-Funktion verwendet, um eine Aufgabe zu planen, die jeden Tag um Mitternacht ausgeführt wird, um die `cron.job_run_details`-Tabelle zu bereinigen. Die Aufgabe behält nur die letzten sieben Tage. Verwenden Sie Ihr `rds_superuser`-Konto, um die Aufgabe wie folgt zu planen.
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
### Protokollieren von Fehlern nur in der Datei postgresql.log
Wenn Sie verhindern möchten, dass in die `cron.job_run_details`-Tabelle geschrieben wird, ändern Sie die mit der PostgreSQL-DB-Instance verknüpfte Parametergruppe und deaktivieren Sie den Parameter `cron.log_run`. Es werden keine Schreibvorgänge der `pg_cron`-Erweiterung in die Tabelle mehr durchgeführt und nur noch Fehler in der `postgresql.log`-Datei erfasst. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Verwenden Sie den folgenden Befehl, um den Wert des `cron.log_run`-Parameters zu überprüfen.
```
postgres=> SHOW cron.log_run;
```
Weitere Informationen finden Sie unter [Parameter für die Verwaltung der pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.parameters).
### Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank
Die Metadaten für `pg_cron` werden alle in der PostgreSQL-Standarddatenbank mit dem Namen `postgres` gespeichert. Da Hintergrund-Worker für die Ausführung der Maintenance-Cron-Aufgaben verwendet werden, können Sie eine Aufgabe in jeder Ihrer Datenbanken innerhalb der PostgreSQL-DB-Instance planen.
**Anmerkung**
Nur Benutzer mit der Rolle `rds_superuser` oder mit `rds_superuser`-Berechtigungen können alle cron-Aufträge in der Datenbank auflisten. Andere Benutzer können nur ihre eigenen Aufträge in der Tabelle `cron.job` anzeigen.
1. Planen Sie die Aufgabe in der Cron-Datenbank wie gewohnt mit [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Aktualisieren Sie als Benutzer mit der `rds_superuser`-Rolle die Datenbankspalte für die soeben erstellte Aufgabe, damit sie in einer anderen Datenbank innerhalb Ihrer PostgreSQL-DB-Instance ausgeführt wird.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Überprüfen Sie dies, indem Sie die `cron.job`-Tabelle abfragen.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**Anmerkung**
In einigen Fällen können Sie eine Cron-Aufgabe hinzufügen, die Sie in einer anderen Datenbank ausführen möchten. Bevor Sie die richtige Datenbankspalte aktualisieren, versucht die Aufgabe in solchen Fällen möglicherweise, in der Standarddatenbank (`postgres`) ausgeführt zu werden. Wenn der Benutzername über Berechtigungen verfügt, wird die Aufgabe erfolgreich in der Standarddatenbank ausgeführt.
## Referenz für die pg\$1cron-Erweiterung
Sie können die folgenden Parameter, Funktionen und Tabellen mit der `pg_cron`-Erweiterung verwenden. Weitere Informationen finden Sie unter [Was ist pg\$1cron?](https://github.com/citusdata/pg_cron) in der pg\$1cron-Dokumentation.
**Topics**
+ [Parameter für die Verwaltung der pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.parameters)
+ [Funktionsreferenz: cron.schedule](#PostgreSQL_pg_cron.schedule)
+ [Funktionsreferenz: cron.unschedule](#PostgreSQL_pg_cron.unschedule)
+ [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables)
### Parameter für die Verwaltung der pg\$1cron-Erweiterung
Es folgt eine Liste der Parameter zur Steuerung des Erweiterungsverhaltens von `pg_cron`.
| Parameter | Description |
| --- | --- |
| cron.database\$1name | Die Datenbank, in der `pg_cron`-Metadaten aufbewahrt werden. |
| cron.host | Der Hostname für die Verbindung mit PostgreSQL. Dieser Wert kann nicht verändert werden. |
| cron.log\$1run | Protokollieren Sie jeden ausgeführten Auftrag in der Tabelle `job_run_details`. Die Werte sind `on` oder `off`. Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Protokolliert alle Cron-Anweisungen, bevor Sie ausgeführt werden. Die Werte sind `on` oder `off`. |
| cron.max\$1running\$1jobs | Die maximale Anzahl von Aufgaben, die gleichzeitig ausgeführt werden können. |
| cron.use\$1background\$1workers | Verwenden Sie Hintergrund-Worker anstelle von Client-Sitzungen. Dieser Wert kann nicht verändert werden. |
Verwenden Sie den folgenden SQL-Befehl, um diese Parameter und ihre Werte anzuzeigen.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Funktionsreferenz: cron.schedule
Diese Funktion plant eine Cron-Aufgabe. Die Aufgabe ist anfänglich in der `postgres` Standarddatenbank geplant. Die Funktion gibt einen `bigint` Wert zurück, der den Aufgabenbezeichner darstellt. Informationen zum Planen von Aufgaben für die Ausführung in anderen Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance finden Sie im Beispiel unter [Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank](#PostgreSQL_pg_cron.otherDB).
Die Funktion hat zwei Syntaxformate.
**Syntax**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Beispiele**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Funktionsreferenz: cron.unschedule
Diese Funktion löscht eine Cron-Aufgabe. Sie können entweder den `job_name` oder die `job_id` angeben. Eine Richtlinie stellt sicher, dass Sie der Besitzer sind, um den Plan für die Aufgabe zu entfernen. Die Funktion gibt einen Booleschen Wert zurück, der Erfolg oder Misserfolg anzeigt.
Die Funktion weist die folgende Syntax auf.
**Syntax**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Beispiele**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tabellen zum Planen von Jobs und zur Erfassung des Status
Die folgenden Tabellen werden verwendet, um die Cron-Aufgaben zu planen und aufzuzeichnen, wie die Aufgaben abgeschlossen wurden.
| Tabelle | Beschreibung |
| --- | --- |
| cron.job | Enthält die Metadaten zu jeder geplanten Aufgabe. Die meisten Interaktionen mit dieser Tabelle sollten über die Funktionen `cron.schedule` und `cron.unschedule` erfolgen. Wir empfehlen, dieser Tabelle keine Aktualisierungs- oder Einfügeberechtigungen zu gewähren. Dies würde es dem Benutzer ermöglichen, die `username`-Spalte zu aktualisieren, die als `rds-superuser` ausgeführt wird. |
| cron.job\$1run\$1details | Enthält Verlaufsdaten zu vergangenen geplanten Aufträgen, die ausgeführt wurden. Dies ist nützlich, um den Status, die Rückgabe von Nachrichten sowie die Start- und Endzeit des ausgeführten Auftrags zu untersuchen. Um zu verhindern, dass diese Tabelle ins Unendliche wächst, bereinigen Sie sie in regelmäßigen Abständen. Ein Beispiel finden Sie unter [Löschen der Verlaufstabelle pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen die `pglogical`-Erweiterung. Die Erweiterung pglogical ist älter als die funktionell ähnliche logische Replikationsfunktion, die von PostgreSQL in Version 10 eingeführt wurde. Weitere Informationen finden Sie unter [Ausführen der logischen Replikation für Amazon RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
Die `pglogical`-Erweiterung unterstützt die logische Replikation zwischen zwei oder mehr . DB-Instances von RDS für PostgreSQL Es unterstützt auch die Replikation zwischen verschiedenen PostgreSQL-Versionen und zwischen Datenbanken, die auf DB-Instances von RDS für PostgreSQL und DB-Clustern von Aurora PostgreSQL laufen. Die `pglogical`-Erweiterung verwendet ein Publish-Subscribe-Modell, um Änderungen an Tabellen und anderen Objekten, z. B. Sequenzen, von einem Herausgeber auf einen Abonnenten zu replizieren. Sie stützt sich auf einen Replikationsslot, um sicherzustellen, dass Änderungen von einem Herausgeberknoten zu einem Abonnentenknoten synchronisiert werden. Dies ist wie folgt definiert.
+ Der *Herausgeberknoten* ist die DB-Instance von RDS für PostgreSQL, die die Datenquelle ist, die auf andere Knoten repliziert werden soll. Der Herausgeberknoten definiert die Tabellen, die in einem Veröffentlichungssatz repliziert werden sollen.
+ Der *Abonnentenknoten* ist die DB-Instance von RDS für PostgreSQL, die WAL-Updates vom Herausgeber erhält. Der Abonnent erstellt ein Abonnement, um eine Verbindung zum Herausgeber herzustellen und die dekodierten WAL-Daten abzurufen. Wenn der Abonnent das Abonnement erstellt, wird der Replikationsslot auf dem Herausgeberknoten erstellt.
Im Folgenden erfahren Sie, wie Sie die `pglogical`-Erweiterung einrichten.
**Topics**
+ [Anforderungen und Einschränkungen für die pglogical-Erweiterung](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [Einrichten der pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [Einrichten der logischen Replikation für die DB-Instance von RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [Wiederherstellung der logischen Replikation nach einem Hauptversions-Upgrade](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [Verwaltung logischer Replikationsslots für](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [Parameterreferenz für die pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Anforderungen und Einschränkungen für die pglogical-Erweiterung
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen die `pglogical`-Erweiterung.
Sowohl der Herausgeberknoten als auch der Abonnentenknoten müssen für die logische Replikation eingerichtet sein.
Die Tabellen, die Sie vom Publisher zum Subscriber replizieren möchten, müssen dieselben Namen und dasselbe Schema haben. Diese Tabellen müssen außerdem dieselben Spalten enthalten und diese müssen dieselben Datentypen verwenden. Sowohl die Herausgeber- als auch die Abonnententabelle müssen dieselben Primärschlüssel haben. Wir empfehlen, nur den PRIMARY KEY als eindeutige Einschränkung zu verwenden.
Die Tabellen auf dem Abonnentenknoten können für CHECK-Einschränkungen und NOT NULL-Einschränkungen großzügigere Einschränkungen haben als die Tabellen auf dem Herausgeberknoten.
Die `pglogical`-Erweiterung bietet Funktionen wie die bidirektionale Replikation, die von der logischen Replikationsfunktion, die in PostgreSQL (Version 10 und höher) integriert ist, nicht unterstützt werden. Weitere Informationen finden Sie unter [Die bidirektionale PostgreSQL-Replikation mit pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
# Einrichten der pglogical-Erweiterung
Wenn Sie die `pglogical`-Erweiterung auf Ihrer DB-Instance von RDS für PostgreSQL einrichten möchten, fügen Sie zunächst `pglogical` zu den gemeinsam genutzten Bibliotheken in der benutzerdefinierten DB-Parametergruppe für Ihre DB-Instance von RDS für PostgreSQL hinzu. Sie müssen außerdem den Wert des `rds.logical_replication`-Parameters auf `1` festlegen, um die logische Dekodierung zu aktivieren. Abschließend erstellen Sie die Erweiterung in der Datenbank. Sie können das AWS-Managementkonsole oder das AWS CLI für diese Aufgaben verwenden.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um diese Aufgaben ausführen zu können.
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance von RDS für PostgreSQL einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
## Konsole
**So richten Sie die pglogical-Erweiterung ein**
1. Melden Sie sich bei der an AWS-Managementkonsole und ö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 Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre DB-Instance von RDS für PostgreSQL Suchen Sie in den Instance-Details den Link **Parameter group** (Parametergruppe).
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Instance von RDS für PostgreSQL
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den `shared_preload_libraries`-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie `pglogical` der Liste im Feld **Values** (Werte) hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
![\[Bild des shared_preload_libraries-Parameters mit hinzugefügter pglogical-Erweiterung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Suchen Sie den `rds.logical_replication`-Parameter und legen Sie ihn auf `1` fest, um die logische Replikation zu aktivieren.
1. Starten Sie die DB-Instance von RDS für PostgreSQL neu, damit Ihre Änderungen wirksam werden.
1. Wenn die Instance verfügbar ist, können Sie über `psql` (oder pgAdmin) eine Verbindung mit der DB-Instance von RDS für PostgreSQL herstellen.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass pglogical initialisiert ist.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Überprüfen Sie die Einstellung, die die logische Dekodierung ermöglicht, wie folgt.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Erstellen Sie die Erweiterung wie folgt.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Wählen Sie **Änderungen speichern ** aus.
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie aus der Liste der Datenbanken Ihre DB-Instance von RDS für PostgreSQL und dann im Menü „Actions“ (Aktionen) die Option **Reboot** (Neustart) aus.
## AWS CLI
**So richten Sie die pglogical-Erweiterung ein**
Um pglogical mit dem einzurichten AWS CLI, rufen Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)Vorgang auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.
1. Verwenden Sie den folgenden AWS CLI Befehl, um den Parameter `pglogical` zu erweitern. `shared_preload_libraries`
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um auf zu setzen`rds.logical_replication`, `1` um die logische Dekodierungsfunktion für die zu aktivieren. DB-Instance von RDS für PostgreSQL
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um die neu zu starten, sodass die pglogische Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Erstellen Sie die Erweiterung wie folgt.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Starten Sie die for PostgreSQL-DB-Instance mit dem folgenden Befehl neu. AWS CLI
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Einrichten der logischen Replikation für die DB-Instance von RDS für PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Instances von RDS für PostgreSQL starten. Bei den Schritten wird davon ausgegangen, dass sowohl für die Quelle (Herausgeber) als auch für das Ziel (Abonnent) die `pglogical`-Erweiterung eingerichtet wurde, wie unter [Einrichten der pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md) beschrieben.
**Anmerkung**
Der `node_name` eines Subscriber-Knoten kann nicht mit `rds` beginnen.
**So erstellen Sie den Herausgeberknoten und die zu replizierenden Tabellen**
Bei diesen Schritten wird vorausgesetzt, dass Ihre DB-Instance von RDS für PostgreSQL über eine Datenbank mit einer oder mehreren Tabellen verfügt, die Sie auf einen anderen Knoten replizieren möchten. Sie müssen die Tabellenstruktur des Herausgebers für den Abonnenten neu erstellen. Rufen Sie daher bei Bedarf zunächst die Tabellenstruktur ab. Verwenden Sie dazu den `psql`-Metabefehl `\d tablename` und erstellen Sie dann dieselbe Tabelle auf der Abonnenten-Instance. Mit dem folgenden Verfahren wird zu Demonstrationszwecken eine Beispieltabelle für den Herausgeber (Quelle) erstellt.
1. Verwenden Sie `psql`, um eine Verbindung zu der Instance herzustellen, die die Tabelle enthält, die Sie als Quelle für Abonnenten verwenden möchten.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Wenn Sie noch keine vorhandene Tabelle haben, die Sie replizieren möchten, können Sie wie folgt eine Beispieltabelle erstellen.
1. Erstellen Sie mit der folgenden SQL-Anweisung eine Beispieltabelle.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Füllen Sie die Tabelle mit der folgenden SQL-Anweisung mit generierten Daten auf.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Stellen Sie sicher, dass Daten in der Tabelle vorhanden sind, indem Sie die folgende SQL-Anweisung verwenden.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifizieren Sie diese DB-Instance von RDS für PostgreSQL wie folgt als Herausgeberknoten.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Fügen Sie die Tabelle, die Sie replizieren möchten, zum Standardreplikationssatz hinzu. Weitere Informationen zu Replikationssätzen finden Sie unter [Replikationssätze](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) in der Dokumentation zur pglogical-Erweiterung.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
Die Einrichtung des Herausgeberknotens ist abgeschlossen. Sie können jetzt den Abonnentenknoten einrichten, um die Updates vom Herausgeber zu erhalten.
**So richten Sie den Abonnentenknoten ein und erstellen ein Abonnement für den Empfang von Updates**
Bei diesen Schritten wird vorausgesetzt, dass die DB-Instance von RDS für PostgreSQL mit der `pglogical`-Erweiterung eingerichtet wurde. Weitere Informationen finden Sie unter [Einrichten der pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Verwenden Sie `psql`, um sich mit der Instance zu verbinden, die Updates vom Herausgeber erhalten soll.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Erstellen Sie auf der DB-Instance von RDS für PostgreSQL des Abonnenten dieselbe Tabelle, die auf dem Herausgeber vorhanden ist. In diesem Beispiel heißt die Tabelle `docs_lab_table`. Sie können die Tabelle wie folgt erstellen.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Stellen Sie sicher, dass diese Tabelle leer ist.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifizieren Sie diese DB-Instance von RDS für PostgreSQL wie folgt als Abonnentenknoten.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Erstellen Sie das Abonnement.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Wenn Sie diesen Schritt abschließen, werden die Daten aus der Tabelle des Herausgeberknotens in der Tabelle auf dem Abonnentenknoten erstellt. Mit der folgenden SQL-Abfrage können Sie überprüfen, ob dies der Fall ist.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
Ab diesem Zeitpunkt werden Änderungen, die an der Tabelle auf dem Herausgeberknoten vorgenommen wurden, auf die Tabelle auf dem Abonnentenknoten repliziert.
# Wiederherstellung der logischen Replikation nach einem Hauptversions-Upgrade
Bevor Sie ein Hauptversions-Upgrade einer DB-Instance von RDS für PostgreSQL durchführen können, die als Herausgeberknoten für die logische Replikation eingerichtet ist, müssen Sie alle Replikationsslots einschließlich der Slots löschen, die nicht aktiv sind. Wir empfehlen, Datenbanktransaktionen vorübergehend vom Herausgeberknoten umzuleiten, die Replikationsslots zu löschen, die DB-Instance von RDS für PostgreSQL zu aktualisieren und dann die Replikation erneut einzurichten und neu zu starten.
Die Replikationsslots werden nur auf dem Herausgeberknoten gehostet. Der Abonnentenknoten von RDS für PostgreSQL hat in einem logischen Replikationsszenario keine Slots, die gelöscht werden könnten. Er kann jedoch nicht auf eine Hauptversion aktualisiert werden, solange er als Abonnentenknoten mit einem Abonnement beim Herausgeber vorgesehen ist. Bevor Sie den Abonnentenknoten von RDS für PostgreSQL aktualisieren, löschen Sie das Abonnement und den Knoten. Weitere Informationen finden Sie unter [Verwaltung logischer Replikationsslots für ](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Feststellen, dass die logische Replikation unterbrochen wurde
Sie können feststellen, ob der Replikationsprozess unterbrochen wurde, indem Sie entweder den Herausgeberknoten oder den Abonnentenknoten wie folgt abfragen.
**So überprüfen Sie den Herausgeberknoten**
+ Verwenden Sie `psql`, um eine Verbindung mit dem Herausgeberknoten herzustellen, und fragen Sie dann die `pg_replication_slots`-Funktion ab. Notieren Sie sich den Wert in der aktiven Spalte. Normalerweise wird `t` (true) zurückgegeben, was bedeutet, dass die Replikation aktiv ist. Wenn die Abfrage `f` (false) zurückgibt, ist dies ein Hinweis darauf, dass die Replikation an den Abonnenten gestoppt wurde.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**So überprüfen Sie den Abonnentenknoten**
Auf dem Abonnentenknoten können Sie den Status der Replikation auf drei verschiedene Arten überprüfen.
+ Suchen Sie in den PostgreSQL-Protokollen auf dem Abonnentenknoten nach Fehlermeldungen. Das Protokoll identifiziert Fehler mit Meldungen, die den Exit-Code 1 enthalten, wie im Folgenden dargestellt.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Fragen Sie die `pg_replication_origin`-Funktion ab. Stellen Sie mithilfe von `psql` eine Verbindung mit der Datenbank auf dem Abonnentenknoten her und fragen Sie die `pg_replication_origin`-Funktion wie folgt ab.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
Die leere Ergebnismenge bedeutet, dass die Replikation unterbrochen wurde. Die Ausgabe sollte normalerweise folgendermaßen aussehen.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Fragen Sie die `pglogical.show_subscription_status`-Funktion wie im folgenden Beispiel veranschaulicht ab.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Diese Ausgabe zeigt, dass die Replikation unterbrochen wurde. Ihr Status lautet `down`. Normalerweise zeigt die Ausgabe den Status `replicating` an.
Wenn Ihr logischer Replikationsprozess unterbrochen wurde, können Sie die Replikation wiederherstellen, indem Sie die folgenden Schritte ausführen.
**So stellen Sie die logische Replikation zwischen Herausgeber- und Abonnentenknoten wieder her**
Um die Replikation wiederherzustellen, trennen Sie zuerst den Abonnenten vom Herausgeberknoten und richten dann das Abonnement erneut ein, wie in diesen Schritten beschrieben.
1. Stellen Sie mit `psql` wie folgt eine Verbindung zum Abonnentenknoten her.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Deaktivieren Sie das Abonnement, indem Sie die `pglogical.alter_subscription_disable`-Funktion verwenden.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Rufen Sie die ID des Herausgeberknotens ab, indem Sie `pg_replication_origin` wie folgt abfragen.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Verwenden Sie die Antwort aus dem vorherigen Schritt mit dem `pg_replication_origin_create`-Befehl, um die ID zuzuweisen, die vom Abonnement verwendet werden kann, wenn es erneut eingerichtet wurde.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Aktivieren Sie das Abonnement, indem Sie seinen Namen mit dem Status `true` übergeben, wie im folgenden Beispiel veranschaulicht.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Prüfen Sie den Status des Knotens. Sein Status sollte `replicating` wie in diesem Beispiel gezeigt lauten.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Überprüfen Sie den Status des Replikationsslots des Abonnenten auf dem Herausgeberknoten. Die `active`-Spalte des Slots sollte den Wert `t` (true) zurückgeben, was darauf hinweist, dass die Replikation wiederhergestellt wurde.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Verwaltung logischer Replikationsslots für
Bevor Sie ein Hauptversions-Upgrade einer DB-Instance von RDS für PostgreSQL durchführen können, die als Herausgeberknoten in einem logischen Replikationsszenario eingerichtet ist, müssen Sie alle Replikationsslots auf der Instance löschen. Bei der Vorabüberprüfung des Hauptversions-Upgrades werden Sie darüber informiert, dass das Upgrade erst fortgesetzt werden kann, wenn die Slots gelöscht wurden.
Um Slots aus Ihrer DB-Instance von RDS für PostgreSQL zu entfernen, löschen Sie zuerst das Abonnement und dann den Slot.
Um Replikationsslots zu identifizieren, die mit der `pglogical`-Erweiterung erstellt wurden, melden Sie sich bei jeder Datenbank an und rufen Sie die Namen der Knoten ab. Wenn Sie den Abonnentenknoten abfragen, erhalten Sie in der Ausgabe sowohl den Herausgeber- als auch den Abonnentenknoten, wie in diesem Beispiel gezeigt.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Die Details zum Abonnement erhalten Sie mit der folgenden Abfrage.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Sie können das Abonnement jetzt wie folgt kündigen.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Nachdem Sie das Abonnement gekündigt haben, können Sie den Knoten löschen.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Sie können wie folgt überprüfen, dass der Knoten nicht mehr existiert.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Parameterreferenz für die pglogical-Erweiterung
In der Tabelle finden Sie Parameter, die der `pglogical`-Erweiterung zugeordnet sind. Parameter wie `pglogical.conflict_log_level` und `pglogical.conflict_resolution` werden verwendet, um Aktualisierungskonflikte zu beheben. Konflikte können auftreten, wenn Änderungen lokal an denselben Tabellen vorgenommen werden, die Änderungen vom Herausgeber abonniert haben. Konflikte können auch in verschiedenen Szenarien auftreten, z. B. bei der bidirektionalen Replikation oder wenn mehrere Abonnenten vom selben Herausgeber replizieren. Weitere Informationen finden Sie unter [Die bidirektionale PostgreSQL-Replikation mit pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
| Parameter | Description |
| --- | --- |
| pglogical.batch\$1inserts | Batch-Inserts wenn möglich Standardmäßig nicht festgelegt. In '1' ändern zum Einschalten, in '0' zum Ausschalten. |
| pglogical.conflict\$1log\$1level | Legt die Protokollstufe für die Protokollierung gelöster Konflikte fest. Unterstützte Zeichenfolgenwerte sind debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Legt die Methode fest, die verwendet werden soll, um Konflikte zu lösen, die lösbar sind. Unterstützte Zeichenfolgenwerte sind error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Verbindungsoptionen zum Hinzufügen zu allen Peer-Knotenverbindungen |
| pglogical.synchronous\$1commit | Spezifischer synchroner Commit-Wert für pglogical |
| pglogical.use\$1spi | Verwenden Sie zum Anwenden von Änderungen SPI (Server Programming Interface) anstelle der Low-Level-API. In '1' ändern zum Einschalten, in '0' zum Ausschalten. Weitere Informationen zu SPI finden Sie unter [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) in der PostgreSQL-Dokumentation. |
# Verwenden von „pgactive“ zur Unterstützung der Aktiv-Aktiv-Replikation
Die Erweiterung „`pgactive`“ verwendet Aktiv-Aktiv-Replikation, um Schreibvorgänge auf mehreren RDS-für-PostgreSQL-Datenbanken zu unterstützen und zu koordinieren. Die Erweiterung `pgactive` wird auf Amazon RDS für PostgreSQL für die folgenden Versionen unterstützt:
+ RDS für PostgreSQL 17.0 und alle höheren Versionen
+ RDS für PostgreSQL 16.1 und höhere 16-Versionen
+ RDS für PostgreSQL 15.4-R2 und höhere 15-Versionen
+ RDS für PostgreSQL 14.10 und höhere 14-Versionen
+ RDS für PostgreSQL 13.13 und höhere 13-Versionen
+ RDS für PostgreSQL 12.17 und höhere 12-Versionen
+ RDS für PostgreSQL 11.22
**Anmerkung**
Wenn in einer Replikationskonfiguration Schreibvorgänge für mehr als eine Datenbank ausgeführt werden, sind Konflikte möglich. Weitere Informationen finden Sie unter [Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md).
**Topics**
+ [Einschränkungen für die pgactive-Erweiterung](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [Initialisierung der „pgactive“-Erweiterungsfunktion](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [Einrichten der Aktiv-Aktiv-Replikation für die DB-Instances von RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [Messen der Replikationsverzögerung zwischen pgactive-Mitgliedern](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [Konfigurieren von Parametereinstellungen für die pgactive-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [Grundlegendes zu active-active-Konflikten](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [Verstehen des pgactive-Schemas](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [Referenz für pgactive-Funktionen](pgactive-functions-reference.md)
+ [Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Einschränkungen für die pgactive-Erweiterung
+ Alle Tabellen benötigen einen Primärschlüssel, andernfalls sind Aktualisierungen und Löschungen nicht zulässig. Die Werte in der Spalte „Primärschlüssel“ sollten nicht aktualisiert werden.
+ Sequenzen können Lücken aufweisen und manchmal keine bestimmte Reihenfolge beachten. Sequenzen werden nicht repliziert. Weitere Informationen finden Sie unter [Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ DDL und große Objekte werden nicht repliziert.
+ Sekundäre eindeutige Indizes können zu Datendivergenzen führen.
+ Die Sortierung muss auf allen Knoten in der Gruppe identisch sein.
+ Das Load Balancing zwischen den Knoten ist ein Anti-Muster.
+ Große Transaktionen können zu Verzögerungen bei der Replikation führen.
# Initialisierung der „pgactive“-Erweiterungsfunktion
Um die Erweiterungsfunktion „`pgactive`“ auf Ihrer RDS-für-PostgreSQL-DB-Instance zu initialisieren, setzen Sie den Wert des Parameters „`rds.enable_pgactive`“ auf `1` und erstellen Sie dann die Erweiterung in der Datenbank. Dadurch werden die Parameter „`rds.logical_replication`“ und „`track_commit_timestamp`“ automatisch aktiviert und der Wert von `wal_level` wird auf `logical` festgelegt.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um diese Aufgaben ausführen zu können.
Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um den erforderlichen RDS für PostgreSQL-DB-Instances zu erstellen. Bei den folgenden Schritten wird davon ausgegangen, dass Ihre RDS-für-PostgreSQL-DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Informationen zum Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
## Konsole
**So initialisieren Sie die „pgactive“-Erweiterungsfunktion**
1. Melden Sie sich bei der an AWS-Managementkonsole und ö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 Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre RDS-für-PostgreSQL-DB-Instance. Suchen Sie in den Instance-Details nach dem Link **DB-Instance-Parametergruppe**.
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer RDS-für-PostgreSQL-DB-Instance zugeordnet sind.
1. Suchen Sie den Parameter „`rds.enable_pgactive`“ und setzen Sie ihn auf „`1`“, um die „`pgactive`“-Funktion zu initialisieren.
1. Wählen Sie **Änderungen speichern ** aus.
1. Wählen Sie im Navigationsbereich der Amazon-RDS-Konsole die Option **Databases** (Datenbanken) aus.
1. Wählen Sie Ihre RDS-für-PostgreSQL-DB-Instance aus und wählen Sie dann im Menü **Aktionen** die Option **Neustart** aus.
1. Bestätigen Sie den Neustart der DB-Instance, damit die Änderungen in Kraft treten.
1. Wenn die DB-Instance verfügbar ist, können Sie „`psql`“ oder einen anderen PostgreSQL-Client nutzen, um eine Verbindung mit der RDS-für-PostgreSQL-DB-Instance herzustellen.
Im folgenden Beispiel wird davon ausgegangen, dass Ihre RDS for PostgreSQL-DB-Instance eine Standarddatenbank mit dem Namen hat. *postgres*
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass „pgactive“ initialisiert ist.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Wenn „`pgactive`“ in `shared_preload_libraries` ist, gibt der vorherige Befehl Folgendes zurück:
```
?column?
----------
t
```
## AWS CLI
**So initialisieren Sie die „pgactive“-Erweiterungsfunktion**
Um das `pgactive` mit dem zu initialisieren AWS CLI, rufen Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)Vorgang auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.
1. Verwenden Sie den folgenden AWS CLI Befehl, `rds.enable_pgactive` `1` um die `pgactive` Funktion für die RDS for PostgreSQL-DB-Instance zu initialisieren.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um die RDS for PostgreSQL-DB-Instance neu zu starten, sodass die `pgactive` Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass „pgactive“ initialisiert ist.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Wenn „`pgactive`“ in `shared_preload_libraries` ist, gibt der vorherige Befehl Folgendes zurück:
```
?column?
----------
t
```
# Einrichten der Aktiv-Aktiv-Replikation für die DB-Instances von RDS für PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Instances von RDS für PostgreSQL starten, wobei `pgactive` verfügbar ist. Um das Beispiel für hohe Verfügbarkeit in mehreren Regionen auszuführen, müssen Sie Instances von Amazon RDS für PostgreSQL in zwei verschiedenen Regionen bereitstellen und VPC-Peering einrichten. Weitere Informationen finden Sie unter [VPC-Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**Anmerkung**
Beim Senden von Datenverkehr zwischen mehreren Regionen können zusätzliche Kosten anfallen.
Bei diesen Schritten wird vorausgesetzt, dass die DB-Instance von RDS für PostgreSQL mit der `pgactive`-Erweiterung eingerichtet wurde. Weitere Informationen finden Sie unter [Initialisierung der „pgactive“-Erweiterungsfunktion](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**So konfigurieren Sie die erste DB-Instance von RDS für PostgreSQL mit der „`pgactive`“-Erweiterung**
Das folgende Beispiel zeigt, wie die „`pgactive`“-Gruppe erstellt wird, sowie weitere Schritte, die erforderlich sind, um die „`pgactive`“-Erweiterung auf der RDS-für-PostgreSQL-DB-Instance zu erstellen.
1. Verwenden Sie `psql` oder ein anderes Client-Tool, um eine Verbindung zu Ihrer ersten DB-Instance von RDS für PostgreSQL herzustellen.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der RDS-für-PostgreSQL-Instance:
```
postgres=> CREATE DATABASE app;
```
1. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:
```
\c app
```
1. Erstellen Sie mit den folgenden SQL-Anweisungen eine Beispieltabelle.
1. Erstellen Sie mit der folgenden SQL-Anweisung eine Beispieltabelle.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Füllen Sie die Tabelle mit der folgenden SQL-Anweisung mit Beispieldaten auf.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Stellen Sie sicher, dass Daten in der Tabelle vorhanden sind, indem Sie die folgende SQL-Anweisung verwenden.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Erstellen Sie eine „`pgactive`“-Erweiterung für die bestehende Datenbank.
```
app=> CREATE EXTENSION pgactive;
```
1. Erstellen und initialisieren Sie die Gruppe „pgactive“ mit den folgenden Befehlen:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Jetzt können Sie die Replikationsgruppe initialisieren und diese erste Instance hinzufügen:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Verwenden Sie die folgenden Befehle als alternative, aber weniger sichere Methode, um die pgactive-Gruppe zu erstellen und zu initialisieren:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app ist der Name, den Sie vergeben, um einen Knoten in der „`pgactive`“-Gruppe eindeutig zu identifizieren.
**Anmerkung**
Um diesen Schritt erfolgreich auf einer DB-Instance durchzuführen, auf die öffentlich zugegriffen werden kann, müssen Sie den Parameter „`rds.custom_dns_resolution`“ aktivieren, indem Sie ihn auf `1` setzen.
1. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die DB-Instance bereit ist:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen die folgende Ausgabe angezeigt:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**So konfigurieren Sie die zweite RDS-für-PostgreSQL-Instance und fügen sie der „`pgactive`“-Gruppe hinzu**
Das folgende Beispiel zeigt, wie Sie eine RDS-für-PostgreSQL-DB-Instance mit der „`pgactive`“-Gruppe verbinden können, sowie weitere Schritte, die zum Erstellen der „`pgactive`“-Erweiterung auf der DB-Instance erforderlich sind.
Bei diesen Schritten wird vorausgesetzt, dass andere DB-Instances von RDS für PostgreSQL mit der „`pgactive`“-Erweiterung eingerichtet wurde(n). Weitere Informationen finden Sie unter [Initialisierung der „pgactive“-Erweiterungsfunktion](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Verwenden Sie `psql`, um sich mit der Instance zu verbinden, die Updates vom Herausgeber erhalten soll.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der zweiten RDS-für-PostgreSQL-Instance:
```
postgres=> CREATE DATABASE app;
```
1. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:
```
\c app
```
1. Erstellen Sie die „`pgactive`“-Erweiterung für die bestehende Datenbank.
```
app=> CREATE EXTENSION pgactive;
```
1. Fügen Sie der „`pgactive`“-Gruppe die zweite DB-Instance von RDS für PostgreSQL mit den folgenden Befehlen hinzu:
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Verwenden Sie die folgenden Befehle als alternative, aber weniger sichere Methode, um der `pgactive`-Gruppe den die zweite DB-Instance von RDS für PostgreSQL hinzuzufügen.
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app ist der Name, den Sie vergeben, um einen Knoten in der „`pgactive`“-Gruppe eindeutig zu identifizieren.
1. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die DB-Instance bereit ist:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen die folgende Ausgabe angezeigt:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Wenn die erste RDS-für-PostgreSQL-Datenbank relativ groß ist, können Sie sehen, dass `pgactive.pgactive_wait_for_node_ready()` den Fortschrittsbericht des Wiederherstellungsvorgangs ausgibt. Die Ausgabe sieht folgendermaßen oder ähnlich aus:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Ab diesem Zeitpunkt werden die Daten zwischen den beiden DB-Instances durch „`pgactive`“ synchronisiert.
1. Sie können den folgenden Befehl verwenden, um zu überprüfen, ob die Datenbank der zweiten DB-Instance die Daten enthält:
```
app=> SELECT count(*) FROM inventory.products;
```
Wenn die Daten erfolgreich synchronisiert wurden, sehen Sie die folgende Ausgabe:
```
count
-------
3
```
1. Führen Sie den folgenden Befehl aus, um neue Werte einzufügen:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Stellen Sie eine Verbindung zur Datenbank der ersten DB-Instance her und führen Sie die folgende Abfrage aus:
```
app=> SELECT count(*) FROM inventory.products;
```
Wenn die Aktiv-Aktiv-Replikation initialisiert ist, sieht die Ausgabe ungefähr wie folgt aus:
```
count
-------
4
```
**So trennen Sie eine DB-Instance von der „`pgactive`“-Gruppe und entfernen Sie daraus**
Sie können eine DB-Instance mit den folgenden Schritten von der „`pgactive`“-Gruppe trennen und daraus entfernen:
1. Sie können die zweite DB-Instance mit dem folgenden Befehl von der ersten DB-Instance trennen:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Entfernen Sie die „`pgactive`“-Erweiterung mit dem folgenden Befehl aus der zweiten DB-Instance:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
So erzwingen Sie die Entfernung der Erweiterung:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Löschen Sie die Erweiterung mit dem folgenden Befehl:
```
app=> DROP EXTENSION pgactive;
```
# Messen der Replikationsverzögerung zwischen pgactive-Mitgliedern
Sie können die folgende Abfrage verwenden, um die Replikationsverzögerung zwischen den `pgactive`-Mitgliedern anzuzeigen. Führen Sie diese Abfrage auf jedem `pgactive`- Knoten aus, um sich ein vollständiges Bild zu machen.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Überwachen Sie mindestens die folgenden Diagnosen:
aktiv
Richten Sie Benachrichtigungen ein, wenn „active“ den Wert „false“ hat, was darauf hinweist, dass der Slot derzeit nicht verwendet wird (die Abonnenten-Instance hat die Verbindung zum Publisher getrennt).
pending\$1wal\$1decoding
Bei der logischen Replikation von PostgreSQL werden WAL-Dateien im Binärformat gespeichert. Der Publisher muss diese WAL-Änderungen dekodieren und in logische Änderungen umwandeln (z. B. Einfüge-, Aktualisierungs- oder Löschvorgänge).
Die Metrik „pending\$1wal\$1decoding“ zeigt die Anzahl der WAL-Dateien, die auf der Publisher-Seite darauf warten, dekodiert zu werden.
Diese Zahl kann aufgrund der folgenden Faktoren steigen:
+ Wenn der Abonnent nicht verbunden ist, wird der Status „Aktiv“ auf „Falsch“ gesetzt und der Wert „pending\$1wal\$1decoding“ wird erhöht
+ Der Slot ist aktiv, aber der Publisher kann mit der Menge der WAL-Änderungen nicht Schritt halten
pending\$1wal\$1to\$1apply
Die Metrik „pending\$1wal\$1apply“ gibt die Anzahl der WAL-Dateien an, die auf Abonnentenseite darauf warten, angewendet zu werden.
Verschiedene Faktoren können verhindern, dass der Abonnent Änderungen vornimmt, und möglicherweise zum Szenario einer vollen Festplatte führen:
+ Schemaunterschiede – Wenn beispielsweise Änderungen im WAL-Stream für eine Tabelle mit dem Namen „sample“ vorliegen, diese Tabelle auf der Abonnentenseite jedoch nicht vorhanden ist.
+ Die Werte in den Primärschlüsselspalten wurden aktualisiert.
+ Sekundäre eindeutige Indizes können zu Datendivergenzen führen.
# Konfigurieren von Parametereinstellungen für die pgactive-Erweiterung
Sie können die folgende Abfrage verwenden, um alle mit der „`pgactive`“-Erweiterung verknüpften Parameter anzuzeigen.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Sie können die `pgactive`-Erweiterung mit verschiedenen Parametern konfigurieren. Diese Parameter können entweder über die AWS-Managementkonsole oder die AWS CLI-Schnittstelle eingestellt werden.
## Wichtigste pgactive-Erweiterungsparameter
Die folgende Tabelle enthält eine Referenz für die Hauptparameter der `pgactive`-Erweiterung:
| Parameter | Einheit | Standard | Description |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Protokolliert vollständige Tupel-Informationen für die `pgactive`-Erweiterung. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Legt fest, ob die `pgactive`-Erweiterung die erkannten Konflikte in der `pgactive.pgactive_conflict_history`-Tabelle protokolliert. Weitere Informationen finden Sie unter „Konfliktprotokollierung“. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Legt fest, ob die `pgactive`-Erweiterung die erkannten Konflikte in der PostgreSQL-Protokolldatei protokolliert. Weitere Informationen finden Sie unter „Konfliktprotokollierung“. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.synchronous\$1commit | `boolean` | aus | Bestimmt das Commit-Verhalten für „pgactive apply“-Worker. Wenn diese Option deaktiviert (aus) ist, führen apply-Worker asynchrone Commits durch. Dadurch wird der PostgreSQL-Durchsatz bei Apply-Vorgängen verbessert, die Wiederholungsbestätigungen an den Upstream werden jedoch verzögert. Die Einstellung auf `off` ist immer sicher und führt nicht zum Verlust oder Überspringen von Transaktionen. Diese Einstellung wirkt sich nur auf den Zeitpunkt der Festplattenleerungen auf dem Downstream-Knoten und darauf aus, wann Bestätigungen upstream gesendet werden. Das System verzögert das Senden von Replay-Flush-Bestätigungen, bis Commits durch unabhängige Vorgänge wie Checkpoints oder regelmäßige Aufgaben auf die Festplatte geschrieben werden. Wenn im Upstream-Bereich jedoch der Downstream unter `synchronous_standby_names` aufgeführt ist, führt die Einstellung auf `off` dazu, dass synchrone Commits auf dem Upstream länger brauchen, bis sie dem Client erfolgreich gemeldet werden. In diesem Fall legen Sie den Parameter auf `on` fest. Selbst wenn dieser Parameter auf `on` mit aufgelisteten Knoten unter `synchronous_standby_names` festgelegt ist, können Replikationskonflikte in active-active-Konfigurationen weiterhin auftreten. Das liegt daran, dass dem System das Sperren zwischen den Knoten und das globale Snapshot-Management fehlen, sodass gleichzeitige Transaktionen auf verschiedenen Knoten dasselbe Tupel ändern können. Darüber hinaus beginnen Transaktionen erst mit der Replikation, nachdem sie auf dem Upstream-Knoten festgeschrieben wurden. Durch die Aktivierung eines synchronen Commits wird die pgactive-Erweiterung nicht in ein stets konsistentes System transformiert. |
| pgactive.temp\$1dump\$1directory | `string` | – | Definiert den temporären Speicherpfad, der für das Klonen von Datenbanken bei der Ersteinrichtung erforderlich ist. Dieses Verzeichnis muss für den Postgres-Benutzer beschreibbar sein und über ausreichend Speicherplatz für einen vollständigen Datenbank-Dump verfügen. Das System verwendet diesen Speicherort nur bei der Ersteinrichtung der Datenbank mit logischen Kopiervorgängen. Dieser Parameter wird nicht von `pgactive_init_copy command` verwendet. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Gibt die maximale Wartezeit für die DDL-Sperre an, bevor gleichzeitige Schreibtransaktionen erzwungen werden. Der Standardwert ist `-1`, der den in `max_standby_streaming_delay` eingestellten Wert übernimmt. Dieser Parameter akzeptiert Zeiteinheiten. Sie können ihn beispielsweise für 10 Sekunden auf 10 Sekunden einstellen. Während dieser Wartezeit versucht das System, DDL-Sperren zu erhalten, während es darauf wartet, dass laufende Schreibtransaktionen entweder festgeschrieben oder rückgängig gemacht werden. Weitere Informationen finden Sie unter „DDL-Sperren“. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Gibt an, wie lange ein DDL-Sperrversuch darauf wartet, die Sperre zu erhalten. Der Standardwert ist `-1`, der den in lock\$1timeout angegebenen Wert verwendet. Sie können diesen Parameter in Zeiteinheiten wie 10s für 10 Sekunden festlegen. Dieser Timer steuert nur die Wartezeit für den Erhalt einer DDL-Sperre. Sobald das System die Sperre erhält und den DDL-Vorgang startet, stoppt der Timer. Dieser Parameter begrenzt weder die Gesamtdauer, für die eine DDL-Sperre aufrechterhalten werden kann, noch die gesamte DDL-Betriebszeit. Um die Gesamtdauer des Vorgangs zu steuern, verwenden Sie stattdessen `statement_timeout`. Weitere Informationen finden Sie unter „DDL-Sperren“. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Setzt die standardmäßige Debug-Protokollebene für DDL-Sperrvorgänge in der `pgactive`-Erweiterung außer Kraft.- Wenn diese Einstellung konfiguriert ist, werden Meldungen im Zusammenhang mit DDL-Sperren auf der LOG-Debug-Ebene statt auf ihrer Standardebene ausgegeben. Verwenden Sie diesen Parameter, um DDL-Sperraktivität zu überwachen, ohne die ausführlichen Protokollebenen `DEBUG1` oder `DEBUG2` Protokollebenen auf Ihrem gesamten Server zu aktivieren. Verfügbare Protokollebenen, in aufsteigender Reihenfolge der Ausführlichkeit: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Weitere Informationen zu Überwachungsoptionen finden Sie unter „Überwachen globaler DDL-Sperren“. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
## Zusätzliche pgactive-Erweiterungsparameter
Die folgende Tabelle enthält weniger häufig verwendete und interne Konfigurationsoptionen, die für die `pgactive`-Erweiterung verfügbar sind.
| Parameter | Einheit | Standard | Description |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Legt eine Anwendungsverzögerung (in Millisekunden) für konfigurierte Verbindungen fest, deren `pgactive.pgactive_connections`-Eintrag keine explizite Anwendungsverzögerung enthält. Diese Verzögerung wird während der Knotenerstellung oder der Verbindungszeit festgelegt, und pgactive gibt eine Transaktion auf Peer-Knoten erst dann wieder, wenn mindestens die angegebene Anzahl von Millisekunden seit dem Festschreiben vergangen ist. Wird in erster Linie verwendet, um Netzwerke mit hoher Latenz in Testumgebungen zu simulieren, um das Erzeugen von Konflikten zu vereinfachen. Beispiel: Bei einer Verzögerung von 500 ms auf den Knoten A und B haben Sie nach dem Einfügen eines Werts auf Knoten A mindestens 500 ms Zeit, um eine widersprüchliche Einfügung auf Knoten B durchzuführen. Erfordert ein erneutes Laden des Servers oder einen Neustart der apply-Worker, um wirksam zu werden. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Gibt die Dauer (in Sekunden) an, für die ein Datenbank-Worker versucht, während fehlgeschlagener Versuche Verbindungen herzustellen. Der Worker unternimmt einen Verbindungsversuch pro Sekunde, bis er erfolgreich ist oder diesen Timeout-Wert erreicht. Diese Einstellung ist hilfreich, wenn die Datenbank-Engine gestartet wird, bevor der Worker bereit ist, Verbindungen herzustellen. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Steuert, wie DDL-Änderungen in Amazon RDS repliziert oder verarbeitet werden, wenn `pgactive` aktiviert ist. Wenn diese Option auf `on` festgelegt ist, verarbeitet der Knoten DDL-Änderungen wie ein Nicht-pgactive-Knoten. Die folgenden Anforderungen gelten bei der Verwendung dieses Parameters: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Sie können diesen Parameter mit Superuser-Berechtigungen auf zwei Arten ändern: global, lokal (Sitzungsebene). Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Dieser Parameter ist nur für die interne Verwendung vorgesehen. Wenn Sie diesen Parameter in einer Transaktion festlegen, werden die Änderungen nicht auf andere Knoten in Ihrem DB-Cluster repliziert. Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Dieser Parameter ist nur für die Verwendung durch Spezialisten vorgesehen. Es wird empfohlen, diesen Parameter nur zur Behebung bestimmter Replikationsprobleme zu verwenden. Verwenden Sie diesen Parameter in folgenden Fällen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Diese Einstellung überschreibt die folgende Fehlermeldung und ermöglicht Datendivergenzen, sodass die Replikation fortgesetzt werden kann: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Wenn dieser Wert auf `on` festgelegt ist, wird für jede Remote-Aktion, die nachgeschaltete apply-Worker verarbeiten, eine Protokollmeldung ausgegeben. Zu den Protokollen gehören: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) In den Protokollen werden auch DDL-Befehle und Tabellenabbrüche in der Warteschlange erfasst.para> Standardmäßig enthalten die Protokolle keine Zeilenfeldinhalte. Um Zeilenwerte in die Protokolle aufzunehmen, müssen Sie bei der Neukompilierung die folgenden Flags aktiviert haben: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Die Aktivierung dieser Protokollierungseinstellung kann sich auf die Leistung auswirken. Wir empfehlen, sie nur zu aktivieren, wenn sie zur Fehlerbehebung benötigt wird. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Sie können Verbindungsparameter für alle Peer-Knotenverbindungen mit pgactive-Knoten konfigurieren. Diese Parameter steuern Einstellungen wie Keepalives und SSL-Modi. Standardmäßig verwendet pgactive die folgenden Verbindungsparameter: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Verwenden Sie den folgenden ähnlichen Befehl, um die Standardparameter zu überschreiben: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Verbindungszeichenfolgen für einzelne Knoten haben Vorrang vor diesen Einstellungen und den integrierten Verbindungsoptionen von pgactive. Weitere Informationen zu Formaten für Verbindungszeichenfolgen finden Sie unter [libpq-Verbindungszeichenfolgen](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Wir empfehlen, die Keepalive-Standardeinstellungen aktiviert zu lassen. Deaktivieren Sie Keepalives nur, wenn Sie Probleme mit großen Transaktionen haben, die über unzuverlässige Netzwerke abgeschlossen werden. Wir empfehlen, die Keepalive-Standardeinstellungen aktiviert zu lassen. Deaktivieren Sie Keepalives nur, wenn Sie Probleme mit großen Transaktionen haben, die über unzuverlässige Netzwerke abgeschlossen werden. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Gibt die Anzahl der parallelen Aufträge an, die `pg_dump` und `pg_restore` bei logischen Knotenverbindungen mit der Funktion `pgactive.pgactive_join_group` verwenden können. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.max\$1nodes | `int` | 4 | Gibt die maximal zulässige Anzahl von Knoten in einer pgactive-Erweiterungsgruppe an. Der Standardwert beträgt 4 Knoten. Sie müssen die folgenden Punkte berücksichtigen, wenn Sie den Wert dieses Parameters festlegen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Sie können diesen Parameter auf zwei Arten festlegen: in der Konfigurationsdatei mit dem Befehl `ALTER SYSTEM SET` Der Standardwert für diesen Parameter ist `4`, was bedeutet, dass zu jedem Zeitpunkt maximal 4 Knoten in der `pgactive`-Erweiterungsgruppe zulässig sind. Die Änderung wird wirksam, nachdem Sie den Server neu gestartet haben. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Dieser Parameter ist nur für die interne Verwendung vorgesehen. Wenn er aktiviert ist, ermöglicht die `pgactive`-Erweiterung die Erstellung der Getter-Funktion für die pgactive-Knoten-ID. |
# Grundlegendes zu active-active-Konflikten
Wenn Sie pgactive im active-active-Modus verwenden, kann das Schreiben in dieselben Tabellen über mehrere Knoten zu Datenkonflikten führen. Während einige Clustering-Systeme verteilte Sperren verwenden, um gleichzeitigen Zugriff zu verhindern, verfolgt pgactive einen optimistischen Ansatz, der sich besser für geografisch verteilte Anwendungen eignet.
Einige Clustering-Systeme von Datenbanken verhindern den gleichzeitigen Datenzugriff mithilfe von verteilten Sperren. Dieser Ansatz funktioniert zwar, wenn sich Server in unmittelbarer Nähe befinden, unterstützt jedoch keine geografisch verteilten Anwendungen, da er für eine gute Leistung eine extrem geringe Latenz erfordert. Anstelle von verteilten Sperren (ein pessimistischer Ansatz) verwendet die pgactive-Erweiterung einen optimistischen Ansatz. Das heißt:
+ Sie hilft Ihnen, Konflikte nach Möglichkeit zu vermeiden.
+ Sie lässt das Auftreten bestimmter Arten von Konflikten zu.
+ Sie stellt Konfliktlösungen bereit, wenn Konflikte auftreten.
Dieser Ansatz bietet Ihnen mehr Flexibilität beim Erstellen verteilter Anwendungen.
## So entstehen Konflikte
Konflikte zwischen Knoten entstehen durch Abfolgen von Ereignissen, die nicht auftreten könnten, wenn alle beteiligten Transaktionen gleichzeitig auf demselben Knoten stattfinden würden. Da die Knoten Änderungen erst nach dem Festschreiben von Transaktionen austauschen, ist jede Transaktion einzeln auf dem Knoten gültig, auf dem sie festgeschrieben wurde. Sie wäre jedoch nicht gültig, wenn sie auf einem anderen Knoten ausgeführt würde, der in der Zwischenzeit andere Aufgaben durchgeführt hat. Da „pgactive apply“ die Transaktion im Wesentlichen auf den anderen Knoten wiedergibt, kann der Wiedergabevorgang fehlschlagen, wenn ein Konflikt zwischen einer angewendeten Transaktion und einer Transaktion besteht, die auf dem Empfängerknoten festgeschrieben wurde.
Der Grund dafür, dass die meisten Konflikte nicht auftreten können, wenn alle Transaktionen auf einem einzigen Knoten ausgeführt werden, besteht darin, dass PostgreSQL über Kommunikationsmechanismen zwischen Transaktionen verfügt, um dies zu verhindern. Hierzu zählen die folgenden:
+ UNIQUE-Indizes
+ SEQUENCEs
+ Sperren von Zeilen und Beziehungen
+ Nachverfolgung von SERIALIZABLE-Abhängigkeiten
All diese Mechanismen sind Möglichkeiten der Kommunikation zwischen Transaktionen zur Vermeidung unerwünschter Parallelitätsprobleme.
pgactive erreicht eine niedrige Latenz und verarbeitet Netzwerkpartitionen gut, da es keinen verteilten Transaktionsmanager oder Sperrmanager verwendet. Dies bedeutet jedoch, dass Transaktionen auf verschiedenen Knoten völlig isoliert voneinander ausgeführt werden. Während die Isolierung in der Regel zu einer Verbesserung der Datenbankkonsistenz beiträgt, müssen Sie sie in diesem Fall reduzieren, um Konflikte zu vermeiden.
## Typen von Konflikten
Zu den möglichen Konflikten gehören:
**Topics**
+ [PRIMARY KEY- oder UNIQUE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [INSERT/INSERT-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [INSERTs die gegen mehrere UNIQUE-Einschränkungen verstoßen](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [UPDATE/UPDATE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [UPDATE-Konflikte beim PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [UPDATEs die gegen mehrere UNIQUE-Einschränkungen verstoßen](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [UPDATE/DELETE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [INSERT/UPDATE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [DELETE/DELETE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [Konflikte bei Fremdschlüsseleinschränkungen](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [Konflikte bei Ausschlusseinschränkungen](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [Konflikte bei globalen Daten](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [Sperrkonflikte und Deadlock-Abbrüche](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [Divergierende Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### PRIMARY KEY- oder UNIQUE-Konflikte
Zeilenkonflikte treten auf, wenn mehrere Vorgänge versuchen, denselben Zeilenschlüssel auf eine Weise zu ändern, die auf einem einzelnen Knoten nicht möglich ist. Diese Konflikte stellen den häufigsten Typ von Datenkonflikten dar.
pgactive löst erkannte Konflikte durch last-update-wins Handling oder Ihren benutzerdefinierten Konflikthandler.
Zu den Zeilenkonflikten gehören:
+ INSERT vs. INSERT
+ INSERT vs. UPDATE
+ UPDATE vs. DELETE
+ INSERT vs. DELETE
+ DELETE vs. DELETE
+ INSERT vs. DELETE
### INSERT/INSERT-Konflikte
Dieser häufigste Konflikt tritt auf, wenn INSERTs auf zwei verschiedenen Knoten ein Tupel mit denselben PRIMARY KEY-Werten (oder identischen UNIQUE-Einschränkungswerten, wenn kein PRIMARY KEY existiert) erstellt wird.
pgactivelink löst INSERT-Konflikte, indem es den Zeitstempel des ursprünglichen Hosts verwendet, um das neueste Tupel beizubehalten. Sie können dieses Standardverhalten mit dem benutzerdefinierten Konflikt-Handler außer Kraft setzen. Dieser Prozess erfordert zwar keine spezielle Administratoraktion, beachten Sie jedoch, dass pgactivelink einen der INSERT-Vorgänge auf allen Knoten verwirft. Es findet keine automatische Datenzusammenführung statt, es sei denn, der benutzerdefinierte Handler implementiert sie.
pgactivelink kann nur Konflikte lösen, die eine einzelne Einschränkungsverletzung betreffen. Wenn ein INSERT-Vorgang gegen mehrere UNIQUE-Einschränkungen verstößt, müssen Sie zusätzliche Strategien zur Konfliktlösung implementieren.
### INSERTs die gegen mehrere UNIQUE-Einschränkungen verstoßen
Ein INSERT/INSERT Konflikt kann mehrere UNIQUE-Einschränkungen verletzen, einschließlich des PRIMÄRSCHLÜSSEL. pgactivelink kann nur Konflikte behandeln, die eine einzige UNIQUE-Einschränkung beinhalten. Wenn Konflikte mehrere UNIQUE-Einschränkungen verletzen, schlägt der Apply-Worker fehl und gibt den folgenden Fehler zurück:
`multiple unique constraints violated by remotely INSERTed tuple.`
In älteren Versionen führte diese Situation stattdessen zu dem Fehler „diverging uniqueness conflict“.
Um diese Konflikte zu lösen, müssen Sie manuelle Maßnahmen ergreifen. Führen Sie für die widersprüchlichen lokalen Tupel entweder einen DELETE- oder einen UPDATE-Vorgang durch, um Konflikte mit dem neuen Remote-Tupel zu beseitigen. Beachten Sie, dass Sie möglicherweise mehrere in Konflikt stehende Tupel beheben müssen. Derzeit stellt pgactivelink keine integrierten Funktionen zum Ignorieren, Verwerfen oder Zusammenführen von Tupeln bereit, die gegen mehrere eindeutige Einschränkungen verstoßen.
**Anmerkung**
Weitere Informationen finden Sie unter Verstöße gegen mehrere UPDATEs UNIQUE-Einschränkungen.
### UPDATE/UPDATE-Konflikte
Dieser Konflikt tritt auf, wenn zwei Knoten gleichzeitig dasselbe Tupel ändern, ohne seinen PRIMÄRSCHLÜSSEL zu ändern. pgactivelink löst diese Konflikte mithilfe von last-update-wins Logik oder Ihrem benutzerdefinierten Konflikthandler, falls definiert. Ein PRIMARY KEY ist für den Tupel-Abgleich und die Konfliktlösung unerlässlich. Für Tabellen ohne PRIMARY KEY lehnt pgactivelink UPDATE-Vorgänge mit dem folgenden Fehler ab:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### UPDATE-Konflikte beim PRIMARY KEY
Für pgactive gelten Einschränkungen beim Verarbeiten von PRIMARY KEY-Aktualisierungen. Sie können zwar eine UPDATE-Operation für einen PRIMÄRSCHLÜSSEL ausführen, aber pgactive kann Konflikte nicht automatisch mithilfe der Logik für diese Operationen lösen. last-update-wins Sie müssen sicherstellen, dass die PRIMARY KEY-Aktualisierungen nicht mit vorhandenen Werten in Konflikt stehen. Wenn während der PRIMARY KEY-Aktualisierungen Konflikte auftreten, werden diese zu divergierenden Konflikten, die Ihr manuelles Eingreifen erfordern. Weitere Informationen zum Umgang mit diesen Situationen finden Sie unter [Divergierende Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs die gegen mehrere UNIQUE-Einschränkungen verstoßen
pgactivelink kann keine last-update-wins Konfliktlösung anwenden, wenn ein eingehendes UPDATE gegen mehrere UNIQUE-Einschränkungen oder PRIMARY KEY-Werte verstößt. Dieses Verhalten entspricht INSERT-Vorgängen mit mehreren Einschränkungsverstößen. Diese Situationen führen zu divergierenden Konflikten, die Ihr manuelles Eingreifen erfordern. Weitere Informationen finden Sie unter [Divergierende Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATE/DELETE-Konflikte
Diese Konflikte treten auf, wenn UPDATEs ein Knoten eine Zeile und ein anderer Knoten gleichzeitig gleichzeitig vorhanden ist. DELETEs In diesem Fall tritt bei der Wiedergabe ein UPDATE/DELETE Konflikt auf. Die Lösung besteht darin, alle nach einem DELETE-Vorgang eingehenden UPDATE-Vorgänge zu verwerfen, sofern der benutzerdefinierte Konflikt-Handler nichts anderes angibt.
pgactivelink erfordert einen PRIMARY KEY, um Tupel abzugleichen und Konflikte zu lösen. Für Tabellen ohne PRIMARY KEY lehnt pgactivelink UPDATE-Vorgänge mit dem folgenden Fehler ab:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**Anmerkung**
pgactivelink kann nicht zwischen und Konflikten unterscheiden. UPDATE/DELETE INSERT/UPDATE In beiden Fällen wirkt sich ein UPDATE-Vorgang auf eine nicht vorhandene Zeile aus. Aufgrund der asynchronen Replikation und der fehlenden Reihenfolge der Wiederholung zwischen den Knoten kann pgactivelink nicht feststellen, ob der UPDATE-Vorgang für eine neue Zeile (INSERT noch nicht empfangen) oder für eine gelöschte Zeile gilt. In beiden Szenarien wird der UPDATE-Vorgang von pgactivelink verworfen.
### INSERT/UPDATE-Konflikte
Dieser Konflikt kann in Umgebungen mit mehreren Knoten auftreten. Es passiert, wenn INSERTs ein Knoten eine Zeile, ein zweiter Knoten UPDATEs sie und ein dritter Knoten das UPDATE vor dem ursprünglichen INSERT empfängt. Standardmäßig löst pgactivelink diese Konflikte, indem es den UPDATE-Vorgang verwirft, sofern der benutzerdefinierte Konflikt-Trigger nichts anderes angibt. Beachten Sie, dass diese Lösungsmethode zu Dateninkonsistenzen zwischen den Knoten führen kann. Weitere Informationen zu ähnlichen Szenarien und deren Handhabung finden Sie unter [UPDATE/DELETE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### DELETE/DELETE-Konflikte
Dieser Konflikt tritt auf, wenn zwei verschiedene Knoten gleichzeitig dasselbe Tupel löschen. pgactivelink betrachtet diese Konflikte als harmlos, da das Endergebnis beider DELETE-Vorgänge identisch ist. In diesem Szenario ignoriert pgactivelink sicher einen der DELETE-Vorgänge, ohne die Datenkonsistenz zu beeinträchtigen.
### Konflikte bei Fremdschlüsseleinschränkungen
FOREIGN KEY-Einschränkungen können zu Konflikten führen, wenn Remote-Transaktionen auf vorhandene lokale Daten angewendet werden. Diese Konflikte treten in der Regel auf, wenn Transaktionen in einer anderen Reihenfolge als in ihrer logischen Reihenfolge auf die Ursprungsknoten angewendet werden.
Standardmäßig wendet pgactive Änderungen mit session\$1replication\$1role als `replica` an, wodurch Fremdschlüsselprüfungen während der Replikation umgangen werden. In active-active-Konfigurationen kann dies zu Verstößen bei Fremdschlüsseln führen. Die meisten Verstöße sind vorübergehend und werden behoben, sobald die Replikation abgeschlossen ist. Es können jedoch hängende Fremdschlüssel auftreten, da pgactive das knotenübergreifende Sperren von Zeilen nicht unterstützt.
Dieses Verhalten ist partitionstoleranten asynchronen active-active-Systemen inhärent. Beispielsweise kann Knoten A eine neue untergeordnete Zeile einfügen und Knoten B gleichzeitig seine übergeordnete Zeile löschen. Das System kann diese Art der gleichzeitigen knotenübergreifenden Änderung nicht verhindern.
Zur Minimierung von Fremdschlüsselkonflikten wird Folgendes empfohlen:
+ Beschränken Sie Fremdschlüsselbeziehungen auf eng verwandte Entitäten.
+ Ändern Sie verwandte Entitäten, wenn möglich, über einen einzigen Knoten.
+ Wählen Sie Entitäten aus, die selten geändert werden müssen.
+ Implementieren Sie die Parallelitätssteuerung auf Anwendungsebene für Änderungen.
### Konflikte bei Ausschlusseinschränkungen
pgactivelink unterstützt keine Ausschlusseinschränkungen und beschränkt deren Erstellung.
**Anmerkung**
Wenn Sie eine vorhandene eigenständige Datenbank in eine pgactivelink-Datenbank konvertieren, löschen Sie manuell alle Ausschlussbeschränkungen.
In einem verteilten asynchronen System lässt sich nicht gewährleisten, dass kein Satz von Zeilen gegen die Einschränkung verstößt. Dies liegt daran, dass alle Transaktionen auf verschiedenen Knoten vollständig isoliert sind. Ausschlusseinschränkungen können zu Deadlocks bei der Wiederholung führen, sodass die Wiederholung aufgrund von Verstößen gegen Ausschlusseinschränkungen nicht von einem Knoten zum anderen fortgesetzt werden kann.
Wenn Sie pgactivelink zwingen, eine Ausschlusseinschränkung zu erstellen, oder wenn Sie beim Konvertieren einer eigenständigen Datenbank in pgactivelink vorhandene Einschränkungen nicht löschen, führt dies möglicherweise zu einer Unterbrechung der Replikation. Um den Replikationsfortschritt wiederherzustellen, entfernen oder ändern Sie die lokalen Tupel, die mit einem eingehenden Remote-Tupel in Konflikt stehen, sodass die Remote-Transaktion angewendet werden kann.
### Konflikte bei globalen Daten
Bei der Verwendung von pgactivelink können Konflikte auftreten, wenn Knoten unterschiedliche globale systemweite PostgreSQL-Daten wie beispielsweise Rollen aufweisen. Diese Konflikte können dazu führen, dass Vorgänge – in erster Linie DDL – auf einem Knoten erfolgreich ausgeführt und festgeschrieben, jedoch nicht auf andere Knoten angewendet werden.
Wenn ein Benutzer auf einem Knoten vorhanden ist, auf einem anderen jedoch nicht, können Replikationsprobleme auftreten:
+ Node1 verfügt über einen Benutzer namens `fred`, der jedoch nicht auf Node2 vorhanden ist.
+ Wenn `fred` eine Tabelle auf Node1 erstellt, wird die Tabelle mit `fred` als Eigentümer repliziert.
+ Wenn dieser DDL-Befehl auf Node2 angewendet wird, schlägt er fehl, da der Benutzer `fred` nicht vorhanden ist.
+ Dieser Fehler generiert einen ERROR in den PostgreSQL-Protokollen auf Node2 und erhöht den Zähler `pgactive.pgactive_stats.nr_rollbacks`.
**Lösung:** Erstellen Sie den Benutzer `fred` auf Node2. Der Benutzer benötigt keine identischen Berechtigungen, sondern muss auf beiden Knoten vorhanden sein.
Wenn eine Tabelle auf einem Knoten vorhanden ist, auf einem anderen jedoch nicht, schlagen Datenänderungsvorgänge fehl:
+ Node1 verfügt über eine Tabelle mit dem Namen `foo`, die auf Node2 nicht vorhanden ist.
+ Alle DML-Vorgänge in der Tabelle `foo` auf Node1 schlagen fehl, wenn sie auf Node2 repliziert werden.
**Lösung:** Erstellen Sie die Tabelle `foo` auf Node2 mit derselben Struktur.
**Anmerkung**
pgactivelink repliziert derzeit keine CREATE USER-Befehle oder DDL-Vorgänge. Die DDL-Replikation ist für eine zukünftige Version geplant.
### Sperrkonflikte und Deadlock-Abbrüche
Da „pgactive apply“-Prozesse wie normale Benutzersitzungen funktionieren, folgen sie den Standardregeln für das Sperren von Zeilen und Tabellen. Dies kann dazu führen, dass „pgactive apply“-Prozesse auf Sperren warten, die von Benutzertransaktionen oder anderen apply-Prozessen gehalten werden.
Die folgenden Typen von Sperren können sich auf apply-Prozesse auswirken:
+ Explizites Sperren auf Tabellenebene (LOCK TABLE...) durch Benutzersitzungen
+ Explizites Sperren auf Zeilenebene (SELECT... FOR UPDATE/FOR SHARE) nach Benutzersitzungen
+ Sperren mit Fremdschlüsseln
+ Implizites Sperren aufgrund von Zeilen UPDATEs, INSERTs, oder DELETEs, entweder aufgrund lokaler Aktivitäten oder aufgrund von Anwendungen von anderen Servern
Deadlocks können auftreten zwischen
+ einem „pgactivelink apply“-Prozess und einer Benutzertransaktion,
+ zwei apply-Prozessen.
Wenn Deadlocks auftreten, beendet Deadlock Detector von PostgreSQL eine der problematischen Transaktionen. Wenn der Prozess des „pgactivelink apply“-Workers beendet wird, versucht er es automatisch erneut, was in der Regel erfolgreich ist.
**Anmerkung**
Diese Probleme sind vorübergehend und erfordern im Allgemeinen kein Eingreifen des Administrators. Wenn ein apply-Prozess durch die Sperre einer inaktiven Benutzersitzung für einen längeren Zeitraum blockiert wird, können Sie die Benutzersitzung beenden, um die Replikation fortzusetzen. Diese Situation ähnelt einer Situation, in der ein Benutzer eine lange Sperre hält, die sich auf eine andere Benutzersitzung auswirkt.
Um Verzögerungen bei der Wiederholung im Zusammenhang mit Sperren zu identifizieren, aktivieren Sie die Funktion `log_lock_waits` in PostgreSQL.
### Divergierende Konflikte
Divergierende Konflikte treten auf, wenn Daten, die knotenübergreifend identisch sein sollten, unerwartet voneinander abweichen. Obwohl diese Konflikte nicht auftreten sollten, können Sie in der aktuellen Implementierung nicht alle zuverlässig verhindert werden.
**Anmerkung**
Das Ändern des PRIMARY KEY einer Zeile kann zu unterschiedlichen Konflikten führen, wenn ein anderer Knoten den Schlüssel derselben Zeile ändert, bevor alle Knoten die Änderung verarbeiten. Vermeiden Sie es, Primärschlüssel zu ändern, oder beschränken Sie Änderungen auf einen bestimmten Knoten. Weitere Informationen finden Sie unter [UPDATE-Konflikte beim PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Divergierende Konflikte, die Zeilendaten betreffen, erfordern in der Regel ein Eingreifen des Administrators. Um diese Konflikte zu lösen, müssen Sie die Daten auf einem Knoten manuell so anpassen, dass sie mit denen eines anderen Knotens übereinstimmen, und gleichzeitig die Replikation mit `pgactive.pgactive_do_not_replicate` vorübergehend deaktivieren. Diese Konflikte sollten nicht auftreten, wenn Sie pgactive wie dokumentiert verwenden und Einstellungen oder Funktionen vermeiden, die als unsicher markiert sind.
Als Administrator müssen Sie diese Konflikte manuell lösen. Je nach Konflikttyp ist die Verwendung erweiterter Optionen wie `pgactive.pgactive_do_not_replicate` erforderlich. Nutzen Sie diese Optionen mit Vorsicht, da sich die Situation durch eine unsachgemäße Verwendung verschlechtern kann. Aufgrund der Vielzahl möglicher Konflikte können wir keine allgemeingültigen Lösungsansätze bereitstellen.
Divergierende Konflikte treten auf, wenn Daten, die auf verschiedenen Knoten identisch sein sollten, unerwartet voneinander abweichen. Obwohl diese Konflikte nicht auftreten sollten, können Sie in der aktuellen Implementierung nicht alle zuverlässig verhindert werden.
## Vermeiden oder Tolerieren von Konflikten
In den meisten Fällen können Sie ein geeignetes Anwendungsdesign verwenden, um Konflikte zu vermeiden oder die Anwendung konflikttolerant zu gestalten.
Konflikte treten nur auf, wenn Vorgänge auf mehreren Knoten gleichzeitig ausgeführt werden. So vermeiden Sie Konflikte:
+ Schreiben Sie nur in einen Knoten.
+ Schreiben Sie in unabhängige Datenbankuntergruppen auf jedem Knoten (weisen Sie beispielsweise jedem Knoten ein separates Schema zu).
Verwenden Sie bei „INSERT vs. INSERT“-Konflikten globale Sequenzen, um Konflikte vollständig zu vermeiden.
Wenn Konflikte für Ihren Anwendungsfall nicht akzeptabel sind, sollten Sie die Implementierung verteilter Sperren auf Anwendungsebene erwägen. Häufig ist es am besten, die Anwendung so zu gestalten, dass sie mit den Konfliktlösungsmechanismen von pgactive funktioniert, anstatt zu versuchen, alle Konflikte zu vermeiden. Weitere Informationen finden Sie unter [Typen von Konflikten](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Protokollierung von Konflikten
pgactivelink protokolliert Konfliktvorfälle in der Tabelle `pgactive.pgactive_conflict_history`, um Sie bei der Diagnose und Behandlung von active-active-Konflikten zu unterstützen. Die Konfliktprotokollierung in dieser Tabelle erfolgt nur, wenn Sie `pgactive.log_conflicts_to_table` auf „true“ festlegen. Die pgactive-Erweiterung protokolliert Konflikte auch dann in der PostgreSQL-Protokolldatei, wenn log\$1min\$1messages auf `LOG` oder `lower` festgelegt ist, und zwar unabhängig von der Einstellung `pgactive.log_conflicts_to_table`.
Verwenden Sie die Konfliktverlaufstabelle, um die folgenden Schritte auszuführen:
+ Messen, wie häufig die Anwendung Konflikte verursacht
+ Identifizieren, wo Konflikte auftreten
+ Verbessern der Anwendung zur Reduzierung der Konfliktrate
+ Erkennen von Fällen, in denen Konfliktlösungen nicht zu den gewünschten Ergebnissen führen
+ Ermitteln, wo benutzerdefinierte Konfliktauslöser oder Änderungen am Anwendungsdesign benötigt werden
Bei Zeilenkonflikten können Sie optional Zeilenwerte protokollieren. Dies wird durch die Einstellung `pgactive.log_conflicts_to_table` gesteuert. Beachten Sie Folgendes:
+ Dies ist eine globale datenbankweite Option.
+ Es gibt keine tabellenbezogene Kontrolle über die Protokollierung von Zeilenwerten.
+ Für Feldnummern, Array-Elemente oder Feldlängen gelten keine Beschränkungen.
+ Die Aktivierung dieser Funktion ist möglicherweise nicht ratsam, wenn Sie mit Zeilen mit mehreren Megabyte arbeiten, die Konflikte auslösen können.
Da die Konfliktverlaufstabelle Daten aus jeder Tabelle in der Datenbank (jede mit potenziell unterschiedlichen Schemas) enthält, werden protokollierte Zeilenwerte als JSON-Felder gespeichert. Die JSON-Datei wird mit `row_to_json` erstellt, ähnlich wie beim direkten Aufruf aus SQL. PostgreSQL bietet keine `json_to_row` Funktion, daher benötigen Sie tabellenspezifischen Code (in usw.)PL/pgSQL, PL/Python, PL/Perl, um ein zusammengesetztes Tupel aus dem protokollierten JSON zu rekonstruieren.
**Anmerkung**
Die Unterstützung für benutzerdefinierte Konflikte ist als zukünftige Erweiterungsfunktion geplant.
# Verstehen des pgactive-Schemas
Das pgactive-Schema verwaltet die Active-Active-Replikation in RDS für PostgreSQL. Dieses Schema enthält Tabellen, in denen die Replikationskonfiguration und Statusinformationen gespeichert werden.
**Anmerkung**
Das pgactive-Schema entwickelt sich weiter und kann geändert werden. Ändern Sie die Daten in diesen Tabellen nicht direkt.
Zu den wichtigsten Tabellen im pgactive-Schema gehören:
+ `pgactive_nodes` – Speichert Informationen über Knoten in der aktiv-aktiven Replikationsgruppe.
+ `pgactive_connections` – Speichert Verbindungsdetails für jeden Knoten.
## pgactive\$1nodes
Die Datei „pgactive\$1nodes“ speichert Informationen zu den Knoten, die an der active-active-Replikationsgruppe teilnehmen.
| Spalte | Typ | Kollation | NULLABLE | Standard |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | nicht NULL | – |
| node\$1timeline | oid | – | nicht NULL | – |
| node\$1dboid | oid | – | nicht NULL | – |
| node\$1status | char | – | nicht NULL | – |
| node\$1name | text | – | nicht NULL | – |
| knoten\$1dsn | text | – | nicht NULL | – |
| node\$1init\$1from\$1dsn | text | – | nicht NULL | – |
| node\$1read\$1only | boolesch | – | – | false |
| node\$1seq\$1id | smallint | – | nicht NULL | – |
**node\$1sysid**
Eindeutige ID für einen Knoten, generiert während `pgactive_create_group` oder `pgactive_join_group`
**node\$1status**
Bereitschaft des Knotens:
+ **b** – Beginn der Einrichtung
+ **i** – wird initialisiert
+ **c** – catchup
+ **o** – Outbound-Slots erstellen
+ **r** – bereit
+ **k** – beendet
Diese Spalte gibt nicht an, ob ein Knoten verbunden oder getrennt ist.
**node\$1name**
Vom Benutzer bereitgestellter eindeutiger Knotenname
**knoten\$1dsn**
Verbindungszeichenfolge oder Name der Benutzerzuordnung
**node\$1init\$1from\$1dsn**
DSN, aus dem dieser Knoten erstellt wurde.
## pgactive\$1connection
Die pgactive\$1connections speichert Verbindungsdetails für jeden Knoten.
| Spalte | Typ | Kollation | NULLABLE | Standard |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | Keine | nicht NULL | Keine |
| conn\$1timeline | oid | Keine | nicht NULL | Keine |
| conn\$1dboid | oid | Keine | nicht NULL | Keine |
| conn\$1dsn | text | Keine | nicht NULL | Keine |
| conn\$1apply\$1delay | Ganzzahl | Keine | Keine | Keine |
| conn\$1replication\$1sets | text | Keine | Keine | Keine |
conn\$1sysid
Knoten-ID für den Knoten, auf den sich dieser Eintrag bezieht.
conn\$1dsn
Wie pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Wenn diese Option festgelegt ist, warten Sie Millisekunden, bevor jede Transaktion vom Remote-Knoten angewendet wird. Dient in erster Linie zum Debuggen. Bei Null gilt der globale Standard.
## Arbeiten mit Replikationssätzen
Replikationssätze bestimmen, welche Tabellen in Replikationsvorgänge aufgenommen oder von ihnen ausgeschlossen werden sollen. Standardmäßig werden alle Tabellen repliziert, sofern Sie mit den folgenden Funktionen nichts anderes angeben:
+ `pgactive_exclude_table_replication_set()` – Schließt angegebene Tabellen von der Replikation aus.
+ `pgactive_include_table_replication_set()` – Schließt bestimmte Tabellen in die Replikation ein.
**Anmerkung**
Berücksichtigen Sie Folgendes, bevor Sie Replikationssätze konfigurieren:
Sie können das Ein- oder Ausschließen von Tabellen erst nach der Ausführung von `pgactive_create_group()`, aber vor der Ausführung von `pgactive_join_group()` konfigurieren.
Nachdem Sie `pgactive_exclude_table_replication_set()` verwendet haben, kann `pgactive_include_table_replication_set()` nicht mehr verwendet werden.
Nachdem Sie `pgactive_include_table_replication_set()` verwendet haben, kann `pgactive_exclude_table_replication_set()` nicht mehr verwendet werden.
Das System behandelt neu erstellte Tabellen je nach Ihrer ursprünglichen Konfiguration unterschiedlich:
+ Wenn Sie Tabellen ausgeschlossen haben: Alle neuen Tabellen, die nach `pgactive_join_group()` erstellt wurden, werden automatisch in die Replikation einbezogen.
+ Wenn Sie Tabellen ausgeschlossen haben: Alle neuen Tabellen, die nach `pgactive_join_group()` erstellt wurden, werden automatisch aus der Replikation ausgeschlossen.
Verwenden Sie die Funktion `pgactive.pgactive_get_table_replication_sets()`, um die Replikationssatz-Konfiguration für eine bestimmte Tabelle anzuzeigen.
# Referenz für pgactive-Funktionen
Im Folgenden finden Sie eine Liste der pgactive-Funktionen mit ihren Parametern, Rückgabewerten und praktischen Anwendungshinweisen, die Ihnen dabei helfen, sie effektiv zu verwenden:
## get\$1last\$1applied\$1xact\$1info
Ruft die zuletzt angewendeten Transaktionsinformationen für einen angegebenen Knoten ab.
**Argumente**
+ sysid (Text) - Zeitleisten-OID
+ dboid (OID)
**Rückgabetyp**
Folgende Aktionen werden aufgezeichnet:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (Zeitstempel mit Zeitzone)
+ last\$1applied\$1xact\$1at (Zeitstempel mit Zeitzone)
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die zuletzt angewendeten Transaktionsinformationen für einen bestimmten Knoten abzurufen.
## pgactive\$1apply\$1pause
Hält den Prozess zum Anwenden der Replikation an.
**Argumente**
Keine
**Rückgabetyp**
Boolean
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Prozess zum Anwenden der Replikation anzuhalten.
## pgactive\$1apply\$1resume
Setzt den Prozess zum Anwenden der Replikation fort.
**Argumente**
Keine
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Prozess zum Anwenden der Replikation fortzusetzen.
## pgactive\$1is\$1apply\$1paused
Prüft, ob die Anwendung der Replikation derzeit angehalten wurde.
**Argumente**
Keine
**Rückgabetyp**
Boolean
**Nutzungshinweise**
Verwenden Sie diese Funktion, um zu überprüfen, ob die Anwendung der Replikation derzeit angehalten wurde.
## pgactive\$1create\$1group
Erstellt eine pgactive-Gruppe, indem eine eigenständige Datenbank in den ursprünglichen Knoten konvertiert wird.
**Argumente**
+ node\$1name (Text)
+ node\$1dsn (Text)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Rückgabetyp**
void
**Nutzungshinweise**
Erstellt eine pgactive-Gruppe, indem eine eigenständige Datenbank in den ursprünglichen Knoten konvertiert wird. Die Funktion führt Plausibilitätsprüfungen durch, bevor der Knoten in einen pgactive-Knoten umgewandelt wird. Vergewissern Sie sich vor der Verwendung der Funktion, dass für die PostgreSQL-Cluster eine ausreichende Anzahl von `max_worker_processes` zur Verfügung steht, um die pgactive-Hintergrund-Worker zu unterstützen.
## pgactive\$1detach\$1nodes
Entfernt die angegebenen Knoten aus der pgactive-Gruppe.
**Argumente**
+ p\$1nodes (text[])
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die angegebenen Knoten aus der pgactive-Gruppe zu entfernen.
## pgactive\$1exclude\$1table\$1replication\$1set
Schließt eine bestimmte Tabelle von der Replikation aus.
**Argumente**
+ p\$1relation (regclass)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um eine bestimmte Tabelle von der Replikation auszuschließen.
## pgactive\$1get\$1replication\$1lag\$1info
Ruft detaillierte Informationen zur Replikationsverzögerung ab, einschließlich Knotendetails, WAL-Status und LSN-Werten.
**Argumente**
Keine
**Rückgabetyp**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Ungefähre WAL-Größe in Byte, die auf dem Senderknoten dekodiert werden soll - pending\$1wal\$1to\$1apply bigint - Ungefähre WAL-Größe in Byte, die auf den Empfängerknoten angewendet werden soll - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um Informationen zur Replikationsverzögerung abzurufen, einschließlich Knotendetails, WAL-Status und LSN-Werten.
## pgactive\$1get\$1stats
Ruft pgactive-Replikationsstatistiken ab.
**Argumente**
Keine
**Rückgabetyp**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**Nutzungshinweise**
Verwenden Sie diese Funktion, um pgactive-Replikationsstatistiken abzurufen.
## pgactive\$1get\$1table\$1replication\$1sets
Ruft die Replikationssatzkonfiguration für eine bestimmte Relation ab.
**Argumente**
+ relation (regclass)
**Rückgabetyp**
SETOF-Datensatz
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die Replikationssatzkonfiguration für eine bestimmte Relation abzurufen.
## pgactive\$1include\$1table\$1replication\$1set
Schließt eine bestimmte Tabelle in die Replikation ein.
**Argumente**
+ p\$1relation (regclass)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um eine bestimmte Tabelle in die Replikation einzubeziehen.
## pgactive\$1join\$1group
Fügt einer vorhandenen pgactive-Gruppe einen Knoten hinzu.
**Argumente**
+ node\$1name (Text)
+ node\$1dsn (Text)
+ join\$1using\$1dsn (Text)
+ apply\$1delay (Ganzzahl, optional)
+ replication\$1sets (text[], Standard: ['default'])
+ bypass\$1collation\$1check (boolesch, Standard: false)
+ bypass\$1node\$1identifier\$1creation (boolesch, Standard: false)
+ bypass\$1user\$1tables\$1check (boolesch, Standard: false)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um einer vorhandenen pgactive-Gruppe einen Knoten hinzuzufügen. Vergewissern Sie sich, dass der PostgreSQL-Cluster über eine ausreichende Anzahl von max\$1worker\$1processes für die pgactive-Hintergrund-Worker verfügt.
## pgactive\$1remove
Entfernt alle pgactive-Komponenten vom lokalen Knoten.
**Argumente**
+ force (boolesch, Standard: false)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um alle pgactive-Komponenten vom lokalen Knoten zu entfernen.
## pgactive\$1snowflake\$1id\$1nextval
Generiert knotenspezifische eindeutige Sequenzwerte.
**Argumente**
+ regclass
**Rückgabetyp**
bigint
**Nutzungshinweise**
Verwenden Sie diese Funktion, um knotenspezifische eindeutige Sequenzwerte zu generieren.
## pgactive\$1update\$1node\$1conninfo
Aktualisiert die Verbindungsinformationen für einen pgactive-Knoten.
**Argumente**
+ node\$1name\$1to\$1update (Text)
+ node\$1dsn\$1to\$1update (Text)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die Verbindungsinformationen für einen pgactive-Knoten zu aktualisieren.
## pgactive\$1wait\$1for\$1node\$1ready
Überwacht den Fortschritt der Gruppenerstellung oder der Zusammenführung.
**Argumente**
+ timeout (Ganzzahl, Standard: 0)
+ progress\$1interval (Ganzzahl, Standard: 60)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Fortschritt der Gruppenerstellung oder der Zusammenführung zu überwachen.
# Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation
Die „`pgactive`“-Erweiterung funktioniert pro Datenbank und nicht pro Cluster. Jede DB-Instance, die „`pgactive`“ verwendet, ist eine unabhängige Instance und kann Datenänderungen aus jeder Quelle akzeptieren. Wenn eine Änderung an eine DB-Instance gesendet wird, schreibt PostgreSQL sie lokal fest und repliziert die Änderung dann mithilfe von „`pgactive`“ asynchron auf andere DB-Instances. Wenn zwei PostgreSQL-DB-Instances denselben Datensatz fast zur gleichen Zeit aktualisieren, kann ein Konflikt auftreten.
Die Erweiterung „`pgactive`“ bietet Mechanismen zur Konflikterkennung und automatischen Lösung. Sie verfolgt den Zeitstempel, zu dem die Transaktion auf beiden DB-Instances festgeschrieben wurde, und wendet die Änderung automatisch mit dem neuesten Zeitstempel an. Die Erweiterung „`pgactive`“ protokolliert auch, wenn in der Tabelle `pgactive.pgactive_conflict_history` ein Konflikt auftritt.
`pgactive.pgactive_conflict_history` nimmt zu. Möglicherweise möchten Sie eine Löschrichtlinie definieren. Dies kann erreicht werden, indem Sie regelmäßig einige Datensätze löschen oder ein Partitionierungsschema für diese Beziehung definieren (und später die gewünschten Partitionen trennen, löschen oder kürzen). Um die Löschrichtlinie regelmäßig zu implementieren, besteht eine Möglichkeit darin, die `pg_cron`-Erweiterung zu verwenden. Im Folgenden finden Sie ein Beispiel für die Verlaufstabelle `pg_cron`, [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation
Eine RDS-für-PostgreSQL-DB-Instance mit der Erweiterung „`pgactive`“ verwendet zwei verschiedene Sequenzmechanismen, um eindeutige Werte zu generieren.
**Globale Sequenzen**
Um eine globale Sequenz zu verwenden, erstellen Sie mit der Anweisung `CREATE SEQUENCE` eine lokale Sequenz. Verwenden Sie `pgactive.pgactive_snowflake_id_nextval(seqname)` statt `usingnextval(seqname)`, um den nächsten eindeutigen Wert der Sequenz abzurufen.
Mit dem folgenden Beispiel wird eine globale Sequenz erstellt:
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Partitionierte Sequenzen**
In Split-Step- oder partitionierten Sequenzen wird auf jedem Knoten eine normale PostgreSQL-Sequenz verwendet. Jede Sequenz wird um den gleichen Betrag inkrementiert und beginnt mit unterschiedlichen Offsets. Bei Schritt 100 generiert Knoten 1 beispielsweise die Sequenz 101, 201, 301 usw. und Knoten 2 generiert die Sequenz 102, 202, 302 usw. Dieses Schema funktioniert auch dann gut, wenn die Knoten über einen längeren Zeitraum nicht kommunizieren können. Es ist jedoch erforderlich, dass der Designer bei der Einrichtung des Schemas eine maximale Anzahl von Knoten festlegt und jeden Knoten einzeln konfiguriert. Fehler können leicht zu überlappenden Sequenzen führen.
Es ist relativ einfach, diesen Ansatz mit `pgactive` zu konfigurieren, indem Sie die gewünschte Sequenz auf einem Knoten wie folgt erstellen:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
Rufen Sie dann `setval` auf jedem Knoten auf, um einen anderen Offset-Startwert wie folgt anzugeben.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg\$1repack
Sie können die `pg_repack`-Erweiterung verwenden, um überflüssige Daten aus Tabellen und Indizes als Alternative zu `VACUUM FULL` zu entfernen. Die Erweiterung wird auf den RDS-for-PostgreSQL-Versionen 9.6.3 und höher unterstützt. Weitere Informationen zur `pg_repack` Erweiterung und zum vollständigen Table Repack finden Sie in der [GitHub Projektdokumentation](https://reorg.github.io/pg_repack/).
Im `VACUUM FULL` Gegensatz dazu erfordert die `pg_repack` Erweiterung in den folgenden Fällen nur für einen kurzen Zeitraum während der Neuerstellung der Tabelle eine exklusive Sperre (AccessExclusiveLock):
+ Erste Erstellung der Protokolltabelle – Eine Protokolltabelle wird erstellt, um Änderungen aufzuzeichnen, die beim ersten Kopieren der Daten vorgenommen wurden, wie im folgenden Beispiel gezeigt:
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ Letzte swap-and-drop Phase.
Für den Rest des Neuerstellungsvorgangs ist lediglich eine `ACCESS SHARE`-Sperre für die ursprüngliche Tabelle erforderlich, um Zeilen aus dieser Tabelle in die neue Tabelle zu kopieren. Dadurch können die INSERT-, UPDATE- und DELETE-Vorgänge wie gewohnt ausgeführt werden.
## Empfehlungen
Die folgenden Empfehlungen gelten, wenn Sie die Aufblähung aus den Tabellen und Indizes mithilfe der `pg_repack`-Erweiterung entfernen:
+ Führen Sie die Neuverpackung außerhalb der Geschäftszeiten oder während eines Wartungsfensters durch, um die Auswirkungen auf die Leistung anderer Datenbankaktivitäten so gering wie möglich zu halten.
+ Überwachen Sie blockierende Sitzungen während der Neuerstellungsaktivität genau und stellen Sie sicher, dass es in der Originaltabelle keine Aktivität gibt, die möglicherweise blockiert werden könnte`pg_repack`, insbesondere in der letzten swap-and-drop Phase, in der eine exklusive Sperre für die Originaltabelle erforderlich ist. Weitere Informationen finden Sie unter [Identifizieren, was eine Abfrage blockiert](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Wenn Sie eine blockierende Sitzung sehen, können Sie sie nach reiflicher Überlegung mit dem folgenden Befehl beenden. Dies hilft bei der Fortsetzung von `pg_repack`, um die Neuerstellung abzuschließen:
```
SELECT pg_terminate_backend(pid);
```
+ Beim Anwenden der angesammelten Änderungen aus der `pg_repack's`-Protokolltabelle auf Systeme mit einer sehr hohen Transaktionsrate kann der apply-Prozess möglicherweise nicht mit der Änderungsrate mithalten. In solchen Fällen könnte `pg_repack` den apply-Prozess nicht abschließen. Weitere Informationen finden Sie unter [Überwachen der neuen Tabelle während der Neuverpackung](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Wenn Indizes stark aufgebläht sind, besteht eine alternative Lösung darin, nur den Index neu zu packen. Dies trägt auch dazu bei, dass die Indexbereinigungszyklen von VACUUM schneller abgeschlossen werden.
Sie können die Indexbereinigungsphase mit manuellem VACUUM ab PostgreSQL Version 12 überspringen, und sie wird während der Notfallselbstbereinigung ab PostgreSQL Version 14 automatisch übersprungen. Auf diese Weise kann VACUUM schneller abgeschlossen werden, ohne dass die Index-Aufblähung entfernt wird, und ist nur für Notfallsituationen vorgesehen, z. B. zur Vermeidung von Wraparound-VACUUM. Weitere Informationen finden Sie unter [Vermeiden von Aufblähungen in Indizes](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) im Amazon Aurora-Benutzerhandbuch.
## Voraussetzungen
+ Die Tabelle muss die UNIQUE-Einschränkung PRIMARY KEY oder einen Wert ungleich Null haben.
+ Die Erweiterungsversion muss sowohl für den Client als auch für den Server identisch sein.
+ Stellen Sie sicher, dass die RDS-Instance mehr als `FreeStorageSpace` der Gesamtgröße der Tabelle ohne Aufblähung hat. Nehmen wir als Beispiel an, dass die Gesamtgröße der Tabelle einschließlich TOAST und Indizes 2 TB beträgt und die Gesamtaufblähung in der Tabelle 1 TB. Der erforderliche `FreeStorageSpace` muss größer sein als der von der folgenden Berechnung zurückgegebene Wert:
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
Mit der folgenden Abfrage können Sie die Gesamtgröße der Tabelle überprüfen und mit `pgstattuple` die Aufblähung ableiten. Weitere Informationen finden Sie unter [Diagnostizieren von Tabellen- und Index-Aufblähungen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) im Amazon Aurora-Benutzerhandbuch.
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Dieser Speicherplatz wird nach Abschluss der Aktivität zurückgewonnen.
+ Stellen Sie sicher, dass die RDS-Instance über genügend Rechen- und I/O-Kapazität verfügt, um den Neuverpackungsvorgang zu bewältigen. Sie könnten erwägen, die Instance-Klasse zu skalieren, um ein optimales Leistungsgleichgewicht zu erzielen.
**So richten Sie die `pg_repack`-Erweiterung ein**
1. Installieren Sie die `pg_repack`-Erweiterung auf Ihrer RDS-for-PostgreSQL-DB-Instance, indem Sie den folgenden Befehl ausführen.
```
CREATE EXTENSION pg_repack;
```
1. Führen Sie die folgenden Befehle aus, um Schreibzugriff auf temporäre Protokolltabellen zu gewähren, die von `pg_repack` erstellt wurden.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Stellen Sie mithilfe des `pg_repack`-Client-Dienstprogramms eine Verbindung mit der Datenbank her. Verwenden Sie ein Konto, das `rds_superuser`-Berechtigungen hat. Nehmen Sie beispielsweise an, dass die `rds_test`-Rolle `rds_superuser`-Berechtigungen hat. Die folgende Syntax führt `pg_repack` für vollständige Tabellen, einschließlich aller Tabellenindizes in der `postgres`- Datenbank durch.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**Anmerkung**
Stellen Sie die Verbindung mit der Option „-k“ her. Die Option -a wird nicht unterstützt.
Die Antwort des `pg_repack`-Clients stellt Informationen zu den Tabellen in der DB-Instance bereit, die neu verpackt werden.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. Die folgende Syntax packt eine einzelne `orders`-Tabelle einschließlich der Indizes in der `postgres`-Datenbank neu.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
Mit der folgenden Syntax werden nur Indizes für die `orders`-Tabelle in der `postgres`-Datenbank erneut gepackt.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Überwachen der neuen Tabelle während der Neuverpackung
+ Die Größe der Datenbank wird bis zur swap-and-drop Phase des Neupackens um die Gesamtgröße der Tabelle abzüglich des Bloats erhöht. Sie können die Wachstumsrate der Datenbankgröße überwachen, die Geschwindigkeit der Neuverpackung berechnen und die Zeit, die bis zum Abschluss der ersten Datenübertragung benötigt wird, grob abschätzen.
Stellen Sie sich als Beispiel die Gesamtgröße der Tabelle mit 2 TB, die Größe der Datenbank mit 4 TB und die Gesamtgröße der Tabelle mit 1 TB vor. Der Wert für die Gesamtgröße der Datenbank, der durch die Berechnung am Ende des Neuverpackungsvorgangs zurückgegeben wurde, lautet wie folgt:
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
Sie können die Geschwindigkeit des Neuverpackungsvorgangs grob schätzen, indem Sie die Wachstumsrate in Byte zwischen zwei Zeitpunkten als Stichproben ermitteln. Wenn die Wachstumsrate 1 GB pro Minute beträgt, kann es etwa 1000 Minuten oder 16,6 Stunden dauern, bis die erste Tabellenerstellung abgeschlossen ist. Zusätzlich zur ersten Tabellenerstellung muss `pg_repack` auch die aufgelaufenen Änderungen anwenden. Die dafür benötigte Zeit hängt von der Geschwindigkeit ab, mit der die laufenden Änderungen und die aufgelaufenen Änderungen angewendet werden.
**Anmerkung**
Sie können die `pgstattuple`-Erweiterung verwenden, um die Aufblähung in der Tabelle zu berechnen. Weitere Informationen finden Sie unter [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ Die Anzahl der Zeilen in der Protokolltabelle `pg_repack's` gemäß dem Neuverpackungsschema entspricht der Menge der Änderungen, die nach dem ersten Laden noch auf die neue Tabelle angewendet werden müssen.
Sie können die Protokolltabelle `pg_repack's` in `pg_stat_all_tables` überprüfen, um die Änderungen zu überwachen, die auf die neue Tabelle angewendet wurden. `pg_stat_all_tables.n_live_tup` gibt die Anzahl der Datensätze an, deren Übernahme auf die neue Tabelle noch aussteht. Weitere Informationen finden Sie unter [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ Sie können die `pg_stat_statements`-Erweiterung verwenden, um herauszufinden, wie viel Zeit für jeden Schritt des Neuverpackungsvorgangs benötigt wird. Dies ist hilfreich bei der Vorbereitung auf die Anwendung desselben Neuverpackungsvorgangs in einer Produktionsumgebung. Sie können die `LIMIT`-Klausel anpassen, um die Ausgabe weiter zu erweitern.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
Beim Umpacken handelt es sich ausschließlich um einen out-of-place Vorgang, sodass die Originaltabelle nicht beeinträchtigt wird und wir nicht mit unerwarteten Problemen rechnen, die eine Wiederherstellung der Originaltabelle erforderlich machen. Wenn das Neuverpacken unerwartet fehlschlägt, müssen Sie die Ursache des Fehlers untersuchen und ihn beheben.
Wenn das Problem behoben ist, löschen Sie die `pg_repack`-Erweiterung, erstellen Sie sie in der Datenbank, in der sich die Tabelle befindet, und wiederholen Sie den Schritt `pg_repack`. Darüber hinaus spielen die Verfügbarkeit von Rechenressourcen und der gleichzeitige Zugriff auf die Tabelle eine entscheidende Rolle für den rechtzeitigen Abschluss des Neuverpackungsvorgangs.
# Erweiterung aktualisieren und verwenden PLV8
PLV8 ist eine vertrauenswürdige Javascript-Spracherweiterung für PostgreSQL. Sie können sie für gespeicherte Prozeduren, Trigger und anderen prozeduralen Code verwenden, der von SQL aus aufrufbar ist. Diese Spracherweiterung wird von allen aktuellen Releases von PostgreSQL unterstützt.
Wenn Sie PostgreSQL verwenden [PLV8](https://plv8.github.io/)und auf eine neue PLV8 Version aktualisieren, nutzen Sie sofort die Vorteile der neuen Erweiterung. Führen Sie die folgenden Schritte aus, um Ihre Katalogmetadaten mit der neuen Version von zu synchronisieren. PLV8 Diese Schritte sind optional, aber wir empfehlen, sie durchzuführen, um Warnungen aufgrund fehlender Übereinstimmung von Metadaten zu vermeiden.
Durch den Upgrade-Vorgang werden alle Ihre vorhandenen PLV8 Funktionen gelöscht. Daher empfehlen wir, vor dem Upgrade einen Snapshot Ihrer DB-Instance von RDS für PostgreSQL zu erstellen. Weitere Informationen finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md).
**Wichtig**
Ab PostgreSQL-Version 18 werden in Amazon RDS für PostgreSQL die PostgreSQL-Erweiterungen `plcoffee` und `plls` eingestellt. Wir empfehlen Ihnen, die Verwendung von CoffeeScript und LiveScript in Ihren Anwendungen einzustellen, um sicherzustellen, dass Sie über einen Upgrade-Pfad für future Engine-Versions-Upgrades verfügen.
**Um Ihre Katalogmetadaten mit einer neuen Version von zu synchronisieren PLV8**
1. Überprüfen, ob Sie ein Update benötigen. Führen Sie dazu den folgenden Befehl aus, während Sie mit Ihrer Instance verbunden sind.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Wenn Ihre Ergebnisse Werte für eine installierte Version enthalten, die niedriger ist als die Standardversion, setzen Sie dieses Verfahren fort, um Ihre Erweiterungen zu aktualisieren. Die folgende Ergebnismenge beispielsweise deutet darauf hin, dass Sie ein Update vornehmen sollten.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Erstellen Sie einen Snapshot Ihrer RDS-for-PostgreSQL-DB-Instance, wenn Sie dies noch nicht getan haben. Sie können die folgenden Schritte fortsetzen, während der Snapshot erstellt wird.
1. Ermitteln Sie die Anzahl der PLV8 Funktionen in Ihrer DB-Instance, sodass Sie nach dem Upgrade überprüfen können, ob sie alle vorhanden sind. Die folgende SQL-Abfrage gibt beispielsweise die Anzahl der in plv8, plcoffee und plls geschriebenen Funktionen zurück.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Erstellen Sie mit pg\$1dump eine Dump-Datei, die nur das Schema enthält. Erstellen Sie beispielsweise eine Datei auf Ihrem Client-Computer im Verzeichnis `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
In diesem Beispiel werden die folgenden Optionen verwendet:
+ `-Fc` – Benutzerdefiniertes Format
+ --schema-only – Erstellen Sie nur einen Dump von Befehlen, die zum Erstellen des Schemas erforderlich sind (in diesem Fall Funktionen)
+ `-U` – Der RDS-Hauptbenutzername
+ `database` – Der Datenbankname für unsere DB-Instance
Weitere Informationen zu pg\$1dump finden Sie unter [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) in der PostgreSQL-Dokumentation.
1. Extrahieren Sie die in der Dump-Datei vorhandene DDL-Anweisung „CREATE FUNCTION”. Im folgenden Beispiel wird der `grep`-Befehl verwendet, um die DDL-Anweisung zu extrahieren, die die Funktionen erstellt, und sie in einer Datei zu speichern. Sie verwenden diese in nachfolgenden Schritten, um die Funktionen neu zu erstellen.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Weitere Informationen zu pg\$1restore finden Sie unter [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) in der PostgreSQL-Dokumentation.
1. Verwerfen Sie die Funktionen und Erweiterungen. Im folgenden Beispiel werden alle PLV8 basierten Objekte gelöscht. Die Option cascade stellt sicher, dass alle Abhängigkeiten verworfen werden.
```
DROP EXTENSION plv8 CASCADE;
```
Wenn Ihre PostgreSQL-Instance Objekte enthält, die auf plcoffee oder plls basieren, wiederholen Sie diesen Schritt für diese Erweiterungen.
1. Erstellen Sie die Erweiterungen. Das folgende Beispiel erstellt die plv8-, plcoffee- und plls-Erweiterungen.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Erstellen Sie die Funktionen unter Verwendung der Dump-Datei und der „Treiber“-Datei.
Das folgende Beispiel erstellt die zuvor extrahierten Funktionen neu.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Prüfen Sie mithilfe der folgenden Abfrage, ob all Ihre Funktionen neu erstellt wurden.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Die PLV8 Version 2 fügt Ihrer Ergebnismenge die folgende zusätzliche Zeile hinzu:
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Verwenden PL/Rust , um PostgreSQL-Funktionen in der Sprache Rust zu schreiben
PL/Rust is a trusted Rust language extension for PostgreSQL. You can use it for stored procedures, functions, and other procedural code that's callable from SQL. The PL/RustDie Spracherweiterung ist in den folgenden Versionen verfügbar:
+ RDS für PostgreSQL 17.1 und höhere 17-Versionen
+ RDS für PostgreSQL 16.1 und höhere 16-Versionen
+ RDS für PostgreSQL 15.2-R2 und höhere 15-Versionen
+ RDS für PostgreSQL 14.9 und höhere 14-Versionen
+ RDS für PostgreSQL 13.12 und höhere 13-Versionen
Weitere Informationen finden Sie unter [PL/Rust on](https://github.com/tcdi/plrust#readme). GitHub
**Topics**
+ [Einrichten von PL/Rust](#PL_Rust-setting-up)
+ [Erstellen von Funktionen mit PL/Rust](#PL_Rust-create-function)
+ [Verwenden von Kisten mit PL/Rust](#PL_Rust-crates)
+ [Einschränkungen von PL/Rust](#PL_Rust-limitations)
## Einrichten von PL/Rust
Um die plrust-Erweiterung auf Ihrer DB-Instance zu installieren, fügen Sie plrust zum Parameter `shared_preload_libraries` in der DB-Parametergruppe hinzu, die mit Ihrer DB-Instance verknüpft ist. Wenn die plrust-Erweiterung installiert ist, können Sie Funktionen erstellen.
Damit der Parameter `shared_preload_libraries` geändert werden kann, muss Ihre DB-Instance mit einer benutzerdefinierten Parametergruppe verknüpft sein. Informationen zum Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können die Plrust-Erweiterung mit dem oder dem AWS-Managementkonsole installieren. AWS CLI
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist.
### Konsole
**Installieren der plrust-Erweiterung im Parameter `shared_preload_libraries`**
Führen Sie die folgenden Schritte mit einem Konto aus, das Mitglied der `rds_superuser`-Gruppe (Rolle) ist.
1. Melden Sie sich bei der an AWS-Managementkonsole und ö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 den Namen Ihrer DB-Instance aus, um ihre Details anzuzeigen.
1. Öffnen Sie die Registerkarte **Konfiguration** für Ihre DB-Instance und suchen Sie den Link zur DB-Instance-Parametergruppe.
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer DB-Instance zugeordnet sind.
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den **`shared_preload_libraries`**-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie der Liste im Feld **Werte** „plrust“ hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
1. Starten Sie die DB-Instance neu, damit die Änderung am Parameter `shared_preload_libraries` in Kraft tritt. Der erste Neustart kann zusätzliche Zeit in Anspruch nehmen.
1. Wenn die Instance verfügbar ist, überprüfen Sie, ob „plrust“ initialisiert wurde. Stellen Sie mit `psql` eine Verbindung mit der DB-Instance her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
```
Ihre Ausgabe sollte wie folgt aussehen:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Installieren der plrust-Erweiterung im Parameter shared\$1preload\$1libraries**
Führen Sie die folgenden Schritte mit einem Konto aus, das Mitglied der `rds_superuser`-Gruppe (Rolle) ist.
1. Verwenden Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl, um plrust zum `shared_preload_libraries` Parameter hinzuzufügen.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI Befehl, um die DB-Instance neu zu starten und die Plrust-Bibliothek zu initialisieren. Der erste Neustart kann zusätzliche Zeit in Anspruch nehmen.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, können Sie überprüfen, ob „plrust“ initialisiert wurde. Stellen Sie mit `psql` eine Verbindung mit der DB-Instance her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
```
Ihre Ausgabe sollte wie folgt aussehen:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Erstellen von Funktionen mit PL/Rust
PL/Rust kompiliert die Funktion als dynamische Bibliothek, lädt sie und führt sie aus.
Die folgende Rust-Funktion filtert Vielfache aus einem Array.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Verwenden von Kisten mit PL/Rust
In den Versionen 16.3-R2 und höher von RDS für PostgreSQL werden in den Versionen 15.7-R2 und höher 15, 14.12-R2 und höher (14 Versionen) und 13.15-R2 und höher (13) zusätzliche Crates unterstützt: PL/Rust
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
In den Versionen 15.5-R2 und höher von RDS für PostgreSQL, 14.10-R2 und höher, 14 und 13.13-R2 und höher, 13, werden zwei zusätzliche Crates unterstützt: PL/Rust
+ `croaring-rs`
+ `num-bigint`
Beginnend mit den Versionen 15.4, 14.9 und 13.12 von Amazon RDS for PostgreSQL werden die folgenden Kisten unterstützt: PL/Rust
+ `aes`
+ `ctr`
+ `rand`
Für diese Kisten werden nur die Standardfunktionen unterstützt. Neue Versionen von RDS für PostgreSQL enthalten möglicherweise aktualisierte Versionen von Kisten und ältere Versionen von Kisten werden möglicherweise nicht mehr unterstützt.
Folgen Sie den bewährten Methoden für die Durchführung eines Hauptversions-Upgrades, um zu testen, ob Ihre PL/Rust Funktionen mit der neuen Hauptversion kompatibel sind. Weitere Informationen finden Sie im Blog [Bewährte Methoden für das Upgrade von Amazon RDS auf Haupt- und Nebenversionen von PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) und [Upgrade einer PostgreSQL-DB-Engine für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) im Amazon-RDS-Benutzerhandbuch.
Beispiele für die Verwendung von Abhängigkeiten bei der Erstellung einer PL/Rust Funktion finden [Sie unter Abhängigkeiten verwenden](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies).
## Einschränkungen von PL/Rust
Standardmäßig können Datenbankbenutzer den folgenden Befehl nicht verwendenPL/Rust. To provide access to PL/Rust, sich als Benutzer mit der Berechtigung rds\$1superuser verbinden und ihn ausführen:
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Verwalten von Geodaten mit der PostGIS-Erweiterung
PostGIS ist eine Erweiterung von PostgreSQL zur Speicherung und Verwaltung von Geodaten. Weitere Informationen zu PostGIS finden Sie unter [PostGIS.net](https://postgis.net/).
Ab Version 10.5 unterstützt PostgreSQL die libprotobuf-1.3.0-Bibliothek, die von PostGIS für die Arbeit mit Vektorkacheldaten der Kartenbox verwendet wird.
Für das Einrichten der PostGIS-Erweiterung sind `rds_superuser`-Berechtigungen erforderlich. Wir empfehlen Ihnen, einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung und Ihrer räumlichen Daten zu erstellen. Die PostGIS-Erweiterung und ihre zugehörigen Komponenten fügen PostgreSQL Tausende von Funktionen hinzu. Erstellen Sie die PostGIS-Erweiterung ggf. in einem eigenen Schema, wenn dies für Ihren Anwendungsfall sinnvoll ist. Das folgende Beispiel zeigt, wie die Erweiterung in einer eigenen Datenbank installiert wird. Dies ist jedoch nicht erforderlich.
**Topics**
+ [Schritt 1: Erstellen Sie einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung.](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [Schritt 2: Laden der PostGIS-Erweiterungen.](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [Schritt 3: Übertragen der Eigentümerschaft der Erweiterungsschemas](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [Schritt 4: Übertragen der Eigentümerschaft der PostGIS-Tabellen](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [Schritt 5: Testen der Erweiterungen](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [Schritt 6: Upgrade der PostGIS-Erweiterung](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [PostGIS-Erweiterungsversionen](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Upgrade von PostGIS 2 auf PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Schritt 1: Erstellen Sie einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung.
Zuerst stellen Sie eine Verbindung mit Ihrer DB-Instance von RDS für PostgreSQL als Benutzer her, der über `rds_superuser`-Berechtigungen verfügt. Wenn Sie beim Einrichten Ihrer Instance den Standardnamen beibehalten haben, stellen Sie eine Verbindung als `postgres` her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Erstellen Sie eine separate Rolle (Benutzer), um die PostGIS-Erweiterung zu verwalten.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Gewähren Sie dieser Rolle `rds_superuser`-Berechtigungen, damit die Rolle die Erweiterung installieren kann.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Erstellen Sie eine Datenbank, die Sie für Ihre PostGIS-Artefakte verwenden können. Dieser Schritt ist optional. Oder Sie können in Ihrer Benutzerdatenbank ein Schema für die PostGIS-Erweiterungen erstellen, aber das ist auch nicht erforderlich.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Gewähren Sie `gis_admin` alle Berechtigungen für die `lab_gis`-Datenbank.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Beenden Sie die Sitzung und stellen Sie wieder eine Verbindung mit Ihrer RDS-for-PostgreSQL-DB-Instance als `gis_admin` her.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Fahren Sie mit der Einrichtung der Erweiterung fort, wie in den nächsten Schritten beschrieben.
## Schritt 2: Laden der PostGIS-Erweiterungen.
Die PostGIS-Erweiterung enthält mehrere verwandte Erweiterungen, die zusammenarbeiten, um Geodatenfunktionen bereitzustellen. Je nach Anwendungsfall benötigen Sie möglicherweise nicht alle Erweiterungen, die Sie in diesem Schritt erstellt haben.
Verwenden Sie `CREATE EXTENSION`-Anweisungen, um die PostGIS-Erweiterungen zu laden.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Sie können die Ergebnisse überprüfen, indem Sie die in dem folgenden Beispiel gezeigte SQL-Abfrage ausführen, in der die Erweiterungen und ihre Besitzer aufgeführt sind.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Schritt 3: Übertragen der Eigentümerschaft der Erweiterungsschemas
Verwenden Sie die ALTER SCHEMA-Anweisungen, um die Eigentümerschaft der Schemata auf die Rolle `gis_admin` zu übertragen.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Sie können die Eigentümeränderung bestätigen, indem Sie die folgende SQL-Abfrage ausführen. Oder Sie können den Metabefehl `\dn` über die psql-Befehlszeile verwenden.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Schritt 4: Übertragen der Eigentümerschaft der PostGIS-Tabellen
**Anmerkung**
Ändern Sie nicht die Eigentümerschaft der PostGIS-Funktionen. Ein ordnungsgemäßer Betrieb sowie zukünftige Upgrades von PostGIS setzen voraus, dass sich an der Eigentümerschaft dieser Funktionen nichts ändert. Weitere Informationen zu PostGIS-Berechtigungen finden Sie unter [PostgreSQL-Sicherheit](https://postgis.net/workshops/postgis-intro/security.html).
Verwenden Sie die folgende Funktion, um die Eigentümerschaft der PostGIS-Tabellen auf die Rolle `gis_admin` zu übertragen. Führen Sie die folgende Anweisung aus der psql-Aufforderung aus, um die Funktion zu erstellen.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Führen Sie als Nächstes die folgende Abfrage aus, um die `exec`-Funktion auszuführen, die wiederum die Anweisungen ausführt und die Berechtigungen ändert.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Schritt 5: Testen der Erweiterungen
Um zu vermeiden, dass der Schemaname angegeben werden muss, fügen Sie das `tiger`-Schema Ihrem Suchpfad unter Verwendung des folgenden Befehls hinzu.
```
SET search_path=public,tiger;
SET
```
Testen Sie das `tiger`-Schema unter Verwendung der folgenden SELECT-Anweisung.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Weitere Informationen zu dieser Erweiterung finden Sie unter [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) in der PostGIS-Dokumentation.
Testen Sie den Zugriff auf das `topology`-Schema, indem Sie folgende `SELECT`-Anweisung verwenden. Das ruft die `createtopology`-Funktion zum Registrieren eines neuen Topologieobjekts (my\$1new\$1topo) mit der angegebenen Raumbezugskennung (26986) und der Standardtoleranz (0,5) auf. Weitere Informationen finden Sie [CreateTopology](https://postgis.net/docs/CreateTopology.html)in der PostGIS-Dokumentation.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Schritt 6: Upgrade der PostGIS-Erweiterung
Jede neue Version von PostgreSQL unterstützt eine oder mehrere Versionen der PostGIS-Erweiterung, die mit dieser Version kompatibel sind. Bei einem Upgrade der PostgreSQL-Engine auf eine neue Version wird die PostGIS-Erweiterung nicht automatisch aktualisiert. Vor dem Upgrade der PostgreSQL-Engine aktualisieren Sie PostGIS in der Regel auf die neueste verfügbare Version für die aktuelle PostgreSQL-Version. Details hierzu finden Sie unter [PostGIS-Erweiterungsversionen](#CHAP_PostgreSQL.Extensions.PostGIS).
Nach dem Upgrade der PostgreSQL-Engine aktualisieren Sie die PostGIS-Erweiterung erneut auf die Version, die für die neu aktualisierte PostgreSQL-Engine-Version unterstützt wird. Weitere Informationen zum Upgrade der PostgreSQL-Engine finden Sie unter [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)..
Sie können jederzeit prüfen, ob eine neue Version der PostGIS-Erweiterung auf der DB-Instance von RDS für PostgreSQL verfügbar ist. Führen Sie dazu den folgenden Befehl aus. Diese Funktion ist mit PostGIS 2.5.0 und höheren Versionen verfügbar.
```
SELECT postGIS_extensions_upgrade();
```
Wenn Ihre Anwendung die neueste PostGIS-Version nicht unterstützt, können Sie weiterhin eine ältere Version von PostGIS installieren, die in Ihrer Hauptversion wie folgt verfügbar ist.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Wenn Sie von einer älteren Version auf eine bestimmte PostGIS-Version aktualisieren möchten, können Sie auch den folgenden Befehl verwenden.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Abhängig von der Version, von der Sie ein Upgrade durchführen, müssen Sie diese Funktion möglicherweise noch einmal verwenden. Das Ergebnis des ersten Durchlaufs der Funktion bestimmt, ob eine zusätzliche Upgrade-Funktion benötigt wird. Dies ist beispielsweise bei einem Upgrade von PostGIS 2 auf PostGIS 3 der Fall. Weitere Informationen finden Sie unter [Upgrade von PostGIS 2 auf PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Wenn Sie diese Erweiterung aktualisiert haben, um ein Upgrade der Hauptversion der PostgreSQL-Engine vorzubereiten, können Sie mit anderen vorbereitenden Aufgaben fortfahren. Weitere Informationen finden Sie unter [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## PostGIS-Erweiterungsversionen
Wir empfehlen Ihnen, die Versionen aller Erweiterungen wie PostGIS zu installieren, wie sie unter [Extension versions for Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Versionen aller Erweiterungen für Amazon RDS für PostgreSQL) in *Versionshinweise für Amazon RDS für PostgreSQL.*. Sie können mithilfe des folgenden Befehls auflisten, welche Versionen in Ihrer Version verfügbar sind.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Versionsinformationen finden Sie in den folgenden Abschnitten in den *Versionshinweisen zu Amazon RDS für PostgreSQL*:
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 9.6.x](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Upgrade von PostGIS 2 auf PostGIS 3
Ab Version 3.0 ist die PostGIS-Raster-Funktionalität jetzt eine separate Erweiterung, `postgis_raster`. Diese Erweiterung hat einen eigenen Installations- und Upgrade-Pfad. Dadurch werden Dutzende von Funktionen, Datentypen und anderen Artefakten, die für die Rasterbildverarbeitung erforderlich sind, aus der `postgis`-Kernerweiterung entfernt. Das heißt, wenn Ihr Anwendungsfall keine Raster-Verarbeitung erfordert, müssen Sie die `postgis_raster`-Erweiterung nicht installieren.
Im folgenden Upgrade-Beispiel extrahiert der erste Upgrade-Befehl die Raster-Funktionalität in die `postgis_raster`-Erweiterung. Ein zweiter Upgrade-Befehl ist dann erforderlich, um ein Upgrade von `postgis_raster` auf die neue Version durchzuführen.
**So führen Sie ein Upgrade von PostGIS 2 auf PostGIS 3 durch**
1. Identifizieren Sie die Standardversion von PostGIS, die für die PostgreSQL-Version auf Ihrem verfügbar ist. DB-Instance von RDS für PostgreSQL. Führen Sie dazu die folgende Abfrage durch.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifizieren Sie die Versionen von PostGIS, die in jeder Datenbank auf Ihrer DB-Instance von RDS für PostgreSQL installiert sind. Anders gesagt: Fragen Sie jede Benutzerdatenbank wie folgt ab.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Diese Nichtübereinstimmung zwischen der Standardversion (PostGIS 3.1.4) und der installierten Version (PostGIS 2.3.7) bedeutet, dass Sie die PostGIS-Erweiterung aktualisieren müssen.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Führen Sie die folgende Abfrage aus, um sicherzustellen, dass sich die Raster-Funktionalität jetzt in einem eigenen Paket befindet.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
Die Ausgabe zeigt, dass es immer noch einen Unterschied zwischen den Versionen gibt. Die PostGIS-Funktionen sind Version 3 (postgis-3), während die Raster-Funktionen (rtpostgis) Version 2 (rtpostgis-2.3) sind. Um das Upgrade abzuschließen, führen Sie den Upgrade-Befehl erneut wie folgt aus.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Die Warnmeldungen können Sie ohne Bedenken ignorieren. Führen Sie die folgende Abfrage erneut aus, um zu überprüfen, ob das Upgrade abgeschlossen ist. Das Upgrade ist abgeschlossen, wenn PostGIS und alle zugehörigen Erweiterungen nicht als aktualisierungsbedürftig gekennzeichnet sind.
```
SELECT postgis_full_version();
```
1. Verwenden Sie die folgende Abfrage, um den abgeschlossenen Upgrade-Vorgang und die separat gepackten Erweiterungen anzuzeigen und zu überprüfen, ob ihre Versionen übereinstimmen.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
Die Ausgabe zeigt, dass die PostGIS-2-Erweiterung auf PostGIS 3 aktualisiert wurde und beide `postgis` und die jetzt getrennte `postgis_raster`-Erweiterungen Version 3.1.5 sind.
Wenn Sie nach Abschluss dieses Upgrades die Raster-Funktionalität nicht verwenden möchten, können Sie die Erweiterung wie folgt löschen.
```
DROP EXTENSION postgis_raster;
```
# Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL
Ein Fremddaten-Wrapper (FDW) ist eine bestimmte Art von Erweiterung, die Zugriff auf externe Daten ermöglicht. Zum Beispiel ermöglicht die Erweiterung `oracle_fdw` Ihrem RDS-für-PostgreSQL-DB-Cluster die Zusammenarbeit mit Oracle-Datenbanken. Mithilfe der nativen PostgreSQL-Erweiterung `postgres_fdw` können Sie beispielsweise auf Daten zugreifen, die in PostgreSQL-DB-Instances außerhalb Ihrer RDS-für-PostgreSQL-DB-Instance gespeichert sind.
Im Folgenden finden Sie Informationen zu mehreren unterstützten PostgreSQL-Fremddaten-Wrappern.
**Topics**
+ [Verwenden der Erweiterung log\$1fdw für den Zugriff auf das DB-Protokoll mithilfe von SQL](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [Verwenden der postgres\$1fdw-Erweiterung für den Zugriff auf externe Daten](postgresql-commondbatasks-fdw.md)
+ [Arbeiten mit MySQL-Datenbanken mithilfe der Erweiterung mysql\$1fdw](postgresql-mysql-fdw.md)
+ [Arbeiten mit Oracle-Datenbanken unter Verwendung der Erweiterung oracle\$1fdw](postgresql-oracle-fdw.md)
+ [Arbeiten mit SQL-Server-Datenbanken unter Verwendung der Erweiterung tds\$1fdw](postgresql-tds-fdw.md)
# Verwenden der Erweiterung log\$1fdw für den Zugriff auf das DB-Protokoll mithilfe von SQL
Die DB-Instance von RDS für PostgreSQL unterstützt die `log_fdw`-Erweiterung, mit der Sie über eine SQL-Schnittstelle auf Ihr Datenbank-Engine-Protokoll zugreifen können. Die `log_fdw`-Erweiterung umfasst zwei neue Funktionen, die das Erstellen von Fremdtabellen für Datenbankprotokolle erleichtern:
+ `list_postgres_log_files` führt die Dateien im Datenbankprotokollverzeichnis und die Dateigröße in Bytes auf.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` erstellt eine Fremdtabelle für die angegebene Datei in der aktuellen Datenbank.
Alle durch `log_fdw` erstellten Funktionen gehören `rds_superuser`. Mitglieder der `rds_superuser`-Rolle können anderen Datenbankbenutzern Zugriff auf diese Funktionen gewähren.
Standardmäßig werden die Protokolldateien von Amazon RDS im `stderr` (Standardfehler)-Format generiert, wie im `log_destination`-Parameter angegeben. Es gibt nur zwei Optionen für diesen Parameter: `stderr` und `csvlog` (Comma Separated Values, CSV). Wenn Sie dem Parameter die Option `csvlog` hinzufügen, generiert Amazon RDS sowohl `stderr`- als auch `csvlog`-Protokolle. Dies kann die Speicherkapazität Ihres DB-Clusters beeinträchtigen. Daher müssen Sie sich der anderen Parameter bewusst sein, die sich auf die Protokollbehandlung auswirken. Weitere Informationen finden Sie unter [Festlegen des Protokollziels (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
Ein Vorteil der Generierung von `csvlog`-Protokollen ist, dass Sie mit der `log_fdw`-Erweiterung Fremdtabellen erstellen können, bei denen die Daten ordentlich in verschiedene Spalten aufgeteilt sind. Dazu muss Ihre Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet sein, damit Sie die Einstellung für `log_destination` ändern können. Weitere Informationen zur Vorgehensweise finden Sie unter [Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Im folgenden Beispiel wird angenommen, dass der `log_destination`-Parameter `cvslog` enthält.
**So verwenden Sie die Erweiterung log\$1fdw:**
1. Installieren Sie die `log_fdw`-Erweiterung.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Erstellen Sie den Protokollserver als Fremddaten-Wrapper.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Wählen Sie aus einer Liste an Protokolldateien "alle" aus.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
Beispiel-Antwort.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Erstellen Sie eine Tabelle mit einer einzigen 'log\$1entry'-Spalte für die ausgewählte Datei.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
Die Antwort liefert keine weiteren Details außer, dass die Tabelle jetzt existiert.
```
-----------------------------------
(1 row)
```
1. Wählen Sie ein Beispiel der Protokolldatei aus. Mit dem folgenden Code werden die Protokollzeit und die Fehlermeldungsbeschreibung abgerufen.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
Beispiel-Antwort.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Verwenden der postgres\$1fdw-Erweiterung für den Zugriff auf externe Daten
Auf die Daten in einer Tabelle auf einem Remote-Datenbank-Server können Sie mit der Erweiterung [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html) zugreifen. Wenn Sie eine Remote-Verbindung ausgehend von einer PostgreSQL-DB-Instance einrichten, ist der Zugriff auch für das Lesereplikat verfügbar.
**Verwenden Sie postgres\$1fdw wie folgt für den Zugriff auf einen Remote-Datenbank-Server:**
1. Installieren Sie die Erweiterung postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Erstellen Sie einen Fremddaten-Server mit CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Erstellen Sie ein Benutzer-Mapping, um die Rolle zu identifizieren, die auf dem Remote-Server verwendet werden soll.
**Wichtig**
Um das Passwort so zu redigieren, dass es nicht in den Protokollen angezeigt wird, legen Sie es auf Sitzungsebene auf `log_statement=none` fest. Durch die Festlegung auf Parameterebene wird das Passwort nicht redigiert.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Erstellen Sie eine Tabelle, die der Tabelle auf dem Remote-Server zugewiesen ist.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Arbeiten mit MySQL-Datenbanken mithilfe der Erweiterung mysql\$1fdw
Um von Ihrer DB-Instance für RDS für PostgreSQL auf eine MySQL-kompatible Datenbank zuzugreifen, können Sie die `mysql_fdw`-Erweiterung installieren und verwenden. Mit diesem Fremddaten-Wrapper können Sie mit RDS für MySQL, Aurora MySQL, MariaDB und anderen MySQL-kompatiblen Datenbanken arbeiten. Die Verbindung der DB-Instance für RDS für PostgreSQL mit der MySQL-Datenbank wird je nach Client- und Serverkonfigurationen bestmöglich verschlüsselt. Sie können die Verschlüsselung jedoch erzwingen, wenn Sie möchten. Weitere Informationen finden Sie unter [Verwenden der Verschlüsselung während der Übertragung mit der Erweiterung](#postgresql-mysql-fdw.encryption-in-transit).
Die `mysql_fdw`-Erweiterung wird in Amazon RDS für PostgreSQL Version 14.2, 13.6 und neueren Versionen unterstützt. Es werden Auswahlen, Einfügungen, Updates und Löschungen einer RDS-für-PostgreSQL-DB in Tabellen einer MySQL-kompatiblen Datenbank-Instance unterstützt.
**Topics**
+ [Einrichten der RDS-für-PostgreSQL-DB zur Verwendung der mysql\$1fdw-Erweiterung](#postgresql-mysql-fdw.setting-up)
+ [Beispiel: Arbeiten mit einer RDS-für-MySQL-Datenbank von RDS für PostgreSQL](#postgresql-mysql-fdw.using-mysql_fdw)
+ [Verwenden der Verschlüsselung während der Übertragung mit der Erweiterung](#postgresql-mysql-fdw.encryption-in-transit)
## Einrichten der RDS-für-PostgreSQL-DB zur Verwendung der mysql\$1fdw-Erweiterung
Das Einrichten der `mysql_fdw`-Erweiterung auf der RDS-für-PostgreSQL-DB-Instance umfasst das Laden der Erweiterung in die DB-Instance und das anschließende Erstellen des Verbindungspunkts mit der MySQL-DB-Instance. Für diese Aufgabe benötigen Sie folgende Details zur MySQL-DB-Instance:
+ Hostname oder Endpunkt. Sie können den Endpunkt für eine RDS-für-MySQL-DB-Instance mithilfe der Konsole ermitteln. Wählen Sie die Registerkarte „Connectivity & security“ (Konnektivität und Sicherheit) aus und sehen Sie im Abschnitt „Endpoint and port“ (Endpunkt und Port) nach.
+ Port-Nummer. Die Standardport-Nummer für MySQL ist 3306.
+ Name der Datenbank. Die DB-ID.
Sie müssen auch Zugriff auf die Sicherheitsgruppe oder die Zugriffssteuerungsliste (ACL) für den MySQL-Port 3306 gewähren. ebenso wiedie RDS-für-PostgreSQL-DB-Instance und die RDS-für-MySQL-DB-Instance benötigen Zugriff auf Port 3306. Wenn der Zugriff nicht korrekt konfiguriert ist, wird beim Versuch, eine Verbindung mit einer MySQL-kompatiblen Tabelle herzustellen, eine Fehlermeldung ähnlich wie die folgende angezeigt:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
Im folgenden Verfahren erstellen Sie (als `rds_superuser`-Konto) den fremden Server. Anschließend gewähren Sie bestimmten Benutzern Zugriff auf den fremden Server. Diese Benutzer erstellen dann ihre eigenen Zuordnungen zu den entsprechenden MySQL-Benutzerkonten zur Zusammenarbeit mit der MySQL-DB-Instance.
**So greifen Sie mit mysql\$1fdw auf einen MySQL-Datenbankserver zu**
1. Stellen Sie über ein Konto, das die `rds_superuser`-Rolle enthält, eine Verbindung mit Ihrer PostgreSQL-DB-Instance her. Wenn Sie die Standardwerte beim Erstellen der RDS-für-PostgreSQL-DB-Instance akzeptiert haben, lautet der Benutzername `postgres`. Sie können sich mit dem `psql`-Befehlszeilen-Tool wie folgt verbinden:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Installieren Sie die `mysql_fdw`-Erweiterung wie folgt:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Nachdem die Erweiterung auf der RDS-für-PostgreSQL-DB-Instance installiert wurde, richten Sie den fremden Server ein, der die Verbindung mit einer MySQL-Datenbank bereitstellt.
**So erstellen Sie den fremden Server**
Führen Sie diese Aufgaben auf der RDS-für-PostgreSQL-DB-Instance aus. Die Schritte setzen voraus, dass Sie als Benutzer mit `rds_superuser`-Berechtigungen wie `postgres` verbunden sind.
1. Erstellen Sie einen fremden Server auf der RDS-for-PostgreSQL-DB-Instance:
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Gewähren Sie den entsprechenden Benutzern Zugriff auf den fremden Server. Dies sollten keine Administratorbenutzer sein, d. h. Benutzer ohne `rds_superuser`-Rolle.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
PostgreSQL-Benutzer erstellen und verwalten ihre eigenen Verbindungen mit der MySQL-Datenbank über den fremden Server.
## Beispiel: Arbeiten mit einer RDS-für-MySQL-Datenbank von RDS für PostgreSQL
Angenommen, Sie haben eine einfache Tabelle auf einer RDS-für-PostgreSQL-DB-Instance. Ihre RDS-für-PostgreSQL-Benutzer möchten (`SELECT`)-, `INSERT`-, `UPDATE`- und `DELETE`-Elemente in dieser Tabelle abfragen. Nehmen wir an, dass die `mysql_fdw`-Erweiterung auf Ihrer RDS-für-PostgreSQL-DB-Instance erstellt wurde, wie im vorherigen Verfahren beschrieben. Nachdem Sie eine Verbindung mit der RDS-für-PostgreSQL-DB-Instance als Benutzer mit `rds_superuser`-Berechtigungen hergestellt haben, können Sie mit den folgenden Schritten fortfahren.
1. Erstellen Sie einen fremden Server in der RDS-für-PostgreSQL-DB-Instance:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Gewähren Sie einem Benutzer, der keine `rds_superuser`-Berechtigungen hat, die Nutzung, zum Beispiel `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Stellen Sie eine Connect als *user1* und erstellen Sie dann eine Zuordnung zum MySQL-Benutzer:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Erstellen Sie eine fremde Tabelle, die mit der MySQL-Tabelle verknüpft ist:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Führen Sie eine einfache Abfrage mit der fremden Tabelle aus:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Sie können der MySQL-Tabelle Daten hinzufügen, ändern und daraus entfernen. Beispiel:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Führen Sie die `SELECT`-Abfrage noch einmal aus, um die Ergebnisse zu sehen:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Verwenden der Verschlüsselung während der Übertragung mit der Erweiterung
Die Verbindung mit MySQL über RDS für PostgreSQL verwendet standardmäßig die Verschlüsselung während der Übertragung (TLS/SSL). Die Verbindung wird jedoch nicht verschlüsselt, wenn sich die Client- und Serverkonfiguration unterscheiden. Sie können die Verschlüsselung für alle ausgehenden Verbindungen erzwingen, indem Sie die Option `REQUIRE SSL` in den RDS-für-MySQL-Benutzerkonten angeben. Derselbe Ansatz funktioniert auch für MariaDB- und Aurora-MySQL-Benutzerkonten.
Für MySQL-Benutzerkonten, die für `REQUIRE SSL` konfiguriert sind, schlägt der Verbindungsversuch fehl, wenn keine sichere Verbindung hergestellt werden kann.
Um die Verschlüsselung für vorhandene MySQL-Datenbankbenutzerkonten durchzusetzen, können Sie den Befehl `ALTER USER` verwenden. Die Syntax variiert je nach MySQL-Version, wie in der folgenden Tabelle gezeigt. Weitere Informationen finden Sie unter [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) im *MySQL-Referenzhandbuch*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Weitere Informationen zur Erweiterung `mysql_fdw` finden Sie in der [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw)-Dokumentation.
# Arbeiten mit Oracle-Datenbanken unter Verwendung der Erweiterung oracle\$1fdw
Um von Ihrer RDS-für-PostgreSQL-DB-Instance auf eine Oracle-Datenbank zuzugreifen, können Sie die Erweiterung `oracle_fdw` installieren und verwenden. Diese Erweiterung ist ein Fremddaten-Wrapper für Oracle-Datenbanken. Weitere Informationen zu dieser Erweiterung finden Sie in der [oracle\$1fdw](https://github.com/laurenz/oracle_fdw)-Dokumentation.
Die Erweiterung `oracle_fdw` wird von den RDS-für-PostgreSQL-Versionen 12.7, 13.3 und höher unterstützt.
**Topics**
+ [Aktivieren der Erweiterung oracle\$1fdw](#postgresql-oracle-fdw.enabling)
+ [Beispiel: Verwendung eines fremden Servers, der mit einer Amazon RDS für Oracle Database verknüpft ist](#postgresql-oracle-fdw.example)
+ [Datenverschlüsselung während der Übertragung](#postgresql-oracle-fdw.encryption)
+ [Informationen zur Ansicht pg\$1user\$1mappings und zu Berechtigungen](#postgresql-oracle-fdw.permissions)
## Aktivieren der Erweiterung oracle\$1fdw
So verwenden Sie die Erweiterung oracle\$1fdw:
**Aktivieren der Erweiterung oracle\$1fdw**
+ Führen Sie den folgenden Befehl mit einem Konto aus, das die `rds_superuser`-Berechtigungen besitzt.
```
CREATE EXTENSION oracle_fdw;
```
## Beispiel: Verwendung eines fremden Servers, der mit einer Amazon RDS für Oracle Database verknüpft ist
Das folgende Beispiel zeigt die Verwendung eines fremden Servers, der mit einer Amazon-RDS-für-Oracle-Datenbank verknüpft ist.
**So erstellen Sie einen fremden Server, der mit einer RDS-for-Oracle-Datenbank verknüpft ist:**
1. Beachten Sie Folgendes auf der RDS-for-Oracle-DB-Instance:
+ Endpunkt
+ Port
+ Datenbankname
1. Erstellen Sie einen fremden Server.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Gewähren Sie einem Benutzer, der keine `rds_superuser`-Berechtigungen hat, die Nutzung, zum Beispiel `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Verbinden Sie sich als `user1` und erstellen Sie ein Mapping zu einem Oracle-Benutzer.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Erstellen einer fremden Tabelle, die mit einer Oracle-Tabelle verknüpft ist.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Fragen Sie die fremde Tabelle ab.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Wenn die Abfrage den folgenden Fehler meldet, überprüfen Sie Ihre Sicherheitsgruppe und Zugriffssteuerungsliste (Access Control List, ACL), um sicherzustellen, dass beide Instances kommunizieren können.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Datenverschlüsselung während der Übertragung
Die PostgreSQL-zu-Oracle-Verschlüsselung bei der Übertragung basiert auf einer Kombination von Client- und Server-Konfigurationsparametern. Ein Beispiel für Oracle 21c finden Sie unter [Informationen zu den Werten für Verschlüsselung und Integrität](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) in der Oracle-Dokumentation. Der Client, der für oracle\$1fdw auf Amazon RDS verwendet wird, ist mit `ACCEPTED` konfiguriert, was bedeutet, dass die Verschlüsselung von der Konfiguration des Oracle-Datenbankservers abhängt und Oracle Security Library (libnnz) als Verschlüsselung verwendet wird.
Wenn sich Ihre Datenbank auf RDS für Oracle befindet, finden Sie weitere Informationen zum Konfigurieren der Verschlüsselung unter [Oracle Native Network Encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html).
## Informationen zur Ansicht pg\$1user\$1mappings und zu Berechtigungen
Der PostgreSQL-Katalog `pg_user_mapping` speichert das Mapping eines Benutzers von RDS für PostgreSQL für den Benutzer auf einem fremden Datenserver (Remote). Der Zugriff auf den Katalog ist eingeschränkt, aber Sie verwenden die Ansicht `pg_user_mappings`, um die Mappings zu sehen. Das folgende Beispiel zeigt, wie Berechtigungen für eine Oracle-Beispieldatenbank gelten. Diese Informationen gelten im Allgemeinen für jeden fremden Daten-Wrapper.
In der folgenden Ausgabe finden Sie Rollen und Berechtigungen, die drei verschiedenen Beispielbenutzern zugeordnet sind. Benutzer `rdssu1` und `rdssu2` sind Mitglieder der `rds_superuser`-Rolle und `user1` nicht. In dem Beispiel wird der `psql`-Metabefehl `\du` verwendet, um vorhandene Rollen aufzulisten.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Alle Benutzer, einschließlich Benutzer mit `rds_superuser`-Berechtigungen, dürfen ihre eigenen Benutzerzuordnungen (`umoptions`) in der `pg_user_mappings`-Tabelle anzeigen. Wie im folgenden Beispiel gezeigt, wird trotz `rdssu1``rds_superuser`-Berechtigungen ein Fehler gemeldet, wenn `rdssu1` versucht, alle Benutzerzuordnungen abzurufen:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Im Folgenden sind einige Beispiele aufgeführt.
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Aufgrund von Unterschieden in der Implementierung von `information_schema._pg_user_mappings` und `pg_catalog.pg_user_mappings` erfordert ein manuell erstelltes `rds_superuser` zusätzliche Berechtigungen zum Anzeigen von Passwörtern in `pg_catalog.pg_user_mappings`.
Es sind keine zusätzlichen Berechtigungen für `rds_superuser` nötig, um Kennwörter in `information_schema._pg_user_mappings` anzuzeigen.
Benutzer, die nicht über die `rds_superuser`-Rolle verfügen können Passwörter in `pg_user_mappings` nur unter den folgenden Bedingungen anzeigen:
+ Der aktuelle Benutzer ist der zugeordnete Benutzer und besitzt den Server oder besitzt die `USAGE`-Berechtigung dafür.
+ Der aktuelle Benutzer ist der Serverbesitzer und das Mapping ist für `PUBLIC`.
# Arbeiten mit SQL-Server-Datenbanken unter Verwendung der Erweiterung tds\$1fdw
Sie können die PostgreSQL-Erweiterung `tds_fdw` für den Zugriff auf Datenbanken verwenden, die das TDS-Protokoll (Tabular Data Stream) unterstützen, wie Sybase- und Microsoft-SQL-Server-Datenbanken. Mit diesem Fremddaten-Wrapper können Sie sich von Ihrer RDS-für-PostgreSQL-DB-Instance aus mit Datenbanken verbinden, die das TDS-Protokoll verwenden, einschließlich Amazon RDS for Microsoft SQL Server. Weitere Informationen finden Sie in der [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw)-Dokumentation auf GitHub.
Die Erweiterung `tds_fdw` wird von den Amazon-RDS-für-PostgreSQL-Versionen 14.2, 13.6 und höher unterstützt.
## Einrichten Ihrer Aurora-PostgreSQL-DB zur Verwendung der tds\$1fdw-Erweiterung
In den folgenden Verfahren finden Sie ein Beispiel für die Einrichtung und Verwendung der Erweiterung `tds_fdw` mit einer RDS-für-PostgreSQL-DB-Instance. Bevor Sie eine Verbindung mit einer SQL-Server-Datenbank mithilfe von `tds_fdw` herstellen können, benötigen Sie die folgenden Details für die Instance:
+ Hostname oder Endpunkt. Sie können den Endpunkt für eine RDS-for-SQL-Server-DB-Instance mithilfe der Konsole ermitteln. Wählen Sie die Registerkarte „Connectivity & security“ (Konnektivität und Sicherheit) aus und sehen Sie im Abschnitt „Endpoint and port“ (Endpunkt und Port) nach.
+ Port-Nummer. Die Standardport-Nummer für Microsoft SQL Server ist 1433.
+ Name der Datenbank. Die DB-ID.
Sie müssen auch Zugriff auf die Sicherheitsgruppe oder die Zugriffssteuerungsliste (ACL) für den SQL-Server-Port 1433 gewähren. Sowohl die RDS-für-PostgreSQL-DB-Instance als auch die RDS-for-SQL-Server-DB-Instance benötigen Zugriff auf Port 1433. Wenn der Zugriff nicht richtig konfiguriert ist, wird beim Versuch, den Microsoft SQL Server abzufragen, die folgende Fehlermeldung angezeigt:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**So verbinden Sie sich mit tds\$1fdw mit einer SQL-Server-Datenbank**
1. Verbinden Sie sich mit Ihrer PostgreSQL-DB-Instance über ein Konto mit der `rds_superuser`-Rolle:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Installieren Sie die `tds_fdw`-Erweiterung.
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Nachdem die Erweiterung auf Ihrer RDS-für-PostgreSQL-DB-Instance installiert wurde, richten Sie den fremden Server ein.
**So erstellen Sie den fremden Server**
Führen Sie diese Aufgaben auf der RDS-für-PostgreSQL-DB-Instance unter Verwendung eines Kontos mit `rds_superuser`-Berechtigungen aus.
1. Erstellen Sie einen fremden Server auf der RDS-for-PostgreSQL-DB-Instance:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Um auf Nicht-ASCII-Daten auf der SQLServer-Seite zuzugreifen, erstellen Sie einen Serverlink mit der Option character\$1set auf der DB-Instance von RDS für PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Gewähren Sie einem Benutzer, der keine `rds_superuser`-Rollenberechtigungen hat, Berechtigungen, zum Beispiel `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Stellen Sie eine Verbindung als „user1“ (Benutzer 1) her und erstellen Sie dann eine Zuordnung zum SQL-Server-Benutzer:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Erstellen Sie eine fremde Tabelle, die mit einer SQL-Server-Tabelle verknüpft ist:
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Fragen Sie die fremde Tabelle ab:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Verwenden der Verschlüsselung während der Übertragung für die Verbindung
Die Verbindung von RDS for PostgreSQL mit SQL Server verwendet je nach SQL-Server-Datenbankkonfiguration die Verschlüsselung während der Übertragung (TLS/SSL). Wenn der SQL Server nicht für die Verschlüsselung konfiguriert ist, bleibt der RDS-für-PostgreSQL-Client, der die Anforderung an die SQL-Server-Datenbank stellt, unverschlüsselt.
Sie können die Verschlüsselung für die Verbindung mit RDS-for-SQL-Server DB-Instances erzwingen, indem Sie den `rds.force_ssl`-Parameter festlegen. Weitere Informationen finden Sie unter [Erzwingen von Verbindungen mit Ihrer DB-Instance, um SSL zu verwenden](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Weitere Informationen zur SSL/TLS-Konfiguration für RDS for SQL Server finden Sie unter [Verwenden von SSL mit einer Microsoft-SQL-Server-DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Arbeiten mit Trusted Language Extensions für PostgreSQL
Trusted Language Extensions für PostgreSQL ist ein Open-Source-Entwicklungskit für die Erstellung von PostgreSQL-Erweiterungen. Es ermöglicht Ihnen, leistungsstarke PostgreSQL-Erweiterungen zu erstellen und diese sicher auf Ihrer PostgreSQL-DB-Instance auszuführen. Mithilfe von Trusted Language Extensions (TLE) für PostgreSQL können Sie PostgreSQL-Erweiterungen erstellen, die dem dokumentierten Ansatz zur Erweiterung der PostgreSQL-Funktionalität folgen. Weitere Informationen finden Sie unter [Packaging Related Objects in a Extension](https://www.postgresql.org/docs/current/extend-extensions.html) in der PostgreSQL-Dokumentation.
Ein wesentlicher Vorteil von TLE besteht darin, dass Sie es in Umgebungen verwenden können, die keinen Zugriff auf das der PostgreSQL-Instance zugrunde liegende Dateisystem bieten. Bisher war für die Installation einer neuen Erweiterung Zugriff auf das Dateisystem erforderlich. Mit TLE entfällt diese Einschränkung. Es bietet eine Entwicklungsumgebung für die Erstellung neuer Erweiterungen für jede PostgreSQL-Datenbank, einschließlich solcher, die auf Ihren DB-Instances von RDS für PostgreSQL ausgeführt werden.
TLE wurde entwickelt, um den Zugriff auf unsichere Ressourcen für die Erweiterungen zu verhindern, die Sie mit TLE erstellen. Die Laufzeitumgebung begrenzt die Auswirkungen eines Erweiterungsdefekts auf eine einzelne Datenbankverbindung. TLE verleiht Datenbankadministratoren auch eine detaillierte Kontrolle darüber, wer Erweiterungen installieren kann, und bietet ein Berechtigungsmodell für deren Ausführung.
TLE wird von den folgenden RDS-for-PostgreSQL-Versionen unterstützt:
+ Version 18.1 und höhere 18-Versionen
+ Version 17.1 und höhere 17-Versionen
+ Version 16.1 und höhere 16-Versionen
+ Version 15.2 und höhere 15-Versionen
+ Version 14.5 und höhere 14-Versionen
+ Version 13.12 und höhere 13-Versionen
Die Entwicklungsumgebung und Laufzeit von Trusted Language Extensions sind als `pg_tle`-PostgreSQL-Erweiterung, Version 1.0.1, verpackt. Es unterstützt die Erstellung von Erweiterungen in Perl JavaScript, Tcl, PL/pgSQL und SQL. Sie installieren die `pg_tle`-Erweiterung in Ihrer DB-Instance von RDS für PostgreSQL auf die gleiche Weise wie andere PostgreSQL-Erweiterungen. Nach der Einrichtung von `pg_tle` können Entwickler damit neue PostgreSQL-Erweiterungen, sogenannte *TLE-Erweiterungen*, erstellen.
In den folgenden Themen finden Sie Informationen darüber, wie Sie Trusted Language Extensions einrichten und Ihre eigenen TLE-Erweiterungen erstellen.
**Topics**
+ [Terminologie](PostgreSQL_trusted_language_extension-terminology.md)
+ [Anforderungen für die Verwendung von Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-requirements.md)
+ [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md)
+ [Übersicht über Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension.overview.md)
+ [Erstellen von TLE-Erweiterungen für RDS für PostgreSQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [Löschen Ihrer TLE-Erweiterungen aus einer Datenbank](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [Deinstallieren von Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [Verwenden von PostgreSQL-Haken mit Ihren TLE-Erweiterungen](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [Verwendung benutzerdefinierter Datentypen in TLE](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [Funktionsreferenz für Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [Hakenreferenz für Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminologie
Sehen Sie sich das folgende Glossar und die in diesem Thema verwendeten Begriffe an, damit Sie Trusted Language Extensions besser verstehen.
**Trusted Language Extensions für PostgreSQL**
*Trusted Language Extensions für PostgreSQL* ist der offizielle Name des Open-Source-Entwicklungskits, das als `pg_tle`-Erweiterung verpackt ist. Es ist für die Verwendung in jedem PostgreSQL-System verfügbar. Weitere Informationen finden Sie unter [aws/pg\$1tle](https://github.com/aws/pg_tle) auf GitHub.
**Trusted Language Extensions**
*Trusted Language Extensions* ist der Kurzname für Trusted Language Extensions für PostgreSQL. Dieser verkürzte Name und seine Abkürzung (TLE) werden ebenfalls in dieser Dokumentation verwendet.
**Vertrauenswürdige Sprache**
Eine *vertrauenswürdige Sprache* ist eine Programmier- oder Skriptsprache mit bestimmten Sicherheitsattributen. Beispielsweise schränken vertrauenswürdige Sprachen in der Regel den Zugriff auf das Dateisystem und die Verwendung bestimmter Netzwerkeigenschaften ein. Das TLE-Entwicklungskit wurde entwickelt, um vertrauenswürdige Sprachen zu unterstützen. PostgreSQL unterstützt verschiedene Sprachen, die verwendet werden, um vertrauenswürdige oder nicht vertrauenswürdige Erweiterungen zu erstellen. Ein Beispiel finden Sie unter [Trusted and Untrusted PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html) in der PostgreSQL-Dokumentation. Wenn Sie eine Erweiterung mithilfe von Trusted Language Extensions erstellen, verwendet die Erweiterung von sich aus vertrauenswürdige Sprachmechanismen.
**TLE-Erweiterung**
Eine *TLE-Erweiterung* ist eine PostgreSQL-Erweiterung, die mithilfe des Trusted Language Extensions (TLE)-Entwicklungskits erstellt wurde.
# Anforderungen für die Verwendung von Trusted Language Extensions für PostgreSQL
Beachten Sie die folgenden Anforderungen für die Einrichtung und Verwendung des TLE-Entwicklungskits.
+ ** RDS-für-PostgreSQL Versionen** – Trusted Language Extensions wird nur von , RDS-für-PostgreSQL Versionen 13.12 und höheren 13-Versionen, 14.5 und höheren 14-Versionen und 15.2 und höheren Versionen unterstützt.
+ Wenn Sie Ihren Ihre Instance von RDS für PostgreSQL aktualisieren müssen, finden Sie weitere Informationen unter [Upgrades der DB-Engine von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
+ Wenn Sie noch keine DB-Instance von Amazon RDS für die Ausführung von PostgreSQL haben, können Sie eine/n erstellen. Weitere Informationen finden Sie unter DB-Instance von RDS für PostgreSQL siehe [Erstellen einer PostgreSQL-DB-Instance und Herstellen einer Verbindung](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md).
+ **Erfordert `rds_superuser`-Berechtigungen** – Um die `pg_tle`-Erweiterung einzurichten und zu konfigurieren, muss Ihre Datenbankbenutzerrolle über die Berechtigungen der `rds_superuser`-Rolle verfügen. Diese Rolle wird standardmäßig dem `postgres`-Benutzer zugewiesen, der den erstellt. DB-Instance von RDS für PostgreSQL
+ **Erfordert eine benutzerdefinierte DB-Parametergruppe** – Ihre DB-Instance von RDS für PostgreSQL muss mit einer benutzerdefinierten DB-Parametergruppe konfiguriert sein.
+ Wenn Ihre DB-Instance von RDS für PostgreSQL nicht mit einer benutzerdefinierten DB-Parametergruppe konfiguriert ist, sollten Sie eine erstellen und sie Ihrer DB-Instance von RDS für PostgreSQL zuordnen. Eine kurze Zusammenfassung der Schritte finden Sie unter [Erstellen und Anwenden einer benutzerdefinierten DB-Parametergruppe](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ Wenn Ihre DB-Instance von RDS für PostgreSQL bereits mit einer benutzerdefinierten DB-Parametergruppe konfiguriert ist, können Sie Trusted Language Extensions einrichten. Details hierzu finden Sie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
## Erstellen und Anwenden einer benutzerdefinierten DB-Parametergruppe
Verwenden Sie die folgenden Schritte, um eine benutzerdefinierte DB-Parametergruppe zu erstellen und Ihre DB-Instance von RDS für PostgreSQLInstance für ihre Verwendung zu konfigurieren.
### Konsole
**So erstellen Sie eine benutzerdefinierte DB-Parametergruppe und verwenden sie mit Ihrem )**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Menü von Amazon RDS „Parameter groups“ (Parametergruppen) aus.
1. Wählen Sie **Parametergruppe erstellen**.
1. Geben Sie auf der Seite **Parameter group details** Parametergruppendetails die folgenden Informationen ein.
+ Wählen Sie unter **Parameter group family** (Parametergruppenfamilie) die Option postgres14 aus.
+ Wählen Sie für **Type** (Typ) die Option DB Parameter Group (DB-Parametergruppe) aus.
+ Geben Sie Ihrer Parametergruppe unter **Group name** (Gruppenname) im Kontext Ihrer Operationen einen aussagekräftigen Namen.
+ Geben Sie unter **Description** (Beschreibung) eine nützliche Beschreibung ein, damit andere Mitglieder Ihres Teams sie leicht finden können.
1. Wählen Sie **Erstellen** aus. Ihre benutzerdefinierte DB-Parametergruppe wird in Ihrer AWS-Region erstellt. Sie können jetzt Ihre DB-Instance von RDS für PostgreSQL ändern, um sie zu verwenden, indem Sie die nächsten Schritte ausführen.
1. Wählen Sie **Databases** (Datenbanken) im Amazon-RDS-Menü aus.
1. Wählen Sie aus der Liste die DB-Instance von RDS für PostgreSQL für die Verwendung mit TLE aus und klicken Sie dann auf **Modify** (Ändern).
1. Suchen Sie auf der Seite zum Suchen Sie auf der Seite zum Ändern der DB-Instance-Einstellungen im Abschnitt „Additional configuration“ (Zusätzliche Konfiguration) nach **Database options** (Datenbankoptionen) und wählen Sie Ihre benutzerdefinierte DB-Parametergruppe in der Auswahl aus.
1. Wählen Sie **Continue** (Weiter) aus, um die Änderung zu speichern.
1. Wählen Sie **Apply immediately** (Sofort anwenden) aus, damit Sie die Einrichtung der DB-Instance von RDS für PostgreSQL zur Verwendung von TLE fortsetzen können.
Informationen zum weiteren Einrichten Ihres Systems für Trusted Language Extensions finden Sie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Weitere Informationen zum Arbeiten mit DB-Parametergruppen siehe [DB-Parametergruppen für DB-Instances von Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
### AWS CLI
Sie können die Angabe des `--region`-Arguments vermeiden, wenn Sie CLI-Befehle verwenden, indem Sie Ihre AWS CLI mit Ihrer standardmäßigen AWS-Region konfigurieren. Weitere Informationen finden Sie unter [Konfigurationsgrundlagen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *AWS Command Line Interface -Benutzerhandbuch*.
**So erstellen Sie eine benutzerdefinierte DB-Parametergruppe und verwenden sie mit Ihrem )**
1. Verwenden Sie den [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI Befehl, um eine benutzerdefinierte DB-Parametergruppe basierend auf postgres14 für Ihre zu erstellen. AWS-Region
Für Linux, macOS oder Unix:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Für Windows:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Ihre benutzerdefinierte DB-Parametergruppe ist in Ihrer AWS-Region verfügbar. Sie können also die DB-Instance von RDS für PostgreSQL ändern, um sie zu verwenden.
1. Verwenden Sie den [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI Befehl, um Ihre benutzerdefinierte DB-Parametergruppe auf anzuwenden. Ihre RDS für PostgreSQL-DB-Instance. Mit diesem Befehl wird die aktive Instance sofort neu gestartet.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Für Windows:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Informationen zum weiteren Einrichten Ihres Systems für Trusted Language Extensions finden Sie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
# Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance von RDS für PostgreSQL einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Für diese Schritte können Sie die AWS-Managementkonsole oder die AWS CLI verwenden.
Wenn Sie Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL einrichten, installieren Sie sie in einer bestimmten Datenbank, damit sie von den Datenbankbenutzern verwendet werden kann, die über Berechtigungen für diese Datenbank verfügen.
## Konsole
**So richten Sie Trusted Language Extensions ein**
Führen Sie die folgenden Schritte mit einem Konto aus, das Mitglied der `rds_superuser`-Gruppe (Rolle) ist.
1. Melden Sie sich bei der AWS-Managementkonsole an und ö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 Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre DB-Instance von RDS für PostgreSQL Suchen Sie in den Instance-Details den Link **Parameter group** (Parametergruppe).
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Instance von RDS für PostgreSQL
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den `shared_preload_libraries`-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie `pg_tle` der Liste im Feld **Values** (Werte) hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
![\[Abbildung des shared_preload_libraries-Parameters mit hinzugefügter pg_tle-Erweiterung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Starten Sie die DB-Instance von RDS für PostgreSQL neu, damit Ihre Änderung des `shared_preload_libraries`-Parameters wirksam wird.
1. Wenn die Instance verfügbar ist, überprüfen Sie, ob `pg_tle` initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. Wenn die `pg_tle`-Erweiterung initialisiert ist, können Sie jetzt die Erweiterung erstellen.
```
CREATE EXTENSION pg_tle;
```
Sie können überprüfen, ob die Erweiterung installiert wurde, indem Sie den folgenden `psql`-Metabefehl verwenden.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Weisen Sie der `pgtle_admin`-Rolle dem primären Benutzernamen zu, den Sie bei der Einrichtung für Ihre DB-Instance von RDS für PostgreSQL erstellt haben. Wenn Sie die Standardeinstellung akzeptiert haben, lautet der Wert `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
Wie in folgendem Beispiel veranschaulicht, können Sie anhand des `psql`-Metabefehls überprüfen, ob die Gewährung erfolgt ist. In der Ausgabe werden nur die Rollen `pgtle_admin` und `postgres` angezeigt. Weitere Informationen finden Sie unter [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Schließen Sie die `psql`-Sitzung mit dem `\q`-Metabefehl.
```
\q
```
Informationen zum Erstellen von TLE-Erweiterungen finden Sie unter [Beispiel: Erstellen einer Trusted Language Extension mit SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
Sie können die Angabe des `--region`-Arguments vermeiden, wenn Sie CLI-Befehle verwenden, indem Sie Ihre AWS CLI mit Ihrer standardmäßigen AWS-Region konfigurieren. Weitere Informationen finden Sie unter [ Konfigurationsgrundlagen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *AWS Command Line Interface Benutzerhandbuch*.
**So richten Sie Trusted Language Extensions ein**
1. Verwenden Sie den AWS CLI-Befehl [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html), um dem `shared_preload_libraries`-Parameter `pg_tle` hinzuzufügen.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den AWS CLI-Befehl [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance), um die DB-Instance von RDS für PostgreSQL neu zu starten und die `pg_tle`-Bibliothek zu initialisieren.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, können Sie überprüfen, ob `pg_tle` initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
Sobald `pg_tle` initialisiert ist, können Sie die Erweiterung erstellen.
```
CREATE EXTENSION pg_tle;
```
1. Weisen Sie der `pgtle_admin`-Rolle dem primären Benutzernamen zu, den Sie bei der Einrichtung für Ihre DB-Instance von RDS für PostgreSQL erstellt haben. Wenn Sie die Standardeinstellung akzeptiert haben, lautet der Wert `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Schließen Sie die `psql`-Sitzung wie folgt.
```
labdb=> \q
```
Informationen zum Erstellen von TLE-Erweiterungen finden Sie unter [Beispiel: Erstellen einer Trusted Language Extension mit SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Übersicht über Trusted Language Extensions für PostgreSQL
Trusted Language Extensions für PostgreSQL ist eine PostgreSQL-Erweiterung, die Sie in Ihrer DB-Instance von RDS für PostgreSQL auf die gleiche Weise installieren, wie Sie andere PostgreSQL-Erweiterungen einrichten. In der folgenden Abbildung einer Beispieldatenbank im pgAdmin-Client-Tool können Sie einige der Komponenten sehen, aus denen die `pg_tle`-Erweiterung besteht.
![\[Die Abbildung zeigt einige der Komponenten des TLE-Entwicklungskits.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
Sie können die folgenden Details sehen.
1. Das Entwicklungskit von Trusted Language Extensions (TLE) für PostgreSQL ist als `pg_tle`-Erweiterung verpackt. Daher wird `pg_tle` den verfügbaren Erweiterungen für die Datenbank hinzugefügt, in der es installiert ist.
1. TLE hat ein eigenes Schema, `pgtle`. Dieses Schema enthält Hilfsfunktionen (3) für die Installation und Verwaltung der von Ihnen erstellten Erweiterungen.
1. TLE bietet über ein Dutzend Hilfsfunktionen für die Installation, Registrierung und Verwaltung Ihrer Erweiterungen. Weitere Informationen zu diesen Funktionen finden Sie unter [Funktionsreferenz für Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md).
Das `pg_tle`-Erweiterungspaket umfasst außerdem folgende Komponenten:
+ **Die `pgtle_admin`-Rolle** – Die `pgtle_admin`-Rolle wird erstellt, wenn die `pg_tle`-Erweiterung installiert wird. Diese Rolle ist privilegiert und sollte entsprechend behandelt werden. Es wird dringend empfohlen, bei der Gewährung der `pgtle_admin`-Rolle an Datenbankbenutzer dem Prinzip der *geringsten Berechtigung* zu folgen. Mit anderen Worten, weisen Sie die `pgtle_admin`-Rolle nur Datenbankbenutzern zu, die berechtigt sind, neue TLE-Erweiterungen zu erstellen, zu installieren und zu verwalten, wie z. b. `postgres`.
+ **Die `pgtle.feature_info`-Tabelle** – Die `pgtle.feature_info`-Tabelle ist eine geschützte Tabelle, die Informationen über Ihre TLEs, Haken und die von ihnen verwendeten benutzerdefinierten gespeicherten Prozeduren und Funktionen enthält. Wenn Sie über `pgtle_admin`-Berechtigungen verfügen, verwenden Sie die folgenden Funktionen von Trusted Language Extensions, um diese Informationen in der Tabelle hinzuzufügen und zu aktualisieren.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Erstellen von TLE-Erweiterungen für RDS für PostgreSQL
Sie können alle Erweiterungen, die Sie mit TLE erstellen, in in jeder beliebigen DB-Instance von RDS für PostgreSQL installieren, sofern die die `pg_tle`-Erweiterung darauf installiert ist. Die `pg_tle`-Erweiterung ist auf die PostgreSQL-Datenbank beschränkt, in der sie installiert ist. Die Erweiterungen, die Sie mit TLE erstellen, sind auf dieselbe Datenbank ausgelegt.
Verwenden Sie die verschiedenen `pgtle`-Funktionen, um den Code zu installieren, aus dem Ihre TLE-Erweiterung besteht. Die folgenden Funktionen von Trusted Language Extensions erfordern alle die `pgtle_admin`-Rolle.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Beispiel: Erstellen einer Trusted Language Extension mit SQL
Das folgende Beispiel zeigt Ihnen, wie Sie eine TLE-Erweiterung namens `pg_distance` erstellen, die einige SQL-Funktionen für die Berechnung von Entfernungen mit verschiedenen Formeln enthält. In der Liste finden Sie die Funktion zur Berechnung der Manhattan-Distanz und die Funktion zur Berechnung des euklidischen Abstands. Weitere Informationen zum Unterschied zwischen diesen Formeln finden Sie unter [Taxi-Geometerie](https://en.wikipedia.org/wiki/Taxicab_geometry) und [Euklidische Geometrie](https://en.wikipedia.org/wiki/Euclidean_geometry) in Wikipedia.
Sie können dieses Beispiel in Ihrer eigenen DB-Instance von RDS für PostgreSQL verwenden, wenn Sie die `pg_tle`-Erweiterung wie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md) beschrieben eingerichtet haben.
**Anmerkung**
Sie benötigen die Rechte der `pgtle_admin`-Rolle, um dieses Verfahren ausführen zu können.
**So erstellen Sie die TLE-Beispielerweiterung**
In den folgenden Schritten wird eine Beispieldatenbank namens `labdb` verwendet. Diese Datenbank gehört dem `postgres`-Hauptbenutzer. Die `postgres`-Rolle verfügt auch über die Berechtigungen der `pgtle_admin`-Rolle.
1. Verwenden Sie `psql`, um eine Verbindung mit der herzustellen. DB-Instance von RDS für PostgreSQL
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Erstellen Sie eine TLE-Erweiterung mit dem Namen `pg_distance`, indem Sie den folgenden Code kopieren und in Ihre `psql`-Sitzungskonsole einfügen.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
Die Ausgabe sollte folgendermaßen aussehen.
```
install_extension
---------------
t
(1 row)
```
Die Artefakte, aus denen die `pg_distance`-Erweiterung besteht, sind jetzt in Ihrer Datenbank installiert. Zu diesen Artefakten gehören die Steuerdatei und der Code für die Erweiterung. Diese Elemente müssen vorhanden sein, damit die Erweiterung mit dem `CREATE EXTENSION`-Befehl erstellt werden kann. Mit anderen Worten, Sie müssen die Erweiterung nach wie vor erstellen, um ihre Funktionen Datenbankbenutzern zur Verfügung zu stellen.
1. Um die Erweiterung zu erstellen, verwenden Sie den `CREATE EXTENSION`-Befehl wie für jede andere Erweiterung. Wie bei anderen Erweiterungen muss der Datenbankbenutzer über die `CREATE`-Berechtigungen in der Datenbank verfügen.
```
CREATE EXTENSION pg_distance;
```
1. Um die `pg_distance`-TLE-Erweiterung zu testen, können Sie sie verwenden, um die [Manhattan-Distanz](https://en.wikipedia.org/wiki/Taxicab_geometry) zwischen vier Punkten zu berechnen.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
Um den [euklidischen Abstand](https://en.wikipedia.org/wiki/Euclidean_geometry) zwischen derselben Menge von Punkten zu berechnen, können Sie Folgendes verwenden.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
Die `pg_distance`-Erweiterung lädt die Funktionen in die Datenbank und stellt sie allen Benutzern mit Berechtigungen für die Datenbank zur Verfügung.
## Ändern Ihrer TLE-Erweiterung
Um die Abfrageleistung für die in dieser TLE-Erweiterung enthaltenen Funktionen zu verbessern, fügen Sie ihren Spezifikationen die beiden folgenden PostgreSQL-Attribute hinzu.
+ `IMMUTABLE` – Das `IMMUTABLE`-Attribut stellt sicher, dass der Abfrageoptimierer Optimierungen verwenden kann, um die Antwortzeiten von Abfragen zu verbessern. Weitere Informationen finden Sie im Abschnitt [Volatilitätskategorien von Funktionen](https://www.postgresql.org/docs/current/xfunc-volatility.html) der PostgreSQL-Dokumentation.
+ `PARALLEL SAFE` – Das `PARALLEL SAFE`-Attribut ist ein weiteres Attribut, das es PostgreSQL ermöglicht, die Funktion im Parallelmodus auszuführen. Weitere Informationen finden Sie im Abschnitt [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) der PostgreSQL-Dokumentation.
Im folgenden Beispiel können Sie sehen, wie die `pgtle.install_update_path`-Funktion verwendet wird, um diese Attribute jeder Funktion hinzuzufügen, um eine Version `0.2` der `pg_distance`-TLE-Erweiterung zu erstellen. Weitere Informationen zu dieser Funktion finden Sie unter [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). Sie benötigen die `pgtle_admin` Rolle, um diese Aufgabe auszuführen.
**So aktualisieren Sie eine vorhandene TLE-Erweiterung und geben die Standardversion an**
1. Stellen Sie über `psql` oder ein anderes Client-Tool wie pgAdmin eine Verbindung mit der der DB-Instance von RDS für PostgreSQL her.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Ändern Sie die vorhandene TLE-Erweiterung, indem Sie den folgenden Code kopieren und in Ihre `psql`-Sitzungskonsole einfügen.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
Es wird eine Antwort ähnlich dem folgenden Beispiel angezeigt.
```
install_update_path
---------------------
t
(1 row)
```
Sie können diese Version der Erweiterung zur Standardversion machen, sodass Datenbankbenutzer keine Version angeben müssen, wenn sie die Erweiterung in ihrer Datenbank erstellen oder aktualisieren.
1. Um anzugeben, dass die modifizierte Version (Version 0.2) Ihrer TLE-Erweiterung die Standardversion ist, verwenden Sie die `pgtle.set_default_version`-Funktion wie im folgenden Beispiel gezeigt.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
Weitere Informationen zu dieser Funktion finden Sie unter [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. Wenn der Code vorhanden ist, können Sie die installierte TLE-Erweiterung wie gewohnt aktualisieren, indem Sie den `ALTER EXTENSION ... UPDATE`-Befehl verwenden, wie hier gezeigt:
```
ALTER EXTENSION pg_distance UPDATE;
```
# Löschen Ihrer TLE-Erweiterungen aus einer Datenbank
Sie können Ihre TLE-Erweiterungen löschen, indem Sie den `DROP EXTENSION`-Befehl auf die gleiche Weise wie für andere PostgreSQL-Erweiterungen verwenden. Durch das Löschen der Erweiterung werden die Installationsdateien, aus denen die Erweiterung besteht, nicht entfernt, sodass Benutzer die Erweiterung neu erstellen können. Gehen Sie wie folgt in zwei Schritten vor, um die Erweiterung und ihre Installationsdateien zu entfernen.
**So löschen Sie die TLE-Erweiterung und entfernen ihre Installationsdateien**
1. Stellen Sie über `psql` oder ein anderes Client-Tool eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Löschen Sie die Erweiterung so wie jede andere PostgreSQL-Erweiterung.
```
DROP EXTENSION your-TLE-extension
```
Wenn Sie die `pg_distance`-Erweiterung beispielsweise wie in beschrieben [Beispiel: Erstellen einer Trusted Language Extension mit SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example) erstellen, können Sie die Erweiterung wie folgt löschen.
```
DROP EXTENSION pg_distance;
```
Es wird eine Ausgabe angezeigt, die bestätigt, dass die Erweiterung gelöscht wurde, wie im Folgenden gezeigt.
```
DROP EXTENSION
```
Zu diesem Zeitpunkt ist die Erweiterung in der Datenbank nicht mehr aktiv. Die Installationsdateien und die Steuerdatei sind jedoch nach wie vor in der Datenbank verfügbar, sodass Datenbankbenutzer die Erweiterung erneut erstellen können, wenn sie möchten.
+ Wenn Sie die Erweiterungsdateien intakt lassen möchten, damit Datenbankbenutzer Ihre TLE-Erweiterung erstellen können, können Sie an dieser Stelle aufhören.
+ Wenn Sie alle Dateien, aus denen die Erweiterung besteht, entfernen möchten, fahren Sie mit dem nächsten Schritt fort.
1. Verwenden Sie die `pgtle.uninstall_extension`-Funktion, um alle Installationsdateien für Ihre Erweiterung zu entfernen. Diese Funktion entfernt dne gesamten Code und die Steuerdateien für Ihre Erweiterung.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
Verwenden Sie beispielsweise den folgenden Befehl, um alle `pg_distance`-Installationsdateien zu entfernen.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Deinstallieren von Trusted Language Extensions für PostgreSQL
Wenn Sie keine eigenen TLE-Erweiterungen mehr mit TLE erstellen möchten, können Sie die `pg_tle`-Erweiterung löschen und alle Artefakte entfernen. Diese Aktion beinhaltet das Löschen aller TLE-Erweiterungen in der Datenbank und das Entfernen des`pgtle`-Schemas.
**So löschen Sie die `pg_tle`-Erweiterung und ihr Schema aus einer Datenbank**
1. Stellen Sie über `psql` oder ein anderes Client-Tool eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Löschen Sie die `pg_tle`-Erweiterung aus der Datenbank. Wenn Ihre eigenen TLE-Erweiterungen noch in der Datenbank laufen, müssen Sie diese Erweiterungen ebenfalls löschen. Dazu können Sie das `CASCADE`-Schlüsselwort verwenden, wie im Folgenden gezeigt.
```
DROP EXTENSION pg_tle CASCADE;
```
Wenn die `pg_tle`-Erweiterung in der Datenbank nicht mehr aktiv ist, müssen Sie das `CASCADE`-Schlüsselwort nicht verwenden.
1. Löschen Sie das `pgtle`-Schema. Mit dieser Aktion werden alle Verwaltungsfunktionen aus der Datenbank entfernt.
```
DROP SCHEMA pgtle CASCADE;
```
Der Befehl gibt nach Abschluss des Vorgangs Folgendes zurück.
```
DROP SCHEMA
```
Die `pg_tle`-Erweiterung, ihr Schema und ihre Funktionen sowie alle Artefakte werden entfernt. Um neue Erweiterungen mit TLE zu erstellen, führen Sie den Einrichtungsvorgang erneut durch. Weitere Informationen finden Sie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
# Verwenden von PostgreSQL-Haken mit Ihren TLE-Erweiterungen
Ein *Haken* ist ein in PostgreSQL verfügbarer Callback-Mechanismus, der es Entwicklern ermöglicht, benutzerdefinierte Funktionen oder andere Routinen während regulärer Datenbankoperationen aufzurufen. Das TLE-Entwicklungskit unterstützt PostgreSQL-Haken, sodass Sie benutzerdefinierte Funktionen zur Laufzeit in das PostgreSQL-Verhalten integrieren können. Sie können beispielsweise einen Haken verwenden, um den Authentifizierungsprozess mit Ihrem eigenen benutzerdefinierten Code zu verknüpfen oder um den Planungs- und Ausführungsprozess für Abfragen Ihren spezifischen Bedürfnissen entsprechend anzupassen.
Ihre TLE-Erweiterungen können Haken verwenden. Wenn ein Haken einen globalen Gültigkeitsbereich hat, gilt er für alle Datenbanken. Wenn Ihre TLE-Erweiterung einen globalen Haken verwendet, müssen Sie Ihre TLE-Erweiterung daher in allen Datenbanken erstellen, auf die Ihre Benutzer zugreifen können.
Wenn Sie die `pg_tle`-Erweiterung verwenden, um Ihre eigenen Trusted Language Extensions zu erstellen, können Sie die verfügbaren Haken einer SQL-API verwenden, um die Funktionen Ihrer Erweiterung zu erstellen. Sie sollten alle Haken bei `pg_tle` registrieren. Für einige Haken müssen Sie möglicherweise auch verschiedene Konfigurationsparameter festlegen. Der `passcode`-Prüfungshaken kann beispielsweise auf ein, aus oder erforderlich festgelegt werden. Weitere Hinweise zu den spezifischen Anforderungen für verfügbare `pg_tle`-Haken finden Sie unter [Hakenreferenz für Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Beispiel: Erstellen einer Erweiterung, die einen PostgreSQL-Haken verwendet
Das in diesem Abschnitt besprochene Beispiel verwendet einen PostgreSQL-Haken, um das bei bestimmten SQL-Vorgängen angegebene Passwort zu überprüfen, und verhindert, dass Datenbankbenutzer ihre Passwörter auf eines der in der `password_check.bad_passwords`-Tabelle enthaltenen Passwörter festlegen. Die Tabelle enthält die zehn am häufigsten verwendeten, aber leicht zu knackenden Optionen für Passwörter.
Um dieses Beispiel in Ihrer DB-Instance von RDS für PostgreSQL einzurichten, müssen Sie Trusted Language Extensions bereits installiert haben. Details hierzu finden Sie unter [Einrichten von Trusted Language Extensions in Ihrer DB-Instance von RDS für PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**So richten Sie das Beispiel für einen Haken für die Passwortüberprüfung ein**
1. Verwenden Sie `psql`, um eine Verbindung mit der herzustellen. DB-Instance von RDS für PostgreSQL
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Kopieren Sie den Code von [Liste der Hakencodes für die Passwortüberprüfung](#PostgreSQL_trusted_language_extension-example-hook_code_listing) und fügen Sie ihn in Ihre Datenbank ein.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
Wenn die Erweiterung in Ihre Datenbank geladen wurde, sehen Sie eine Ausgabe ähnlich wie die folgende.
```
install_extension
-------------------
t
(1 row)
```
1. Während Sie noch mit der Datenbank verbunden sind, können Sie jetzt die Erweiterung erstellen.
```
CREATE EXTENSION my_password_check_rules;
```
1. Mit dem folgenden `psql`-Metabefehl können Sie bestätigen, dass die Erweiterung in der Datenbank erstellt wurde.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Öffnen Sie eine weitere Terminalsitzung, um mit der AWS CLI zu arbeiten. Sie müssen Ihre benutzerdefinierte DB-Parametergruppe ändern, um den Haken für die Passwortüberprüfung zu aktivieren. Verwenden Sie dazu den CLI-Befehl [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html), wie im folgenden Beispiel gezeigt.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Wenn der Parameter erfolgreich aktiviert wurde, wird eine Ausgabe wie die folgende angezeigt.
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
Es kann einige Minuten dauern, bis die Änderung der Parametergruppe wirksam wird. Dieser Parameter ist jedoch dynamisch, sodass Sie die DB-Instance von RDS für PostgreSQL nicht neu starten müssen, damit die Einstellung wirksam wird.
1. Öffnen Sie die `psql`-Sitzung und fragen Sie die Datenbank ab, um zu überprüfen, ob der password\$1check-Haken aktiviert wurde.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
Der Haken für die Passwortüberprüfung ist jetzt aktiv. Sie können dies testen, indem Sie eine neue Rolle erstellen und eines der schwachen Passwörter verwenden, wie im folgenden Beispiel gezeigt.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
Die Ausgabe wurde zur besseren Lesbarkeit formatiert.
Das folgende Beispiel zeigt, dass das interaktive `pgsql`-Metabefehlverhalten `\password` auch vom password\$1check-Haken beeinflusst wird.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
Sie können diese TLE-Erweiterung löschen und ihre Quelldateien deinstallieren, wenn Sie möchten. Weitere Informationen finden Sie unter [Löschen Ihrer TLE-Erweiterungen aus einer DatenbankLöschen Ihrer TLE-Erweiterungen aus einer Datenbank](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Liste der Hakencodes für die Passwortüberprüfung
Der hier gezeigte Beispielcode definiert die Spezifikation für die `my_password_check_rules`-TLE-Erweiterung. Wenn Sie diesen Code kopieren und in Ihre Datenbank einfügen, wird der Code für die `my_password_check_rules`-Erweiterung in die Datenbank geladen und der `password_check`-Haken für die Verwendung durch die Erweiterung registriert.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Verwendung benutzerdefinierter Datentypen in TLE
PostgreSQL unterstützt Befehle zur Registrierung neuer Basistypen (auch bekannt als Skalartypen), um komplexe Datenstrukturen in Ihrer Datenbank effizient zu handhaben. Mit einem Basistyp können Sie anpassen, wie die Daten intern gespeichert werden und wie sie in und aus einer externen Textdarstellung konvertiert werden. Diese benutzerdefinierten Datentypen sind nützlich, wenn PostgreSQL erweitert wird, um funktionale Domains zu unterstützen, in denen ein integrierter Typ wie Zahl oder Text keine ausreichende Suchsemantik bieten kann.
Mit RDS für PostgreSQL können Sie benutzerdefinierte Datentypen in Ihrer Trusted Languages Extension erstellen und Funktionen definieren, die SQL- und Indexoperationen für diese neuen Datentypen unterstützen. Benutzerdefinierte Datentypen sind für die folgenden Versionen verfügbar:
+ RDS für PostgreSQL 15.4 und höhere 15-Versionen
+ RDS für PostgreSQL 14.9 und höhere 14-Versionen
+ RDS für PostgreSQL 13.12 und höhere 13-Versionen
Weitere Informationen finden Sie unter [Trusted Language Base-Typen](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md).
# Funktionsreferenz für Trusted Language Extensions für PostgreSQL
Sehen Sie sich die folgende Referenzdokumentation zu den Funktionen an, die in Trusted Language Extensions für PostgreSQL verfügbar sind. Verwenden Sie diese Funktionen, um Ihre *TLE-Erweiterungen*, d. h. die PostgreSQL-Erweiterungen, die Sie mit dem Trusted Language Extensions Development Kit entwickeln, zu installieren, zu registrieren, zu aktualisieren und zu verwalten.
**Topics**
+ [pgtle.available\$1extensions](#pgtle.available_extensions)
+ [pgtle.available\$1extension\$1versions](#pgtle.available_extension_versions)
+ [pgtle.extension\$1update\$1paths](#pgtle.extension_update_paths)
+ [pgtle.install\$1extension](#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](#pgtle.install_update_path)
+ [pgtle.register\$1feature](#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
Die `pgtle.available_extensions`-Funktion ist eine Mengenrückgabefunktion. Sie gibt alle verfügbaren TLE-Erweiterungen in der Datenbank zurück. Jede zurückgegebene Zeile enthält Informationen zu einer einzelnen TLE-Erweiterung.
### Funktionsprototyp
```
pgtle.available_extensions()
```
### Rolle
Keine.
### Argumente
Keine.
### Output
+ `name` – Der Name der TLE-Erweiterung.
+ `default_version` – Die Version der TLE-Erweiterung, die verwendet werden soll, wenn `CREATE EXTENSION` ohne Angabe einer Version aufgerufen wird.
+ `description` – Eine ausführlichere Beschreibung der TLE-Erweiterung.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
Die `available_extension_versions`-Funktion ist eine Mengenrückgabefunktion. Sie gibt eine Liste aller verfügbaren TLE-Erweiterungen und deren Versionen zurück. Jede Zeile enthält Informationen zu einer bestimmten Version der angegebenen TLE-Erweiterung, einschließlich der Frage, ob für sie eine bestimmte Rolle erforderlich ist.
### Funktionsprototyp
```
pgtle.available_extension_versions()
```
### Rolle
Keine.
### Argumente
Keine.
### Output
+ `name` – Der Name der TLE-Erweiterung.
+ `version` – Die Version der TLE-Erweiterung.
+ `superuser` – Dieser Wert ist für Ihre TLE-Erweiterungen immer `false`. Die Berechtigungen, die zum Erstellen oder Aktualisieren der TLE-Erweiterung erforderlich sind, entsprechen denen, die für die Erstellung anderer Objekte in der angegebenen Datenbank notwendig sind.
+ `trusted` – Dieser Wert ist für eine TLE-Erweiterung immer `false`.
+ `relocatable` – Dieser Wert ist für eine TLE-Erweiterung immer `false`.
+ `schema` – Gibt den Namen des Schemas an, in dem die TLE-Erweiterung installiert ist.
+ `requires` – Ein Array, das die Namen anderer Erweiterungen enthält, die für diese TLE-Erweiterung benötigt werden.
+ `description` – Eine ausführliche Beschreibung der TLE-Erweiterung.
Weitere Informationen zu Ausgabewerten finden Sie unter [Packaging Related Objects into an Extension > Extension Files](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) in der PostgreSQL-Dokumentation.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
Die `extension_update_paths`-Funktion ist eine Mengenrückgabefunktion. Sie gibt eine Liste aller möglichen Aktualisierungspfade für eine TLE-Erweiterung zurück. Jede Zeile enthält die verfügbaren Upgrades oder Downgrades für diese TLE-Erweiterung.
### Funktionsprototyp
```
pgtle.extension_update_paths(name)
```
### Rolle
Keine.
### Argumente
`name` – Der Name der TLE-Erweiterung, von der die Upgrade-Pfade abgerufen werden sollen.
### Output
+ `source` – Die Quellversion für eine Aktualisierung.
+ `target` – Die Zielversion für eine Aktualisierung.
+ `path` – Der Upgrade-Pfad, der verwendet wird, um eine TLE-Erweiterung von der `source`-Version auf die `target`-Version zu aktualisieren, zum Beispiel `0.1--0.2`.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
Mit dieser `install_extension`-Funktion können Sie die Artefakte, aus denen Ihre TLE-Erweiterung besteht, in der Datenbank installieren. Anschließend können sie mit dem `CREATE EXTENSION`-Befehl erstellt werden.
### Funktionsprototyp
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Rolle
Keine.
### Argumente
+ `name` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `version` – Die Version der TLE-Erweiterung.
+ `description` – Eine ausführliche Beschreibung der TLE-Erweiterung. Diese Beschreibung wird im Feld `comment` in `pgtle.available_extensions()` angezeigt.
+ `ext` – Der Inhalt der TLE-Erweiterung. Dieser Wert enthält Objekte wie Funktionen.
+ `requires` – Ein optionaler Parameter, der Abhängigkeiten für diese TLE-Erweiterung angibt. Die `pg_tle`-Erweiterung wird automatisch als Abhängigkeit hinzugefügt.
Viele dieser Argumente entsprechen denen, die in einer Erweiterungskontrolldatei für die Installation einer PostgreSQL-Erweiterung im Dateisystem einer PostgreSQL-Instance enthalten sind. Weitere Informationen finden Sie unter [Extension Files](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) in [Packaging Related Objects in a Extension](https://www.postgresql.org/docs/current/extend-extensions.html) in der PostgreSQL-Dokumentation.
### Output
Diese Funktion gibt bei Erfolg `OK` und bei Fehler `NULL` zurück.
+ `OK` – Die TLE-Erweiterung wurde erfolgreich in der Datenbank installiert.
+ `NULL` – Die TLE-Erweiterung wurde nicht erfolgreich in der Datenbank installiert.
### Verwendungsbeispiel
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
Die `install_update_path`-Funktion stellt einen Aktualisierungspfad zwischen zwei verschiedenen Versionen einer TLE-Erweiterung bereit. Mit dieser Funktion können Benutzer Ihrer TLE-Erweiterung ihre Version mithilfe der `ALTER EXTENSION ... UPDATE`-Syntax aktualisieren.
### Funktionsprototyp
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `name` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `fromvers` – Die Quellversion der TLE-Erweiterung für das Upgrade.
+ `tovers` – Die Zielversion der TLE-Erweiterung für das Upgrade.
+ `ext` – Der Inhalt der Aktualisierung. Dieser Wert enthält Objekte wie Funktionen.
### Output
Keine.
### Verwendungsbeispiel
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
Die `register_feature`-Funktion fügt der `pgtle.feature_info`-Tabelle das angegebene interne PostgreSQL-Feature hinzu. PostgreSQL-Haken sind ein Beispiel für ein internes PostgreSQL-Feature. Das Trusted Language Extensions Development Kit unterstützt die Verwendung von PostgreSQL-Haken. Derzeit unterstützt diese Funktion das folgende Feature.
+ `passcheck` – Registriert den Haken für die Passwortüberprüfung bei Ihrer Prozedur oder Funktion, die das Verhalten von PostgreSQL bei der Passwortüberprüfung anpasst.
### Funktionsprototyp
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Rolle
`pgtle_admin`
### Argumente
+ `proc` – Der Name einer gespeicherten Prozedur oder Funktion, die für das Feature verwendet werden soll.
+ `feature` – Der Name des `pg_tle`-Features (z. B. `passcheck`), das für die Funktion registriert werden soll.
### Output
Keine.
### Verwendungsbeispiel
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
Die `pgtle.register_feature_if_not_exists`-Funktion fügt der `pgtle.feature_info`-Tabelle das angegebene PostgreSQL-Feature hinzu und identifiziert die TLE-Erweiterung oder eine andere Prozedur oder Funktion, die das Feature verwendet. Weitere Informationen zu Haken und Trusted Language Extensions finden Sie unter [Verwenden von PostgreSQL-Haken mit Ihren TLE-Erweiterungen](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Funktionsprototyp
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Rolle
`pgtle_admin`
### Argumente
+ `proc` – Der Name einer gespeicherten Prozedur oder Funktion, die die Logik (Code) enthält, die als Feature für Ihre TLE-Erweiterung verwendet werden soll. Beispielsweise der `pw_hook`-Code.
+ `feature` – Der Name des PostgreSQL-Features, das für die TLE-Funktion registriert werden soll. Derzeit ist der `passcheck`-Haken das einzige verfügbare Feature. Weitere Informationen finden Sie unter [Haken zur Passwortüberprüfung (Passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
Gibt `true` zurück, nachdem das Feature für die angegebene Erweiterung registriert wurde. Gibt `false` zurück, wenn das Feature bereits registriert ist.
### Verwendungsbeispiel
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
Mit der `set_default_version`-Funktion können Sie eine `default_version` für Ihre TLE-Erweiterung angeben. Mit dieser Funktion können Sie einen Upgrade-Pfad definieren und die Version als Standard für Ihre TLE-Erweiterung festlegen. Wenn Datenbankbenutzer Ihre TLE-Erweiterung in den Befehlen `CREATE EXTENSION` und `ALTER EXTENSION ... UPDATE` angeben, wird diese Version Ihrer TLE-Erweiterung in der Datenbank für diesen Benutzer erstellt.
Diese Funktion gibt bei Erfolg `true` zurück. Wenn die im `name`-Argument angegebene TLE-Erweiterung nicht vorhanden ist, gibt die Funktion einen Fehler zurück. Entsprechend wird ein Fehler zurückgegeben, wenn die `version` der TLE-Erweiterung nicht existiert.
### Funktionsprototyp
```
pgtle.set_default_version(name text, version text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `name` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `version` – Die Version der TLE-Erweiterung, für die die Standardeinstellung festgelegt werden soll.
### Output
+ `true`– Wenn die Standardversion erfolgreich festgelegt wurde, gibt die Funktion `true` zurück.
+ `ERROR` – Gibt eine Fehlermeldung zurück, wenn eine TLE-Erweiterung mit dem angegebenen Namen oder der angegebenen Version nicht existiert.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(name)
Die `uninstall_extension`-Funktion entfernt alle Versionen einer TLE-Erweiterung aus einer Datenbank. Diese Funktion verhindert, dass die TLE-Erweiterung durch künftige Aufrufe von `CREATE EXTENSION` installiert wird. Wenn die TLE-Erweiterung in der Datenbank nicht existiert, wird ein Fehler ausgelöst.
Die `uninstall_extension`-Funktion löscht die TLE-Erweiterung jedoch nicht, wenn diese derzeit in der Datenbank aktiv ist. Zum Löschen einer TLE-Erweiterung, die derzeit aktiv ist, müssen Sie explizit `DROP EXTENSION` aufrufen, um sie zu entfernen.
### Funktionsprototyp
```
pgtle.uninstall_extension(extname text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `extname` – Der Name der zu deinstallierenden TLE-Erweiterung. Dieser Name ist derselbe, der mit `CREATE EXTENSION` verwendet wurde, um die TLE-Erweiterung zur Verwendung in einer bestimmten Datenbank zu laden.
### Output
Keine.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension(name, version)
Die `uninstall_extension(name, version)`-Funktion entfernt die angegebene Version der TLE-Erweiterung aus der Datenbank. Diese Funktion verhindert, dass `CREATE EXTENSION` und `ALTER EXTENSION` eine TLE-Erweiterung installieren oder auf die angegebene Version aktualisieren. Diese Funktion entfernt außerdem alle Aktualisierungspfade für die angegebene Version der TLE-Erweiterung. Diese Funktion deinstalliert die TLE-Erweiterung jedoch nicht, wenn diese derzeit in der Datenbank aktiv ist. Sie müssen explizit `DROP EXTENSION` aufrufen, um die TLE-Erweiterung zu entfernen. Informationen zur Deinstallation aller Versionen einer TLE-Erweiterung finden Sie unter [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name).
### Funktionsprototyp
```
pgtle.uninstall_extension(extname text, version text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `extname` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `version` – Die Version der TLE-Erweiterung, die in der Datenbank deinstalliert werden soll.
### Output
Keine.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
Die `uninstall_extension_if_exists`-Funktion entfernt alle Versionen einer TLE-Erweiterung aus einer bestimmten Datenbank. Wenn die TLE-Erweiterung nicht existiert, bleibt die Funktion im Hintergrund (es wird keine Fehlermeldung ausgegeben). Wenn die angegebene Erweiterung derzeit in einer Datenbank aktiv ist, wird sie von dieser Funktion nicht gelöscht. Sie müssen `DROP EXTENSION` explizit aufrufen, um die TLE-Erweiterung zu entfernen, bevor Sie diese Funktion verwenden, um ihre Artefakte zu deinstallieren.
### Funktionsprototyp
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `extname` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
### Output
Die `uninstall_extension_if_exists`-Funktion gibt `true` nach der Deinstallation der angegebenen Erweiterung zurück. Wenn die angegebene Erweiterung nicht vorhanden ist, gibt die Funktion `false` zurück.
+ `true` – Gibt `true` nach der Deinstallation der TLE-Erweiterung zurück.
+ `false` – Gibt `false` zurück, wenn die TLE-Erweiterung in der Datenbank nicht existiert.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
Die `uninstall_update_path`-Funktion entfernt den angegebenen Aktualisierungspfad einer TLE-Erweiterung. Dadurch wird verhindert, dass `ALTER EXTENSION ... UPDATE TO` diesen Pfad als Aktualisierungspfad verwendet.
Wenn die TLE-Erweiterung derzeit von einer der Versionen in diesem Aktualisierungspfad verwendet wird, verbleibt sie in der Datenbank.
Wenn der angegebene Aktualisierungspfad nicht vorhanden ist, gibt diese Funktion einen Fehler aus.
### Funktionsprototyp
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `extname` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `fromvers` – Die Quellversion der TLE-Erweiterung, die im Aktualisierungspfad verwendet wird.
+ `tovers` – Die Zielversion der TLE-Erweiterung, die im Aktualisierungspfad verwendet wird.
### Output
Keine.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
Die `uninstall_update_path_if_exists`-Funktion ähnelt `uninstall_update_path` insofern, als sie den angegebenen Aktualisierungspfad aus einer TLE-Erweiterung entfernt. Wenn der Aktualisierungspfad jedoch nicht existiert, löst diese Funktion keine Fehlermeldung aus. Stattdessen gibt die Funktion `false` zurück.
### Funktionsprototyp
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Rolle
`pgtle_admin`
### Argumente
+ `extname` – Der Name der TLE-Erweiterung. Dieser Wert wird beim Aufrufen von `CREATE EXTENSION` verwendet.
+ `fromvers` – Die Quellversion der TLE-Erweiterung, die im Aktualisierungspfad verwendet wird.
+ `tovers` – Die Zielversion der TLE-Erweiterung, die im Aktualisierungspfad verwendet wird.
### Output
+ `true` – Die Funktion hat den Pfad für die TLE-Erweiterung erfolgreich aktualisiert.
+ `false` – Die Funktion konnte den Pfad für die TLE-Erweiterung nicht aktualisieren.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
Die `unregister_feature`-Funktion bietet eine Möglichkeit, Funktionen zu entfernen, die für die Verwendung von `pg_tle`-Features wurden, wie z. B. Haken. Weitere Informationen zur Registrierung eines Features erhalten Sie unter [pgtle.register\$1feature](#pgtle.register_feature).
### Funktionsprototyp
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Rolle
`pgtle_admin`
### Argumente
+ `proc` – Der Name einer gespeicherten Funktion, für die ein `pg_tle`-Feature registriert werden soll.
+ `feature` – Der Name des `pg_tle`-Features, das für die Funktion registriert werden soll. Beispielsweise ist `passcheck` ein Feature, das für die Verwendung durch die vertrauenswürdigen Spracherweiterungen, die Sie entwickeln, registriert werden kann. Weitere Informationen finden Sie unter [Haken zur Passwortüberprüfung (Passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
Keine.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
Die `unregister_feature`-Funktion bietet eine Möglichkeit, Funktionen zu entfernen, die für die Verwendung von `pg_tle`-Features wurden, wie z. B. Haken. Weitere Informationen finden Sie unter [Verwenden von PostgreSQL-Haken mit Ihren TLE-Erweiterungen](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Gibt `true` zurück, nachdem die Registrierung der Funktion erfolgreich aufgehoben wurde. Gibt `false` zurück, wenn das Feature nicht registriert wurde.
Informationen zur Registrierung von `pg_tle`-Features für Ihre TLE-Erweiterungen finden Sie unter [pgtle.register\$1feature](#pgtle.register_feature).
### Funktionsprototyp
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Rolle
`pgtle_admin`
### Argumente
+ `proc` – Der Name der gespeicherten Funktion, für die ein `pg_tle`-Feature registriert wurde.
+ `feature` – Der Name des `pg_tle`-Features, das mit der vertrauenswürdigen Spracherweiterung registriert wurde.
### Output
Gibt `true` oder `false` wie folgt zurück.
+ `true` – Die Funktion hat die Registrierung des Features in der Erweiterung erfolgreich aufgehoben.
+ `false` – Die Funktion konnte die Registrierung des Features in der TLE-Erweiterung nicht aufheben.
### Verwendungsbeispiel
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Hakenreferenz für Trusted Language Extensions für PostgreSQL
Trusted Language Extensions für PostgreSQL unterstützt PostgreSQL-Haken. Ein *Haken* ist ein interner Callback-Mechanismus, der Entwicklern zur Erweiterung der Kernfunktionalität von PostgreSQL zur Verfügung steht. Durch die Verwendung von Haken können Entwickler ihre eigenen Funktionen oder Verfahren zur Verwendung bei verschiedenen Datenbankoperationen implementieren und so das Verhalten von PostgreSQL in gewisser Weise ändern. Sie können beispielsweise einen `passcheck`-Haken verwenden, um anzupassen, wie PostgreSQL die Passwörter behandelt, die beim Erstellen oder Ändern von Passwörtern für Benutzer (Rollen) angegeben werden.
In der folgenden Dokumentation erfahren Sie mehr über die Passcheck-Hooks, die für Ihre TLE-Erweiterungen verfügbar sind. Weitere Informationen zu den verfügbaren Hooks, einschließlich des Client-Authentifizierungs-Hooks, finden Sie unter [Trusted Language Extensions-Hooks](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Haken zur Passwortüberprüfung (Passcheck)
Der `passcheck`-Haken wird verwendet, um das PostgreSQL-Verhalten während der Passwortüberprüfung für die folgenden SQL-Befehle und `psql`-Metabefehle anzupassen.
+ `CREATE ROLE username ...PASSWORD` – Weitere Informationen finden Sie im Abschnitt [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) der PostgreSQL-Dokumentation.
+ `ALTER ROLE username...PASSWORD` – Weitere Informationen finden Sie im Abschnitt [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) der PostgreSQL-Dokumentation.
+ `\password username` – Dieser interaktive `psql`-Metabefehl ändert das Passwort für den angegebenen Benutzer auf sichere Weise, indem er das Passwort hasht, bevor die `ALTER ROLE ... PASSWORD`-Syntax transparent verwendet wird. Der Metabefehl ist ein sicherer Wrapper für den `ALTER ROLE ... PASSWORD`-Befehl, daher gilt der Haken für das Verhalten des`psql`-Metabefehls.
Ein Beispiel finden Sie unter [Liste der Hakencodes für die Passwortüberprüfung](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [Funktionsprototyp](#passcheck_hook-prototype)
+ [Argumente](#passcheck_hook-arguments)
+ [Konfiguration](#passcheck_hook-configuration)
+ [Nutzungshinweise](#passcheck_hook-usage)
### Funktionsprototyp
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Argumente
Eine `passcheck`-Hakenfunktion verwendet die folgenden Argumente.
+ `username` – Der Name (als Text) der Rolle (Benutzername), die ein Passwort festlegt.
+ `password` – Das Klartext- oder Hash-Passwort. Das eingegebene Passwort sollte dem im `password_type` angegebenen Typ entsprechen.
+ `password_type` – Geben Sie das `pgtle.password_type`-Format des Passworts an. Dieses Format kann einer der folgenden Optionen entsprechen.
+ `PASSWORD_TYPE_PLAINTEXT` – Ein Klartext-Passwort.
+ `PASSWORD_TYPE_MD5`— Ein Passwort, das mit dem Algorithmus MD5 (Message Digest 5) gehasht wurde.
+ `PASSWORD_TYPE_SCRAM_SHA_256` – Ein Passwort, das mit dem SCRAM-SHA-256-Algorithmus gehasht wurde.
+ `valid_until` – Geben Sie den Zeitpunkt an, am dem das Passwort ungültig wird. Dieses Argument ist optional. Wenn Sie dieses Argument verwenden, geben Sie die Uhrzeit als `timestamptz`-Wert an.
+ `valid_null` – Wenn dieser boolesche Wert auf `true` festgelegt ist, wird die `valid_until`-Option auf `NULL` eingestellt.
### Konfiguration
Die Funktion `pgtle.enable_password_check` steuert, ob der Passcheck-Haken aktiv ist. Der Passcheck-Haken hat drei mögliche Einstellungen.
+ `off` – Schaltet den `passcheck`-Haken für die Passwortüberprüfung aus. Dies ist der Standardwert.
+ `on` – Aktiviert den `passcode`-Haken für die Passwortüberprüfung, sodass Passwörter mit der Tabelle verglichen werden.
+ `require` – Erfordert, dass ein Passwortüberprüfungshaken definiert wird.
### Nutzungshinweise
Um den `passcheck`-Haken ein- oder auszuschalten, müssen Sie die benutzerdefinierte DB-Parametergruppe für Ihre DB-Instance von RDS für PostgreSQL ändern.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```