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.
# Arbeiten mit Erweiterungen und Fremddaten-Wrappern
Sie können verschiedene PostgreSQL-*Erweiterungen* installieren und verwenden, um Ihrem DB-Cluster der Aurora-PostgreSQL-kompatiblen Edition einige Funktionen hinzuzufügen. Wenn Ihr Anwendungsfall beispielsweise eine intensive Dateneingabe in sehr großen Tabellen verlangt, können Sie die `[pg\$1partman](https://pgxn.org/dist/pg_partman/doc/pg_partman.html)`-Erweiterung installieren, um Ihre Daten zu partitionieren und damit den Workload zu verteilen.
**Anmerkung**
Ab Aurora PostgreSQL 14.5 unterstützt Aurora PostgreSQL Trusted Language Extensions für PostgreSQL. Diese Funktion ist als Erweiterung `pg_tle` implementiert, die Sie Ihrem Aurora PostgreSQL hinzufügen können. Mithilfe dieser Erweiterung können Entwickler ihre eigenen PostgreSQL-Erweiterungen in einer sicheren Umgebung erstellen, was die Setup- und Konfigurationsanforderungen sowie einen Großteil der Vorabtests für neue Erweiterungen vereinfacht. 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-Cluster-Parametergruppe Ihres DB-Clusters von Aurora PostgreSQL hinzuzufü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/#).
Eine Erweiterung, die Zugriff auf externe Daten ermöglicht, wird als *Fremddaten-Wrapper* (FDW) bezeichnet. Zum Beispiel ermöglicht die Erweiterung `oracle_fdw` Ihrem Aurora-PostgreSQL-DB-Cluster die Zusammenarbeit mit Oracle-Datenbanken.
Sie können auch genau angeben, welche Erweiterungen auf Ihrer Aurora PostgreSQL DB-Instance installiert werden können, indem Sie sie im Parameter `rds.allowed_extensions` aufführen. Weitere Informationen finden Sie unter [Einschränkung der Installation von PostgreSQL-Erweiterungen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction.html).
Im Folgenden finden Sie Informationen zur Einrichtung und Verwendung einiger Erweiterungen, Module und, die für Aurora PostgreSQL FDWs verfügbar sind. Der Einfachheit halber werden diese alle als „Erweiterungen“ bezeichnet. Eine Auflistung der Erweiterungen, die Sie mit den aktuell verfügbaren Aurora-PostgreSQL-Versionen verwenden können, finden Sie unter [Versionen der Erweiterungen für Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in *Versionshinweise für Aurora PostgreSQL*.
+ [Verwalten großer Objekte mit dem lo-Modul](PostgreSQL_large_objects_lo_extension.md)
+ [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
+ [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md)
+ [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md)
+ [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren](Appendix.PostgreSQL.CommonDBATasks.pglogical.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 Unterstützung für delegierte Erweiterungen von Amazon Aurora für PostgreSQL
Mithilfe der Unterstützung für delegierte Erweiterungen von Amazon Aurora 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 eine neue Rolle namens `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 die Erweiterungen angeben, die auf Ihrer DB-Instance von Aurora PostgreSQL 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
+ 15.5 und höhere 15-Versionen
+ 14.10 und höhere 14 Versionen
+ 13.13 und höhere 13 Versionen
+ 12.17 und höhere 12 Versionen
**Topics**
+ [Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer](#AuroraPostgreSQL.delegated_ext_mgmt)
+ [Konfiguration, die in der Unterstützung für delegierte Erweiterungen von Aurora für PostgreSQL verwendet wird](#AuroraPostgreSQL.delegated_ext_config)
+ [Deaktivieren der Unterstützung für die delegierte Erweiterung](#AuroraPostgreSQL.delegated_ext_disable)
+ [Vorteile der Verwendung der Unterstützung für delegierte Erweiterungen von Amazon Aurora](#AuroraPostgreSQL.delegated_ext_benefits)
+ [Einschränkung der Unterstützung für delegierte Erweiterungen von Amazon Aurora für PostgreSQL](#AuroraPostgreSQL.delegated_ext_limit)
+ [Für bestimmte Erweiterungen erforderliche Berechtigungen](#AuroraPostgreSQL.delegated_ext_perm)
+ [Sicherheitsüberlegungen](#AuroraPostgreSQL.delegated_ext_sec)
+ [Drop extension cascade ist deaktiviert](#AuroraPostgreSQL.delegated_ext_drop)
+ [Beispielerweiterungen, die mithilfe der Unterstützung für delegierte Erweiterungen hinzugefügt werden können](#AuroraPostgreSQL.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 Instanzparametergruppe, über die API AWS-Managementkonsole oder. Weitere Informationen finden Sie unter [Parametergruppen für Amazon Aurora](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 in der Unterstützung für delegierte Erweiterungen von Aurora 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/AuroraUserGuide/Aurora_delegated_ext.html) Weitere Informationen zum Einrichten dieses Parameters finden Sie unter [Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer](#AuroraPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Mit diesem Parameter kann der Kunde die Erweiterungen einschränken, die in der DB-Instance von Aurora PostgreSQL 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 DB-Instance von Aurora PostgreSQL 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 Aurora
Durch die Verwendung der Unterstützung für delegierte Erweiterungen von Amazon Aurora 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 Aurora für PostgreSQL
+ Objekte, die während der Erweiterungserstellung erstellt wurden, benötigen möglicherweise zusätzliche Berechtigungen, damit die Erweiterung ordnungsgemäß funktioniert.
## 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 | | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | | | |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | | | | |
| dict\$1int | | | | intdict | |
| pg\$1partman | | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | | | |
| pg\$1stat\$1statements | | | | | |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | | | |
| postgis\$1raster | | | | | |
| postgis\$1topology | | topology, layer | topology | | Der delegierte Benutzer muss der Datenbankbesitzer sein. |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | | | | |
| rds\$1tools | role\$1password\$1encryption\$1type | | | | |
| postgis\$1tiger\$1geocoder | | geocode\$1settings\$1default, geocode\$1settings | tiger | | |
| pg\$1freespacemap | pg\$1freespace | | | | |
| pg\$1visibility | pg\$1visibility | | | | |
## 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 großer Objekte mit dem lo-Modul
Das lo-Modul (Erweiterung) richtet sich an Datenbankbenutzer und Entwickler, die mit PostgreSQL-Datenbanken über JDBC- oder ODBC-Treiber arbeiten. Sowohl JDBC als auch ODBC erwarten, dass die Datenbank das Löschen großer Objekte bewältigt, wenn sich Verweise auf sie ändern. PostgreSQL funktioniert jedoch nicht so. PostgreSQL geht nicht davon aus, dass ein Objekt gelöscht werden sollte, wenn sich sein Verweis ändert. Demzufolge verbleiben Objekte auf der Festplatte und sind nicht referenziert. Die Erweiterung lo enthält eine Funktion, mit der bei Referenzänderungen das Löschen von Objekten bei Bedarf ausgelöst wird.
**Tipp**
Wenn Sie feststellen möchten, ob Ihre Datenbank von der lo-Erweiterung profitieren kann, suchen Sie mit dem `vacuumlo`-Dienstprogramm nach verwaisten großen Objekten. Um die Anzahl von verwaisten großen Objekten zu erhalten, ohne Maßnahmen zu ergreifen, führen Sie das Dienstprogramm mit der `-n` Option (no-op) aus. Weitere Informationen erhalten Sie unter [vacuumlo utility](#vacuumlo-utility).
Das lo-Modul ist für Aurora PostgreSQL 13.7, 12.11, 11.16, 10.21 und höhere Nebenversionen verfügbar.
Zum Installieren des Moduls (Erweiterung) benötigen Sie `rds_superuser`-Berechtigungen. Durch die Installation der lo-Erweiterung wird Ihrer Datenbank Folgendes hinzugefügt:
+ `lo`— Dies ist ein Datentyp für große Objekte (Lo), den Sie für binäre große Objekte (BLOBs) und andere große Objekte verwenden können. Der `lo`-Datentyp ist eine Domäne des `oid`-Datentyps. Mit anderen Worten, es ist eine Objekt-ID mit optionalen Beschränkungen. Weitere Informationen finden Sie unter [Objekt-IDs](https://www.postgresql.org/docs/14/datatype-oid.html) in der PostgreSQL-Dokumentation. Einfach ausgedrückt, können Sie den `lo` Datentyp verwenden, um Ihre Datenbankspalten, die große Objektverweise enthalten, von anderen Objektbezeichnern (OIDs) zu unterscheiden.
+ `lo_manage` – Dies ist eine Funktion, die Sie in Triggern für Tabellenspalten verwenden können, die große Objektreferenzen enthalten. Immer wenn Sie einen Wert löschen oder ändern, der auf ein großes Objekt verweist, hebt der Trigger die Verknüpfung des Objekts (`lo_unlink`) mit seiner Referenz auf. Verwenden Sie den Trigger für eine Spalte nur, wenn die Spalte der einzige Datenbankverweis auf das große Objekt ist.
Weitere Informationen zum Modul für große Objekte erhalten Sie unter [lo](https://www.postgresql.org/docs/current/lo.html) in der PostgreSQL-Dokumentation.
## Installieren der lo-Erweiterung
Stellen Sie vor der Installation der lo-Erweiterung sicher, dass Sie über `rds_superuser`-Berechtigungen verfügen.
**So installieren Sie die lo-Erweiterung**
1. Verwenden Sie `psql`, um eine Verbindung mit der primären DB-Instance Ihres Aurora-PostgreSQL-DB-Clusters herzustellen.
```
psql --host=your-cluster-instance-1.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. Installieren Sie die Erweiterung wie folgt.
```
postgres=> CREATE EXTENSION lo;
CREATE EXTENSION
```
Sie können jetzt den `lo`-Datentyp zum Definieren von Spalten in Ihren Tabellen verwenden. Beispielsweise können Sie eine Tabelle (`images`) erstellen, die Raster-Bilddaten enthält. Sie können den `lo`-Datentyp für eine Spalte `raster` verwenden, wie im folgenden Beispiel, mit dem eine Tabelle erstellt wird, gezeigt.
```
postgres=> CREATE TABLE images (image_name text, raster lo);
```
## Verwenden der Triggerfunktion lo\$1manage zum Löschen von Objekten
Sie können die `lo_manage`-Funktion in einem Trigger in einer `lo` oder anderen großen Objektspalten verwenden, um verwaiste Objekte zu bereinigen (und zu verhindern), wenn `lo` aktualisiert oder gelöscht wird.
**So richten Sie Trigger für Spalten ein, die auf große Objekte verweisen**
+ Führen Sie eine der folgenden Aktionen aus:
+ Erstellen Sie einen BEFORE UPDATE ODER DELETE-Trigger für jede Spalte, damit diese eindeutige Verweise auf große Objekte enthält, wobei der Spaltenname als Argument verwendet wird.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
+ Wenden Sie einen Trigger nur an, wenn die Spalte aktualisiert wird.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OF images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
Die `lo_manage`-Trigger-Funktion funktioniert nur im Kontext des Einfügens oder Löschens von Spaltendaten, je nachdem, wie Sie den Trigger definieren. Er hat keine Auswirkung, wenn Sie eine `DROP`- oder `TRUNCATE`-Operation in einer Datenbank ausführen. Das bedeutet, dass Sie vor der Verwendung der DROP-Operation Objektspalten aus allen Tabellen löschen sollten, um das Erstellen von verwaisten Objekten zu verhindern.
Angenommen, Sie möchten die Datenbank entfernen, die die Tabelle `images` enthält. Sie löschen die Spalte wie folgt.
```
postgres=> DELETE FROM images COLUMN raster
```
Vorausgesetzt, die `lo_manage`-Funktion ist in dieser Spalte definiert, um Löschvorgänge zu behandeln, können Sie die Tabelle jetzt sicher entfernen.
## Entfernen verwaister großer Objekte mit `vacuumlo`
Das `vacuumlo`-Dienstprogramm identifiziert verwaiste große Objekte und kann diese aus Datenbanken entfernen. Dieses Dienstprogramm ist seit PostgreSQL 9.1.24 verfügbar. Wenn Ihre Datenbankbenutzer routinemäßig mit großen Objekten arbeiten, empfehlen wir Ihnen, `vacuumlo`gelegentlich auszuführen, um verwaiste große Objekte zu bereinigen.
Bevor Sie die lo-Erweiterung installieren, können Sie mit `vacuumlo`beurteilen, ob Ihr Aurora-PostgreSQL-DB-Cluster davon profitieren kann. Führen Sie dazu `vacuumlo` mit der `-n`-Option (no-op) aus, um zu zeigen, was entfernt würde, wie im Folgenden gezeigt:
```
$ vacuumlo -v -n -h your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com -p 5433 -U postgres docs-lab-spatial-db
Password:*****
Connected to database "docs-lab-spatial-db"
Test run: no large objects will be removed!
Would remove 0 large objects from database "docs-lab-spatial-db".
```
Wie die Ausgabe zeigt, stellen verwaiste große Objekte für diese bestimmte Datenbank kein Problem dar.
Weitere Informationen über dieses Dienstprogramm finden Sie unter [https://www.postgresql.org/docs/current/vacuumlo.html](https://www.postgresql.org/docs/current/vacuumlo.html) in der PostgreSQL-Dokumentation.
## Grundlegendes zur Funktionsweise von `vacuumlo`
Der `vacuumlo` Befehl entfernt verwaiste große Objekte (LOs) aus Ihrer PostgreSQL-Datenbank, ohne Ihre Benutzertabellen zu beeinträchtigen oder Konflikte mit ihnen zu verursachen.
Der Befehl lautet wie folgt:
1. `vacuumlo`beginnt mit der Erstellung einer temporären Tabelle, die alle Object IDs (OIDs) der großen Objekte in Ihrer Datenbank enthält.
1. `vacuumlo` durchsucht dann jede Spalte in der Datenbank, die die Datentypen `oid` oder `lo` verwendet. Wenn `vacuumlo` in diesen Spalten eine passende OID gefunden wird, wird die OID aus der temporären Tabelle entfernt. `vacuumlo` überprüft nur Spalten, die die ausdrücklich mit `oid` oder `lo` benannt sind, keine Domains, die auf diesen Typen basieren.
1. Die verbleibenden Einträge in der temporären Tabelle stehen für verwaiste Einträge LOs, die `vacuumlo` dann sicher entfernt werden.
## Verbessern der Leistung von `vacuumlo`
Sie können die Leistung von `vacuumlo` potenziell verbessern, indem Sie die Batchgröße mithilfe der Option `-l` erhöhen. Dadurch können mehr `vacuumlo` auf LOs einmal verarbeitet werden.
Wenn Ihr System über ausreichend Arbeitsspeicher verfügt und Sie die temporäre Tabelle vollständig im Arbeitsspeicher unterbringen können, kann eine Erhöhung der Einstellung `temp_buffers` auf Datenbankebene die Leistung verbessern. Dadurch kann sich die Tabelle vollständig im Arbeitsspeicher befinden, was die Gesamtleistung verbessern kann.
Die folgende Abfrage schätzt die Größe der temporären Tabelle:
```
SELECT
pg_size_pretty(SUM(pg_column_size(oid))) estimated_lo_temp_table_size
FROM
pg_largeobject_metadata;
```
## Überlegungen zu großen Objekten
Im Folgenden finden Sie einige wichtige Überlegungen, die Sie beachten sollten, wenn Sie mit großen Objekten arbeiten:
+ `Vacuumlo`ist die einzige Lösung, da es derzeit keine andere Methode gibt, um verwaiste LOs Dateien zu entfernen.
+ Tools wie pglogical, systemeigene logische Replikation, die Replikationstechnologien verwenden AWS DMS , unterstützen die Replikation großer Objekte nicht.
+ Vermeiden Sie beim Entwerfen Ihres Datenbankschemas nach Möglichkeit die Verwendung großer Objekte und ziehen Sie stattdessen alternative Datentypen wie `bytea` in Betracht.
+ Führen Sie das `vacuumlo` Programm regelmäßig, mindestens einmal wöchentlich, aus, um Probleme mit verwaisten Geräten zu vermeiden. LOs
+ Verwenden Sie einen Trigger mit dieser `lo_manage` Funktion für Tabellen, in denen große Objekte gespeichert sind, um zu verhindern, dass verwaiste Objekte LOs erstellt werden.
# 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 [Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). .
Sie können jederzeit prüfen, ob eine neue Version der PostGIS-Erweiterung auf dem Aurora-PostgreSQL-DB-Cluster 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 [Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
## PostGIS-Erweiterungsversionen
Wir empfehlen Ihnen, die Versionen aller Erweiterungen wie PostGIS zu installieren, wie sie unter [Extension versions for Aurora PostgreSQL-Compatible Edition](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) (Versionen aller Erweiterungen für Editionen, die mit Aurora PostgreSQL kompatibel sind) in *Versionshinweise für Aurora PostgreSQL* aufgelistet sind. . 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 Aurora PostgreSQL*:
+ [Erweiterungsversionen für Aurora PostgreSQL 14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.14)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.13) (Versionen aller Erweiterungen für Edition 13, die mit Aurora PostgreSQL kompatibel ist)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.12) (Versionen aller Erweiterungen für Edition 12, die mit Aurora PostgreSQL kompatibel ist)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.11) (Versionen aller Erweiterungen für Edition 11, die mit Aurora PostgreSQL kompatibel ist)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.10) (Versionen aller Erweiterungen für Edition 10, die mit Aurora PostgreSQL kompatibel ist)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 9.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.96) (Versionen aller Erweiterungen für Edition 9.6, die mit Aurora PostgreSQL kompatibel ist)
## 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 Aurora-PostgreSQL-DB-Cluster verfügbar ist. 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 der Writer-Instance Ihres Aurora-PostgreSQL-DB-Clusters 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;
```
# 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 Aurora-PostgreSQL-Versionen 12.6 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 Aurora](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).
# 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 Aurora-PostgreSQL-Versionen 12.6 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.
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 [Amazon-Aurora-PostgreSQL-Parameter](AuroraPostgreSQL.Reference.ParameterGroups.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 Ihres Aurora-PostgreSQL-DB-Clusters 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.
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 Aurora](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/AuroraUserGuide/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/AuroraUserGuide/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 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 Ihrem DB-Cluster von Aurora 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 [Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.md).
Die pgAudit-Erweiterung redigiert sensible Daten wie Klartext-Passwörter aus den Protokollen. Wenn Ihr DB-Cluster von Aurora PostgreSQL so konfiguriert ist, dass Data Manipulation Language (DML)-Anweisungen protokolliert werden, wie in [Aktivieren der Abfrageprotokollierung für Ihren Aurora PostgreSQL-DB-Cluster ](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 Aurora-PostgreSQL-Versionen unterstützt. Eine Liste der pgAudit-Versionen, die von Aurora PostgreSQL unterstützt werden, finden Sie unter [Versionen der Erweiterungen für Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in den *Versionshinweisen für Aurora 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 einrichten möchten, fügen Sie zunächst pgAudit zu den gemeinsam genutzten Bibliotheken in der , benutzerdefinierten DB-Cluster-Parametergruppe für Ihren DB-Cluster von Aurora PostgreSQL hinzu. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Cluster-Parametergruppe finden Sie unter [Parametergruppen für Amazon Aurora](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 Ihr DB-Cluster von Aurora PostgreSQL einer benutzerdefinierten DB-Cluster -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 Writer-Instance des DB-Clusters von Aurora PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre Writer-Instance des DB-Clusters von Aurora 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-Cluster von Aurora PostgreSQL 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 `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/AuroraUserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Starten Sie die Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance Ihres DB-Clusters von Aurora 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/AuroraUserGuide/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 Writer-Instance des DB-Clusters von Aurora 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 Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL neu zu starten, sodass die pgaudit-Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-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 Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL mit dem folgenden AWS CLI-Befehl neu.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Überprüfen von Datenbankobjekten
Wenn pgAudit auf Ihrem DB-Cluster von Aurora 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/AuroraUserGuide/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 Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL mit dem folgenden AWS CLI-Befehl neu, damit Ihre Änderungen der Parameter wirksam werden.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-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 Aurora-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 [Aurora PostgreSQL ](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 DB-Cluster von Aurora PostgreSQL überwachen.
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-Cluster-Parametergruppe der Writer-Instance des DB-Clusters von Aurora PostgreSQL. Wenn Sie nicht möchten, dass Datenbankbenutzer Ihre Konfigurationseinstellungen für die Audit-Protokollierung umgehen, müssen Sie ihre Berechtigungen ändern.
Angenommen, Ihr DB-Cluster von Aurora 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.
# Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren
Alle derzeit verfügbaren Aurora-PostgreSQL-Versionen 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 [Überblick über die logische Replikation von PostgreSQL mit Aurora](AuroraPostgreSQL.Replication.Logical.md).
Die `pglogical`-Erweiterung unterstützt die logische Replikation zwischen zwei oder mehr DB-Cluster von Aurora 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 der DB-Cluster von Aurora PostgreSQL, der 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 der DB-Cluster von Aurora PostgreSQL, der 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 den DB-Cluster von Aurora 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 Aurora PostgreSQL PostgreSQL](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 Aurora 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 Ihrem DB-Cluster von Aurora PostgreSQL einrichten möchten, fügen Sie zunächst `pglogical` zu den gemeinsam genutzten Bibliotheken in der benutzerdefinierten DB-Cluster-Parametergruppe für Ihren DB-Cluster von Aurora 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 Ihr DB-Cluster von Aurora PostgreSQL einer benutzerdefinierten DB-Cluster -Parametergruppe zugeordnet ist. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Cluster-Parametergruppe finden Sie unter [Parametergruppen für Amazon Aurora](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 Writer-Instance des DB-Clusters von Aurora PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre Writer-Instance des DB-Clusters von Aurora 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-Cluster von Aurora PostgreSQL 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 `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/AuroraUserGuide/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 Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance des DB-Clusters von Aurora 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 Writer-Instance des Aurora PostgreSQL-DB-Clusters zu aktivieren.
```
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 Writer-Instance Ihrer Aurora neu zu starten, sodass die pglogische Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, stellen Sie über `psql` eine Verbindung mit der Writer-Instance Ihres DB-Clusters von Aurora 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 Writer-Instance Ihrer Aurora PostgreSQL-DB-Cluster-RDS mit dem folgenden Befehl neu. AWS CLI
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Einrichten der logischen Replikation für den DB-Cluster von Aurora PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Clustern von Aurora 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 Ihr DB-Cluster von Aurora PostgreSQL über eine Writer-Instance mit einer 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 diesen DB-Cluster von Aurora 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 der DB-Cluster von Aurora 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 dem DB-Cluster von Aurora 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 diesen DB-Cluster von Aurora 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 eines DB-Clusters von Aurora PostgreSQL durchführen können, der 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, den DB-Cluster von Aurora PostgreSQL zu aktualisieren und dann die Replikation erneut einzurichten und neu zu starten.
Die Replikationsslots werden nur auf dem Herausgeberknoten gehostet. Der Aurora-PostgreSQL-Abonnentenknoten hat in einem logischen Replikationsszenario keine Slots, die gelöscht werden könnten. Der Upgrade-Prozess für die Hauptversion von Aurora PostgreSQL unterstützt das Upgrade des Abonnenten auf eine neue Hauptversion von PostgreSQL unabhängig vom Herausgeberknoten. Der Upgrade-Prozess unterbricht jedoch den Replikationsprozess und beeinträchtigt die Synchronisation der WAL-Daten zwischen dem Herausgeber- und dem Abonnentenknoten. Sie müssen die logische Replikation zwischen Herausgeber und Abonnent wiederherstellen, nachdem Sie den Herausgeber, den Abonnenten oder beide aktualisiert haben. Im folgenden Verfahren wird gezeigt, wie Sie feststellen, ob die Replikation unterbrochen wurde, und wie Sie das Problem beheben.
## 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 Aurora PostgreSQL PostgreSQL
Bevor Sie ein Hauptversions-Upgrade eines DB-Clusters von Aurora PostgreSQL durchführen können, der 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 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. |
# Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon Aurora Postgre SQL
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` Ihrer Aurora-PostgreSQL-DB-Instance die Zusammenarbeit mit Oracle-Datenbanken.
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
Das Aurora-PostgreSQL-DB-Cluster 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 Aurora 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 Aurora 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 [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.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 Ihrem Aurora-PostgreSQL-DB-Cluster 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 des Aurora-PostgreSQL-DB-Clusters 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 Aurora PostgreSQL Version 15.4, 14.9, 13.12, 12.16 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 Aurora-PostgreSQL-DB zur Verwendung der mysql\$1fdw-Erweiterung](#postgresql-mysql-fdw.setting-up)
+ [Beispiel: Arbeiten mit einer Aurora-MySQL--Datenbank von Aurora 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 Aurora-PostgreSQL-DB zur Verwendung der mysql\$1fdw-Erweiterung
Das Einrichten der `mysql_fdw`-Erweiterung auf dem Aurora-PostgreSQL-DB-Cluster umfasst das Laden der Erweiterung in den DB-Cluster 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 einen Aurora-MySQL-DB-Cluster 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. Der Aurora-PostgreSQL-DB-Cluster und der Aurora-MySQL-DB-Cluster ebenso wie 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 des Aurora-PostgreSQL-DB-Clusters 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 dem Aurora-PostgreSQL-DB-Cluster 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 dem Aurora-PostgreSQL-DB-Cluster aus. Die Schritte setzen voraus, dass Sie als Benutzer mit `rds_superuser`-Berechtigungen wie `postgres` verbunden sind.
1. Erstellen Sie einen fremden Server auf dem Aurora-PostgreSQL-DB-Cluster:
```
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 Aurora-MySQL--Datenbank von Aurora PostgreSQL
Angenommen, Sie haben eine einfache Tabelle auf einer Aurora-PostgreSQL-DB-Instance. Ihre Aurora-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 Aurora-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 Aurora 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 Ihrem Aurora-PostgreSQL-DB-Cluster 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 Aurora PostgreSQL 12.7, Amazon Aurora Version 4.2) und höheren Versionen 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 Aurora 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 Ihrem Aurora-PostgreSQL-DB-Cluster 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-Aurora-PostgreSQL-Versionen 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 einem Aurora-PostgreSQL-DB-Cluster. 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 der Aurora-PostgreSQL-DB-Cluster 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 primären Instance des Aurora-PostgreSQL-DB-Clusters über ein Konto mit der `rds_superuser`-Rolle:
```
psql --host=your-cluster-name-instance-1.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 Ihrem Aurora-PostgreSQL-DB-Cluster installiert wurde, richten Sie den fremden Server ein.
**So erstellen Sie den fremden Server**
Führen Sie diese Aufgaben auf dem Aurora-PostgreSQL-DB-Cluster unter Verwendung eines Kontos mit `rds_superuser`-Berechtigungen aus.
1. Erstellen Sie einen fremden Server auf dem Aurora-PostgreSQL-DB-Cluster:
```
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 im DB-Cluster von Aurora 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 Aurora 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).